What benefits can I hope to achieve by switching from jQuery to react?
8 comments
> but one thing that dissuades me from getting into it is the whole monstrous npm system of components around it.
You are not alone. It is very complicated, but a lot of people seem to get off on the complexity (for some unknown reason).
> Is it not possible to just like include react through CDN with `link` or `script` tags and still make good use of it?
Not with React (as far as I know). But with Vue you can use it straight off a CDN.
Follow this guide through. It take about 15 minutes but it is entirely worth it!
https://v2.vuejs.org/v2/guide/#Getting-Started
> More specifically, I want to know what can I hope to achieve if I migrate from jquery to react?
You can build SPAs (which although not impossible to do in jQuery, is a lot harder). You can also be part of "The React Gang" and get more jobs.
> And to begin with, is this a good idea even?
Not if jQuery is still working for you. If it ain't broke, don't fix it! :)
You are not alone. It is very complicated, but a lot of people seem to get off on the complexity (for some unknown reason).
> Is it not possible to just like include react through CDN with `link` or `script` tags and still make good use of it?
Not with React (as far as I know). But with Vue you can use it straight off a CDN.
Follow this guide through. It take about 15 minutes but it is entirely worth it!
https://v2.vuejs.org/v2/guide/#Getting-Started
> More specifically, I want to know what can I hope to achieve if I migrate from jquery to react?
You can build SPAs (which although not impossible to do in jQuery, is a lot harder). You can also be part of "The React Gang" and get more jobs.
> And to begin with, is this a good idea even?
Not if jQuery is still working for you. If it ain't broke, don't fix it! :)
> It seems to be quite integrated with node when it comes to some react components like next, nuxt or whatever.
I find Next.js to be a hot mess of a framework. Sure, it's nice to have the whole convention by configuration thing to have routable pages and pass path parameters, but the way it mixes server-side rendering with everything ends up building up a gigantic mess of a JavaScript blob that blows up spectacularly when anything doesn't quite work.
To put this in perspective, vanilla React is the epitome of simplicity when compared with Next.js. Truly awful stuff.
> Is it not possible to just like include react through CDN with `link` or `script` tags and still make good use of it?
If by "include react" you mean serve the JavaScript bundle through a static file server, technically it is. However, you'd forego some techniques to prevent cross-site request forgery attacks. So unless you only want your web app do to read-only access to data, you need to implement some server-side code as well.
I find Next.js to be a hot mess of a framework. Sure, it's nice to have the whole convention by configuration thing to have routable pages and pass path parameters, but the way it mixes server-side rendering with everything ends up building up a gigantic mess of a JavaScript blob that blows up spectacularly when anything doesn't quite work.
To put this in perspective, vanilla React is the epitome of simplicity when compared with Next.js. Truly awful stuff.
> Is it not possible to just like include react through CDN with `link` or `script` tags and still make good use of it?
If by "include react" you mean serve the JavaScript bundle through a static file server, technically it is. However, you'd forego some techniques to prevent cross-site request forgery attacks. So unless you only want your web app do to read-only access to data, you need to implement some server-side code as well.
Please don't use React unless the websites you're building would benefit from a reactive JS framework. You're going to have to maintain dependencies, likely ruin your site's accessibility and end up writing code far more complicated than is needed given your requirements.
The reason you feel out of touch is probably because most people who learnt webdev over the last decade basically grew up on React and are now building everything with React without any thought. Unlike TypeScript which was widely adopted by web developers because it's superior to JS, React offers most projects nothing of value and is neither superior or a direct replacement for libraries like jQuery.
If you're building simple websites then you don't need a complicated stack. In fact, I'd even question why you feel the need to use jQuery in 2024... Keeping your stack as simple as possible is a good rule of thumb if you want to build things that require little maintenance and will be around for years to come.
If you're struggling to build the interactivity you need with jQuery, then perhaps look at React. But even then I'm not particularly keen on React as a first option myself. If you're a good JS dev and have good patterns in place you can build some very complicated stuff with Vanilla JS...
I'd also consider other frameworks. I've been doing web dev for about 20 years now and in recent years I've used React a lot, but I hate it. I find it's very easy to write ugly and poorly structured React code. Next.js tries to add some structure, but urgh, I find Next.js far too complex for most use cases and in many cases creates more problems then it solves. In my experience React projects need to have a great team of developers behind them to not end up a total mess within a couple of years.
I think Svelte and Alpine.js are generally better options for most smaller projects which require some reactivity. That's personally where I would look first.
The main reason I think you should move away from jQuery is simply that it's not useful anymore. Back when vanilla JS had limited functionality and poor cross browser support jQuery was amazing, but today it serves no real purpose.
The reason you feel out of touch is probably because most people who learnt webdev over the last decade basically grew up on React and are now building everything with React without any thought. Unlike TypeScript which was widely adopted by web developers because it's superior to JS, React offers most projects nothing of value and is neither superior or a direct replacement for libraries like jQuery.
If you're building simple websites then you don't need a complicated stack. In fact, I'd even question why you feel the need to use jQuery in 2024... Keeping your stack as simple as possible is a good rule of thumb if you want to build things that require little maintenance and will be around for years to come.
If you're struggling to build the interactivity you need with jQuery, then perhaps look at React. But even then I'm not particularly keen on React as a first option myself. If you're a good JS dev and have good patterns in place you can build some very complicated stuff with Vanilla JS...
I'd also consider other frameworks. I've been doing web dev for about 20 years now and in recent years I've used React a lot, but I hate it. I find it's very easy to write ugly and poorly structured React code. Next.js tries to add some structure, but urgh, I find Next.js far too complex for most use cases and in many cases creates more problems then it solves. In my experience React projects need to have a great team of developers behind them to not end up a total mess within a couple of years.
I think Svelte and Alpine.js are generally better options for most smaller projects which require some reactivity. That's personally where I would look first.
The main reason I think you should move away from jQuery is simply that it's not useful anymore. Back when vanilla JS had limited functionality and poor cross browser support jQuery was amazing, but today it serves no real purpose.
You can absolutely host the entirety of your React code on a CDN - in fact, that's the preferred way of doing it. Node is used locally to generate the static resources needed by your app. There is also the server-side rendering approach enabled by frameworks such as Next.js - those indeed run on the server and provide a way of merging frontend and backend development.
To be honest, if jQuery has worked for you so far, it's not clear to me you need to be switching. It's possible your requirements just don't have enough frontend complexity to make the change worthwhile. I'd suggest working through the excellent React docs and building something very simple. If it clicks - great! If not, you haven't committed yourself to support tech you don't need. Either way, greenfield is better, don't jump into retrofitting an existing jQuery codebase.
To be honest, if jQuery has worked for you so far, it's not clear to me you need to be switching. It's possible your requirements just don't have enough frontend complexity to make the change worthwhile. I'd suggest working through the excellent React docs and building something very simple. If it clicks - great! If not, you haven't committed yourself to support tech you don't need. Either way, greenfield is better, don't jump into retrofitting an existing jQuery codebase.
[deleted]
jquery is a client lib, whereas react is a full stack where you can run server-side-rendering, access server services, and in general do everything server-side
I don't think this is quite accurate/precise... yes, with the right framework (like Next), React can do some server-side rendering of components. But that's not the same thing as being a true full-stack framework that can handle auth, databases, APIs, etc. out of the box. React by itself is very naked and would require frameworks/libs to add most of that functionality, but even then, it's not typically as fully-featured as things like Rails or Laravel/Symfony.
On the other hand, you can do most of those things with Node, but that's just Javascript, not React.
On the other hand, you can do most of those things with Node, but that's just Javascript, not React.
An opinion from someone's who been doing web dev since the 90s (and who had to learn Perl and frames before jQuery + Bootstrap):
For me the big one is componentization. For example, take a look at https://mui.com/material-ui/all-components/. It's kinda like Bootstrap in that it's a bunch of UI widgets that you can easily compose into a site. But using React gives you an orderly way of maintaining and sharing state across these components, turning an API response (or several) into a tree of states that can be easily used, modified, and shared across components and pages. The jQuery way of doing that (in the old days, at least) would typically be global vars or else each widget handling its own fetches and data. But it's not easy to pass that kinda stuff between widgets. In React + TypeScript it becomes very simple, once you learn it, to make such a dashboard with loading states, notifications, graphs, popups, etc. all synced to each other.
But, that said, not every site needs that kind of complexity. (And especially not every site needs Next.js on top of React). If you're doing a simple blog, React is frankly overkill and will add unnecessary complexity. These days, you probably don't need jQuery either. Modern ECMAScript is pretty good.
The dislike of React, IMO, is partially because it's designed to solve medium-biz-to-enterprise-scale web problems where several devs have to work together on a codebase of sufficient complexity. It is hard to do that with the code soup of jQuery + Bootstrap because every component (or at least every page) tended to have its own way of doing things. React, especially with a modern framework, tends to enforce a top-down way of fetching state and storing it in some store and then propagating that down to pages and components, which means that each page becomes like a function... you can properly separate its inputs from its outputs. That means one dev can be responsible for the inputs (like an API response, or a structured state derived from the response) while another dev can focus on making/modifying the UI around that response, all without touching other parts of the codebase.
That initial problem, once solved, then created a HUGE explosion of secondary things, like serverside rendering/static building (for performance reasons), package management (NPM, yarn, etc.) for tracking & locking third-party package versions, various state management libs (for really complicated frontends... most don't need anything like that), routers (because React was born in the clientside single-page-app infancy, alongside Angular and other hash-based clientside routers)... but all of those things aren't really "React", just things that people added TO React in order to make it more batteries-included (because they wanted to keep using React, but React didn't have those things out of the box). That's a different, after-the-fact approach vs something like Angular which tried to include those bolts from the get-go (and had an even higher learning curve, and died shortly thereafter).
Next.js in particular is the combination of many of those concerns, rolling up package management, typescript, serverside rendering, etc. into one "convention, not configuration" setup that you can deploy with a single `create next app` command and deploy onto Vercel in 2 minutes. It's an incredible framework for those who need its power, but it's also a lot of complexity for those who don't.
Honestly, if jQuery is working fine for you (and your clients don't need anything more complex), all I'd consider doing is seeing if you can replace jQuery with modern ECMAScript selectors/methods. But there's no reason to jump ship to React unless you have a professional need for it.
If you do (like your frontends are getting more complex), I'd also investigate other frameworks/libs too, like Svelte, Vue, maybe HTMX, etc. and see which one fits your needs the best. The only significant advantage that React has over those is hireability/popularity. It's become the de facto business-scale frontend (way more than the others), even though it's not the easiest to learn or use.
For me the big one is componentization. For example, take a look at https://mui.com/material-ui/all-components/. It's kinda like Bootstrap in that it's a bunch of UI widgets that you can easily compose into a site. But using React gives you an orderly way of maintaining and sharing state across these components, turning an API response (or several) into a tree of states that can be easily used, modified, and shared across components and pages. The jQuery way of doing that (in the old days, at least) would typically be global vars or else each widget handling its own fetches and data. But it's not easy to pass that kinda stuff between widgets. In React + TypeScript it becomes very simple, once you learn it, to make such a dashboard with loading states, notifications, graphs, popups, etc. all synced to each other.
But, that said, not every site needs that kind of complexity. (And especially not every site needs Next.js on top of React). If you're doing a simple blog, React is frankly overkill and will add unnecessary complexity. These days, you probably don't need jQuery either. Modern ECMAScript is pretty good.
The dislike of React, IMO, is partially because it's designed to solve medium-biz-to-enterprise-scale web problems where several devs have to work together on a codebase of sufficient complexity. It is hard to do that with the code soup of jQuery + Bootstrap because every component (or at least every page) tended to have its own way of doing things. React, especially with a modern framework, tends to enforce a top-down way of fetching state and storing it in some store and then propagating that down to pages and components, which means that each page becomes like a function... you can properly separate its inputs from its outputs. That means one dev can be responsible for the inputs (like an API response, or a structured state derived from the response) while another dev can focus on making/modifying the UI around that response, all without touching other parts of the codebase.
That initial problem, once solved, then created a HUGE explosion of secondary things, like serverside rendering/static building (for performance reasons), package management (NPM, yarn, etc.) for tracking & locking third-party package versions, various state management libs (for really complicated frontends... most don't need anything like that), routers (because React was born in the clientside single-page-app infancy, alongside Angular and other hash-based clientside routers)... but all of those things aren't really "React", just things that people added TO React in order to make it more batteries-included (because they wanted to keep using React, but React didn't have those things out of the box). That's a different, after-the-fact approach vs something like Angular which tried to include those bolts from the get-go (and had an even higher learning curve, and died shortly thereafter).
Next.js in particular is the combination of many of those concerns, rolling up package management, typescript, serverside rendering, etc. into one "convention, not configuration" setup that you can deploy with a single `create next app` command and deploy onto Vercel in 2 minutes. It's an incredible framework for those who need its power, but it's also a lot of complexity for those who don't.
Honestly, if jQuery is working fine for you (and your clients don't need anything more complex), all I'd consider doing is seeing if you can replace jQuery with modern ECMAScript selectors/methods. But there's no reason to jump ship to React unless you have a professional need for it.
If you do (like your frontends are getting more complex), I'd also investigate other frameworks/libs too, like Svelte, Vue, maybe HTMX, etc. and see which one fits your needs the best. The only significant advantage that React has over those is hireability/popularity. It's become the de facto business-scale frontend (way more than the others), even though it's not the easiest to learn or use.
But when I keep hearing the discussions here and on other places in social media, they make me feel like I'm stuck in a very different century! There is no doubt that React is a well-known, popular and robust piece of software but one thing that dissuades me from getting into it is the whole monstrous npm system of components around it. It seems to be quite integrated with node when it comes to some react components like next, nuxt or whatever. Is it not possible to just like include react through CDN with `link` or `script` tags and still make good use of it?
More specifically, I want to know what can I hope to achieve if I migrate from jquery to react? I'm quite tied to the jquery way of things right from DOM manipulation to event handling to things like cloning and reusing HTML components in `<div>` blocks. Is there any established guide or path for folks like us to migrate from jquery and react? And to begin with, is this a good idea even?