jQuery Is Better Than React
melissa mcewen
5K98

jQuery and RequireJS is really all you need, and since jQuery can be broken down to vanilla JS, RequireJS is all you need.

jQuery is a library. React is a library. AngularJS is a framework. We can compare libraries. The same arguments that say "jQuery and React cannot be compared cannot be the same arguments that say "React and AngularJS cannot be compared" — these claims need more nuance and microcomment.

If your library has no impact on the average size of your files in your source code, then your library is not doing what it's supposed to do. This is why jQuery has the "bloat" problem — because developers fail to understand that the decision to use jQuery involves minimally some commitment to styling code that doesn't inevitably become of a size that makes it potentially but essentially not portable to jQuery, or just jQuery itself, in spirit of its "purpose" or goal as a codebase. Your codebase need not become a library, and it may contain it's own various types of libraries, but if it is all coded as one giant file, the limit on being able to group things becomes a source of code smell. The library itself has no real commitment to avoiding size increases because it should also have a build configuration that enables modular outputs, but *your project* probably doesn't need modality in the way jQuery's build layer does — your front matter needs such provisioning, but probably not your build layer. Though, RequireJS solves this problem for both.

A lot of comments here turn on this point that jQuery and React are incomparable. Why would that be the case if they're both libraries? Why should we call them both libraries if it is the case that they're incomparable but the same class of software?

React: A JavaScript library for building user interfaces

jQuery: Write Less, Do More, JavaScript Library

They're both advertised as libraries, and if it's decided that they're to be used in a codebase, I think a first question, before we claim that certain things can only be done in React, because it is a "car," is perhaps to identify whether or not simply coding style and having documentation and testing are the actual missing ingredients. We probably assume that because all software is becoming more opinionated that the fact that React has coding style and automation, which improves its adoption, that also improve the on-boarding and usability of the wares in question.

I think the exact point of this post is to say, as an implied qualification:

jQuery Is Better Than React Just When You Want To Scale

Or:

jQuery Is Better Than React At Every Scale

I don't want to re-write the author's intention, but this seems to be a problem also with Philosophical Definitions and things like the Categorical Imperative. The gist of most arguments involving Kantian scholars about CI is that there are multiple versions of it, or not, that can be used without qualification notwithstanding a loss a logical or rational force. Same thing here: Can one say — jQuery is better than React and be taken not to mean at every scale or for mid-sized projects or when it's time to scale or upgrade.

In terms of organization — it's not particularly clear why jQuery should be less organized unless one has decided not to adopt a coding style at all, or one takes React's coding style and build configuration for granted. I mean, a lot of what gives React its appeal has less to do with React and more to do with gulp and Webpack, and the fact that developers all over love virtue signaling their full stack prowess, or that they're all doing this at the same time. Fair enough, but generally it's already well-known, and we need more authors like OP arguing this, that whatever React can do, jQuery can do better for all of the reasons we fell in love with jQuery in the first place. (React is just a pattern; if having a pattern, or understanding design patterns, solves your problem, then why not just do that with jQuery instead of adopt React?) It's really satellite technologies and build tools that we've acclimated too, and questions around licensing and centralization of repos (which are questions of power, not trust in the tools, be they React, Backbone, jQuery, Vue, or AngularJS). Plus, there's the problem that Browserify+Webpack will "… have put us further away from the dream of universally understood hot reloading for front-end development."[0] So part of React's compromise is that it's riding on the coat-tails of a limited bundler/build system, which is why Facebook decided to move away from npm altogether. But that doesn't change the fact that solutions for server-side rendering are a completely different matter (a) and (b) R.js enables bundled builds which you can leverage with Cordova. But all of this is getting outside of the question of why React is a library, and why it's not fair to compare it to jQuery.

A main reason, I think, for this is exactly that React was popularized in the context of npm, bower, webpack, browserify, and ES6 transitions and adoptions. So I believe what people are actually saying is "React's history is too complicated to compare it to jQuery, even if they're both called 'libraries'". And how can this be? Tools are being modularized and mixed — we've seen AngularJS combined with React — because React is a library just like jQuery is a library. So here again it makes no sense to claim that jQuery and React are incomparable — they both can be used as plugins within AngularJS. Clearly we can compare the Level of Effort and Integration Complexity between the two under such a use-case. I think most people will quickly say that jQuery is best with AngularJS, but why should that be the case if React is all that it's cracked up to be? Well, then the question of Flux is brought into the question. Now we cannot answer any question about React without considering Flux, Webpack, Browserify, and a whole host of other tools. Does jQuery have that problem? No. Does jQuery have a licensing problem that makes it antagonistic to wider FOSS? No. Does jQuery lack a coding style? Yes. But that's because it's a library. Does React necessarily have a coding style? No, but there's a de facto coding style assuming you fall within a matrix of concerns of (a) wanting to code Facebook apps according to their license and standards, (b) want to code Progressive Web Apps that scale, (c) have no coding style or standards to follow, or (d) actually want to use a framework because neither React nor jQuery are frameworks such that "choosing Flux or Redux" is not choosing a coding style for a framework. Choosing a coding style for a framework is not the same as choosing a coding style for a library.

I guess I have no way of ending this post on a positive point, so I'll just leave with this:

❝There are only two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
— Leon Bambrick

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.