Anyone who uses "the new jQuery" as some sort of insult (as it seems Sara did in her tweet) probably hasn't been a developer for more than a few years or is just trying to sound smarter than they are by bashing an easy target.
The reason jQuery got so popular is that it made common tasks so much easier than anything else at the time. Anyone who was doing web development before jQuery knows what a godsend it was at the time. JQuery was a fantastic leap forward for development at the time it was released.
JQuery didn't become bad, the rest of the development world caught up and made it unnecessary.
A charitable explanation of Sara's tweet might be that, like with jQuery, it is becoming difficult to convince new developers that React may not be necessary for their next project.
The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did.
This is kind of the same concern I have with Vue to be honest. I use Vue for prototyping and will probably use it in some final apps as well. But I'm probably not ever going to use a component that someone else has written if it relies on Vue.
IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc...
I kind of wonder if the problems Vue solves for me could be solved better by a smaller, lodash-style library instead of a framework.
That's fair.
> The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did.
I totally agree with that, but I don't think you can use that as a knock against jQuery, react, or vue. I think developers, especially js developers with our love of pulling in external packages, have yet to find a great solution for dependency management.
> IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc...
I think lodash can work that way because most of its functions are small and self-contained. It's easy to just bundle in a few select functions when they functions are 100 lines max and don't need the rest of the library, but I don't think React or Vue could use a similar approach.
Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it?
First it took about a decade of browser and ECMA very intensive development to actually make it unnecessary.
> it is becoming difficult to convince new developers that React may not be necessary for their next project.
Give it a decade for the web "components" to actually become composable and for inventive and useful native language built-in solutions to state management to happen before you start advocating people out of React. Until then telling people they might not need React is not a step forward but backward. Imagine people saying "you might not need jQuery" in times where IE reigned and browsers were wildly incompatible.
When querySelector and ES6 came about, I found myself not needing jquery by default.
But jQuery wasn’t just a tool, it was also community. What that community did/perpetuated was some pretty bad and ill advised practices. Plugins for everything - the old $.sum(2,2) joke applies here. DOM for state. Even sanctioned projects like jQuery UI were guilty of some terrible, awful practices.
That said, React isn’t the new jQuery, it’s the new Backbone. Backbone lacked so much - and did so little - that it’s deficiencies needed to be made up for by “other” tooling. As a result, there was O(n) ways to “Backbone” – making backbone apps very difficult to study/build/maintain.
React is fine. The community just needs to coalesce.
Edit: typing on my phone; and am lazy
react, redux, thunks (with async functions), fetch, material-ui ... those will get you a LONG way to where you need to be with react.
However in my experience, a couple of things were key to creating a negative view of jQuery:
1. Security and unsafe defaults, for example: evaluating remote JavaScript by default [1]; and unsafe DOM parsing by default [2]
2. Not really to blame on jQuery, but its ease of use for DOM manipulation led to programming patterns that aren't easily scalable, for both code and performance
[1] https://nvd.nist.gov/vuln/detail/CVE-2015-9251 [2] http://api.jquery.com/jQuery.parseHTML/
Times were different
I cant even name a similar piece of software in web development history that is as important as jQuery.
Despite Web development as a whole, back end or front end is still no where near being good enough, it is still many times better then the old days.
React is in a similar boat - it provides a far more pleasant experience keeping the DOM in sync with your application state, in a way that Web Components don't (although they have other advantages that make them great when used together with React).
I would understand if comparing VueJS with jquey. Even if they are very different, the philosophy is the same: a small elegant easy to use versatil tool.
Yet, Sara is neither of those, she's a well respected developer, who's work with CSS and SVG is world-class.
If she's using jQuery as a comparison she's doing it from a place of experience and knowledge
Also, a slow loading JS lib wasn't as much of an issue 5-7 years ago when jQuery was really in its heyday. Web pages were simpler and more information based back then and it was usually a requirement that they be useable without javascript. Since you are (should be) loading jQuery at the end of the page (or asynchronously) the page should render just fine without jQuery and probably would have been loaded by the time any user interaction would have happened.
Also, since users were on computers (mobile wasn't really a thing) and data usage wasn't a limiting factor (most plans were unlimited), loading extra data didn't really matter that much.
Yeah, jQuery had extra functions that you didn't need, but it didn't really hurt much at the time and there wasn't really a better option.
1. Every document has a root node. <div id='app' /> is your root node now. You had a root node before, you have a root node now.
2. Do a search and replace. That's easy.
3. That's another search and replace.
4. You don't need to call a constructor, you don't need to use bind, and you don't need to assign your functions to an variable on your class instance.
React allows you to compose things. Make something once and use it everywhere. You write much, much less code. You get lifecycle hooks for when things mount, update, unmount. You get easy templating in JSX. You can also ditch the whole thing for Inferno if you care about having no lisence or company behind it.
You also get amazing libraries for state management and async via reactivex.
React is great, mostly for bigger web apps that do need a framework and more structure, such as an SPA with multiple team members working on it.
Just like jQuery is great to do some quick and simple dom manipulation.
I've tried both opposites; I've been on teams working on large apps in jQuery, and it's hell. And I've also used React to implement simple little things, and it's also hell (part of it for reasons Brad mentions in this article).
I don't have much experience with Vuejs but I've been using it instead of React recently, and it's refreshing indeed. Just like jQuery you can just import it with a script tag and start doing some dom manipulation and it makes the code much cleaner than jQuery.
And as others have said, jQuery is not bad - it's awesome. I guess it didn't age very well with the JS env evolving, but it's great.
I'd argue this is bad advice. What constitutes a 'bigger' project us arbitrary, and once you build your whole app on jQuery it's expensive to migrate to React once you get just a bit 'bigger'.
Now whether or not all websites need to be React-based SPAs is a different question entirely.
I can usually jump into someone's react code and get what's going on pretty quickly unless they did something really gnarly with incredibly nested props. Even then, at least I still know where to drill down. With jQuery soup, you didn't get that luxury.
Being able to have an entire team know how to build components and provide them with functionality is an incredible advantage. I don't love everything about react either, but the ecosystem, somewhat enforced convention, tooling, etc - it's worth it (so far).
I love some things about Vue, but it isn't a silver bullet either. Brad seems to be pretty butt hurt about react. If you've worked on a large team without something like react, then worked on one with react, it really shines. It's a major productivity booster.
It's not perfect, but it's very good.
jQuery + co. have very consistent "look and feel"
Well, of course he will struggle to learn React. Web design and software engineering are two different fields… Not saying he needs a master in CS to learn React, but he will surely need to learn a bit of programming and JavaScript before jumping on it.
This isn't totally true -- if you really only wanted to implement a single toggle and leave the rest of the page alone, then you could replace just the relevant DOM elements with a container and render into that fragment of the page. (Though really I'd ask why use React if that's the only value you're getting out of it)
> I guess that’s why I’m still struggling to comprehend why so many organizations are so eager to take the sturdy, foundational layer of the frontend stack and rewrite it all in a proprietary format. [...] Projects like Vue are showing that’s not necessary.
Except, Vue.js does require a proprietary format; all those v-* attributes and custom components will be need to be migrated if you want to switch away from Vue. Comparatively, React is better in this regard because there are multiple implementations of React (preact, inferno, nerv). Also, JSX is technically optional, and it's really easy to mix markdown, or other formats/templating engines into a React app to handle the content-heavy bits.
Wikipedia seems to agree with me [1], but maybe I'm misinterpreting it:
I was more into those two but jQuery made everything dead simple.
A lot of the mootools team moved into React. At least the ones I was familiar with.
Move along. Engineers will continue to use good technology they understand (like React) while newcomers will continue to try to emotionally justify technologies they don't want to learn and use.
React is a decision. I'm speaking in broad generalizations because I don't know how to put this principle into more specific terms, but good programmers should avoid making decisions for as long as possible. This is the same reason why I caution people against using test frameworks. Most of the time when you start coding an application you won't have enough information to make any educated decisions about it.
This is a huge advantage that Vue has over React. You can use Vue for just one component out of your entire app and it's fine. It is fairly easy to separate it from all of the rest of your application logic and that means by extension it's fairly easy to rip it out later. Or at least... easy enough.
It's still not perfect. I dislike how hard it is to make its templates fail gracefully when Javascript is disabled. I dislike that it uses setters in its data model, which discourages immutable programming. I dislike a few other things as well.
At some point, someone will make a better framework than Vue, probably by building something even smaller and even more focused than Vue already is. But in the meantime, if you are going to use a framework for two-way data bindings, you should probably be using Vue instead of React. Opinion me, of course.
This is probably the only real concern I see.
jQuery is a library for DOM manipulation. It can co-exist with many other libraries.
React is an entire framework.
These days you need jquery less because browsers are more standards compliant and css animations basically work.
The trick is about using the right tool for the right job.
We have several large react applications - these are user-interaction heavy rich single page apps.
But we also use vanilla html and jquery dom manipulations in many other places.
Originally, jQuery's big selling point wasn't that it handled animations, it was that it gave you a query selector, and one that could be used in any browser. jQuery predates the release of chrome, and came out a few years before document.querySelector was added to Firefox and Chrome was released.
jQuery was monumentally more useful for common actions compared to its contemporaries, such as Dojo, MooTools and Prototype.
The people for whom ripping out React or Vue leads to a blank page are those who wanted an app from the ground-up.
If anything, React is losing because it doesn't include enough out of the box. If you wanted to build a news widget, fine. But if you wanted to build an app, you have to start putting pieces together from 3rd parties (or write your own custom pieces). That's not what a framework sounds like to me, that sounds like figure-out-your-own-framework, and I think that's why Vue is winning.
Create React App was a very late response, and I still don't think it's as good as Vue's up-and-going tooling experience.
With jQuery, you're likely building it with html and using jQuery for user interactions or animations (I know - not always true - constructing the markup with $('<tag>') is also useful). So its easier to rip out jQuery and replace it with - say - document.querySelector - or whatnot.
I personally think React is overkill if you're pulling it in to do a small widget on a larger non-react page
Is there a step-by-step tutorial for this? I was googling for one yesterday, because I have a legacy app and want to start moving small components (like datagrids) out of server-side rendering and into components.
The best I found was https://reactjs.org/docs/add-react-to-an-existing-app.html, which reads like it would make sense to an xperienced React developer, but not someone coming new to it.
I'm sorry but this is not a problem. If you commit to React then you commit to it. You are not suppoused to change it every other year.
Imagine a big C++ Qt application. Will you ever think of changing Qt on it, and expect no huge cost? No. That's unreasonable.
So what he wants is not only a cross-browser, cross-platform framework (and much more) but also a framework that is somehow "cross-framework"!!
This is really getting me. People, such flexibility and ubiquity is NOT FREE. People this days complain about the web being to complicated, and that it is a lot of complexity to make something "simple as a webapp". I agree, it is. But that simple multimedia webapp you get today works over a distributed network, in almost every platform, from mobile to desktop to almost everywhere. This kind of ubiquity will be unthinkable in the early 90s/2000s without investing on a huge number of experienced dev teams and a huge especialized codebase(s). Today some javascript framework and markup will give you almost the same product. Yes, I think the web ecosystem can be improved. A lot. And the end result is not always 1:1 comparable at many levels with what you would get back in the day with native apps and a load of work and experience. But still.
People complain but they don't know what they are getting.
React works better for teams working on applications that need build tooling and dependency management anyway.
Angular, frankly I don't see why anyone would pick it over the other two. Yeah, it's got more in the box, but that bigger box takes 4x as much effort to lift off the ground.
I totally agree, and in fact I would take it a little farther and say it's making functional programming mainstream on the backend as well. Many people I've worked with got their taste via React/Redux and then started adopting things like Elixir/Phoenix for the backend.
Maybe it's an overstatement, but I credit React with driving at least some of that.
You hit on the two points that makes React what it is. A pure state -> ui abstraction and the ability for large projects or teams to use it efficiently.
I do see something similar happening with our more junior devs. Their Google searches have now turned to "how do I read a cookie with React?"... and sure enough, there is a react-cookie lib - which may or may not be useful for their task... but since it says "react", it'll probably show up in a pull request. React can't be blamed for this though. All the ecosystem being built with the expectation of "well everyone's using React", _is_ a problem.
Education about separation of concerns is the only solution I can see.
He's given hundreds of talks all over the world about a component-based approach to style guides in web, but yet cannot fathom the need for React.
Catch being you he to learn how to write js but that's true for any framework as well. And frameworks have smaller shelf life anyways.
In the end it's hard to believe how fast JavaScript can be even on smaller devices.
Plus as I said, core logic works on both server and client and we have offline support as an added bonus.
The amount of js code to make even basic things work is high, and with so many different styles of writing react/js code, large codebases require significant effort to keep maintainable.
Which is to say, with this much effort put into structuring maintainable react js code, one could pretty much develop in any js ui framework (including jquery, backbone or none whatsoever) - since little of this effort is dependent on react, or made easier by it.
It's not something you can easily implement yourself either.
That's the main part that makes React code maintainable.
I don’t think the same could be said of your random JQuery or. Backbon based project
Or the more general problem of not knowing the difference between store state, local component state, and component instance state (the actual JS object's properties.)
The new Unstated library leveraging the next Context API is a nice balance I find for state management. It basically just mirrors Reacts setState style update system. Although you do lose the single source of truth pro of Redux.
I'm not a huge fan of React. I'm really not a fan of any site that requires Javascript to view. If it's a new article and I get a blank page, I immediately stick it in archive.is. I'm not turning on Javascript for your site just to view content. Fuck that. Fix your site to not suck shit.
I realize you can easily get into the same thing with Vue .. and I think Vue, React and others, makes sense if you're actually running a web application. Your main page, login page and other content pages should be static, no Javascript required. If you have a new site or a blog or graphics, why the hell are you requiring React/Vue/Angular or some other framework? Just display the content.
I haven't really looked into server-side rendering, but I suspect that still requires Javascript to be enabled on the client? Are there any newer Vue/React style front-end frameworks that are designed to still degrade gracefully without Javascript? (I suppose you can't really do this without pairing it with the backend language on the server).
I really like how Hackernews still supports a Javascript-less system, even for things like up/down votes (although I still turn JS on for HN to avoid page refreshes).
Is it worth the effort for a fraction of a percent of technical users whining about the need for JS? probably not.
For SSR you are sending the HTML text instead of JSON. Time ago you needed nodejs for SSR I do not know the alternatives today.
var formname = $(this).find('.formname');
formname.empty();
formname.append(n_input);
document.querySelector('.formname').innerHTML=n_input;
$(".formname").html(n_input);
- `this` might not be document
- find might return multiple elements, not just one
- if nothing matches, jQuery does not throw unlike the vanilla version
I do understand it's just an example, but if you'd consider all the implicit cases the jQuery example covers, you'd end up with a lot more than a single line. I see your point, but using off examples like this don't really sell it too well.
Array.from(document.querySelectorAll(...)).forEach(x => {...})
Modern libraries such as React and Vue however play a totally different role. They introduce proper architecture to web development such as separating the view from your business logic with data binding, they can not be compared with jquery which was just a nicer way of doing the same old manual DOM manipulation.
ReactJS is a power tool and it takes some learning.
If your primary concern is about your initial learning curve then you should look elsewhere such as VueJS but I'm glad of the power of ReactJS.
Changing class to className is not a big deal, nor are the minor other bits and pieces mentioned in the post.
With JQuery you're signing up for manual DOM manipulation. It's a challenge to scale that for what's now considered table-stakes for web apps.
React is made for building web-based applications. You can do small stuff with it, but it's often overkill.
Just because you can use a butter knife to turn a flathead screw, doesn't mean it's the right tool for the job. These days I might reach for Vue as a jQuery stand-in, but more likely, I'd use a smaller jQuery-like library, or just use straight vanilla JS, or other micro libraries. For anything big enough to deserve a build process React is absolutely my first choice.
same! Jquery is still quite useful and powerful. This is also what rails does for me; makes web development fun. Or highcharts making charts fun, or elasticsearch making search fun. To me that's a testament to elegantly solving a problem. I just don't get those fuzzies with react.
JQuery -> Backbone -> [Tons of Backbone wannabe's written in Coffeescript Batmanjs/Bananajs/what not..] -> Angular -> [Angular lookalikes with tons of magic] -> Ember -> Meteor -> React -> Vue -> [Wait a few months new framework in the Pipeline].
Unfortunately very few want to agree to the truth.
Anyway, I recommend giving this setup a go.
Any thoughts on https://news.ycombinator.com/item?id=17213264?
> Don’t @ me I’m not trying to start a controversy. I’m only stating an observation.
https://twitter.com/SaraSoueidan/status/1001189524477743105
React, like jQuery, could have done more to keep people from writing bad code. With React, they made the same mistake that Angular did, which was to impose strict rules on all developers. Vue, to its credit, doesn't make this mistake. It's much less opinionated about state management.
I don't disagree but will push back slightly on the appeal to authority. I think in JS land we're getting a little too carried away with celebrity developers (I often joke about "what would Dan Abramov say?" and it's only half-joke). I've been trying hard to focus on the ideas, without regard from who said it.
What does that even mean?
It's frightening, the degree to which many professional web app developers do not know the fundamentals of Javascript. Our technical interview starts out with ridiculously simple questions and gets progressively more difficult and esoteric. And a dismayingly high number of candidates don't get past the first couple of questions. And these are people with years of experience and at least some of the hot JS frameworks on their resume.
There’s nothing proprietary about React. It’s all open source. MIT licensed. If you don’t like Facebook’s implementation, there’s like a dozen re-implementations. Hell, a modestly competent software developer could write his own implementation of React in a few days of work.
All else being equal, I’d say a React code base will be less of a maintenance hassle in the future, than the spaghetti mess you usually get when trying to write complex applications with jQuery (been there, done that).
You can replace jquery/react with any technology or concept, OO programming, functional programming, MVC, blockchain, machine learning, and every technology or concept having its momentum is or will be misused in some way at some point.
This happened, is happening, and will always happen.
I think jQuery != react.
I do not understand, why experienced people like to compare jQuery with react when both the lib have different goal ? And show that jQuery is bad.
React can be used with jQuery for DOM manipulation. Described in react doc (https://reactjs.org/docs/integrating-with-other-libraries.ht...).
Shall I learn jQuery at all ? Please, guide me.
The problems with jQuery is that it's mostly a set of functions to simplify Ajax and DOM manipulation so it's not really helpful for the structure of an application.
React (and other frameworks surch as Angular, Ember and Vue), on the other hand, helps you to build reusable component which helps a lot to scale.
Also jQuery's golden age was when browser compatibility was a big issue, nowaday, most browsers behave properly.
There's no harm in learning jQuery, its interface is way more intuitive than native DOM apis. It could be a good idea to try and build a simple app with jQuery and see what are the pain points and then compare with a modern framework.
it is as if some react developer sat down and said, “how can we make this even simpler so that even my grandson can do it.”
i appreciate when we have guys like the authors of Vue come forward driving the community and taking web development to the next level giving us a more elegant solution.
React is for building applications, especially with teams. Combined with redux and a handful of other pieces, it's very nice.
Angular, I don't get why anyone would choose it today (I've said it time and again).
There are many big companies and startups who switched to Vue and loving it so I would say your point is moot.
jQuery and the plain DOM are retained mode APIs. You manipulate stateful objects to achieve your goals. It is ok for simple interactions, but it quickly becomes unmanageable for more complex apps.
React feels like writing normal Javascript.
Vue is very easy to embed into existing web page but feels like learning a new DSL instead of regular Javascript.
it's about workforce and durability of the platform
I prefer vue, but I dislike that it’s essentially a one man show.
And when compared to React, he's absolutely right.