I’ve been developing web based applications for most of my career and the two biggest shifts in JavaScript have been jQuery and Reactjs. For the most part, Reactjs has displaced jQuery, and that has been mostly due to Firefox and Chrome dragging the rest of the browser ecosystem into standards compliance. The addition of functions that performed the most common action jQuery was used for, selecting elements by use of a CSS selector, made it pretty well obsolete a few years ago.

Truthfully though, Reactjs and jQuery have very little overlap. In truth they do very different things. Reactjs is at heart a view layer that aims to not only better organize front-end code but also embraces the event-driven nature of JavaScript and web browsers. In opposition to how traditional applications handled state by forcing the developer to deal with directly, Reactjs forces us to organize our code in such a way that when state changes the bits that rely on that state just straight up get redrawn. The new Hooks api is really just an extension of that idea taken to its logical conclusion, getting away from the direction of forcing an object oriented view of JavaScript design in favor of a more “functional” approach, for better and for worse.

But I’m not going to delve into specifics in this post. I don’t aim to teach how either works or how to use them to build things. Rather, because Reactjs has captured the mindshare of the community, I’d like to make some predictions about what we can expect in the future regarding the fast-paced world that is web development and the trends that are already appearing.

The Current Landscape in Contrast

Ecosystem

Back in jQuery’s heyday, a budding developer could go onto jQuery’s website and peruse the plugins sections for any tools that might be useful. There was even jQueryUI for a selection of tools that could be used to put together interfaces fairly easily. We didn’t have a centralized repository like npm in those days. Git and Github were years away. Sourceforge was the closest to an equivalent to that back then, but it was mostly a wild-west sort of experience back then.

Luckily, the Reactjs ecosystem has matured quite a bit thanks to influence from other sectors of the industry. At this point, if you want a premade component for something it likely exists. If not, then it’s very easy to build a component in a modular manner and there likely exists a set of libraries to help put it together, from the ReachUI libraries for accessiblity-ready UI elements to react-hook-form for easier form handling.

This has been one of Reactjs’ strengths. Where with jQuery the developer would have to micromanage how state was used and abused all the way to the DOM level (and most of the time circumventing how the DOM wanted the data injected), with Reactjs you design your component to handle the state within the confines how Reactjs wants you to. The only major sticking point is really with data that you know will have HTML elements included. In that case, it really is dangerous, and the community has taken the wise position that you should make sure you know what you’re doing wtih it. No such distinction ever happened with jQuery as that was just the norm. So much so that it was actually a performance improvement to build HTML as a set of strings before injecting it into an element directly, bypassing the DOM as much as possible.

Events

jQuery had to do a lot in those early days to normalize browser behavior. It’s interface for managing events was pretty straightforward for the time. However, because of the lack of an overall structure, event handling with jQuery usually ended up with a giant mess of spaghetti code that could be indecipherable and unmaintainable.

Mercifully, normalization of events isn’t much of a concern these days. Events in today’s browsers behave pretty uniformly. And components are by far a better solution for organization, even as the size of a component begins to balloon. Breaking a component apart into pieces is far more straightforward.

AJAX

jQuery was probably best known for making AJAX uniform across browsers. Thing is that Reactjs doesn’t include this within itself. You might use Axios for making HTTP requests or use a GraphQL library for data acquisition. In this way Reactjs is far more focused on doing one thing well.

Looking Forward

jQuery’s days are numbered, and that’s truthfully a good thing. It was a product of its time, needed in its day quite badly, but that time is long gone. It’ll be around a while longer, but it’s more than possible to build good web experiences without it.

As for Reactjs, this is its prime time. Libraries like Angular offer a more complete experience and in some ways Reactjs’ lack of opinion on library preference hurt it in this regard. As a developer, you have to pick and choose the pieces you bring in and knowing those individual parts can be burdensome.

In fact, for a lot of development teams that should be the primary concern. If leadership has strong, educated opinions on tooling they’ll likely be okay, but if not a more cohesive set of tools would likely better serve them. This could change for Reactjs in the future, but given Facebook’s history it’s unlikely.

So Reactjs will likely see a giant shift in the landscape in the web before it goes the way of jQuery. It will likely survive the attempts of Angular, Vuejs, Svelte and others to unseat it from the mindshare of developers. There is definitely a place for competitors though, so while it’ll be king of the hill for a while it won’t be alone and it won’t keep it forever.