Honest Question: What benefits can I hope to achieve by switching from jquery to react?
I'm a freelance coder who builds small-medium apps and my front-end stack primarily consists of Bootstrap+jquery. This combo has never let me down until now even with all kinds of features, functionality and complexity thrown at it. I've built dashboards with line charts, puzzles and MCQs, grids and tabular components to edit data, etc. and it was all very seamless.
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 doing 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?
React's big thing that makes it different from jQuery is that it's immediate mode UI. You have your data, and then you generate your DOM elements as a representation of that data, and you do it again if the data changes (with optimizations to not remove and reinsert elements that didn't change). This lets you do things like conditional rendering of an element without having to explicitly write code to show/hide it; you just say
if (shouldShowTheThing) { <div>thing!</div> }and React reruns that when the inputs to that component change. (Read "component" as, approximately, "function that takes some data and returns some DOM nodes".)There are places where this is a great fit, and places where it isn't. The modern React All The Things trend is probably excessive.
Sure it is. People do that sometimes.
The build step is because React supports an extension to JS syntax called JSX. But it's just syntax sugar for
React.createElement()calls, and you can just write plain JavaScript using those if you want.I'd say: Try multiple frameworks, and see how they feel. I've done Angular, React, and Vue (and jQuery, for that matter), and it was obvious Vue fit me best, and was easiest [for me] to work with, and very straightforward. That may not be the case for you, but I'd recommend that you try some, and see what happens. Other, lesser-known options: Svelte, HTMX.
I had tried angular in the 1.x days when it was called "angular.js". The whole experience was so pathetic, it seemed that getting started was easy with those
ng-*tags and dependency injection but it soon got buggy and complex when you tried to do something little more non-trivial. It seems you couldn't use any javascript library for charting, etc. without "Angularizing" them first which was a very deep science! I soon lost taste for both angular.js and trying of JS frameworks in general after that!I'm generally not one to defend Angular, but, in its defense, it improved post-1.x. React is easier, but Vue is easiest (IMHO). Least confusion and frustration.
I think you're confusing npm with node. You do need to use some kind of package manager that hooks into npm (which can be many things these days, e.g yarn), but that's disconnected from node. And to be honest, you're going to have to use npm packages for any non-trivial JS project.
React does have synergy with node based server deployments because you do server-side rendering, but it's not necessary.
Not doing this:
I use NextJS at work, which is a framework that is based around React. Honestly even with all the stuff we’re doing right now I could totally get away with using jquery. But a major reason for using React is that it’s what we can hire for in San Francisco. If the company is successful we’ll need the modularity as well.
In the meantime I’m really loving Typescript. I use it on the front and back end. That means I can share types across the API boundary, ensuring the two parts stay in sync. This largely removes the feeling you otherwise would have where it feels like you have two completely different code bases.
Since I feel my comment may have contributed to you feeling this way, I should probably add some additional thoughts here.
I understand the desire to avoid node/npm and just load libraries directly. There's so many different technologies now that it can feel overwhelming. But it's important to remember that tools are there to help you. If you have a problem, a tool likely exists to solve it. That tool adds complexity to the process, maybe by introducing a dependency or build step, but it also makes your life easier in other ways. It's up to the developer to decide if that tradeoff is justified.
Before we get into it though, I'd like to ask a question: are you using jQuery standalone, or jQuery + jQuery UI? You've talked about building dashboards with line charts and tabbed interfaces. There's a number of popular jQuery UI plugins such as DatePicker and Tabs that you might be used to, and I wonder if that's what you're trying to replace. If so, while there might be React components that perform similar tasks, that's not really the end goal of React. I might suggest looking for newer libraries instead such as Chart.js, or even implementing native solutions where feasible (eg. tabbed UIs can be done with no/minimal JS).
It's probably best to stop thinking of React as an upgrade or replacement for jQuery. If anything, jQuery has been mostly "replaced" by vanilla JavaScript. jQuery was never bad, but it's best features have now been adopted into the standard JS library so it's just not as necessary today as it once was.
React and jQuery do very different things. jQuery implements a unique API for selecting elements, acting on them, and performing certain tasks like network requests. It's more of a library that sits on top of your application, and you can call in to it for helper functions. React meanwhile is a larger framework for component-based design. It uses a custom templating language called JSX, and one of the most useful features is data bindings (sometimes called Signals).
Using a component-based framework is useful in a lot of ways. It lets you compartmentalize your logic and display into smaller chunks, keeping things readable without turning into interconnected spaghetti. It encourages more explicit APIs and reuse of data, which is great when working with a team. It also allows for reusable components to be shared with others online.
The thing to keep in mind though is that React, or similar frameworks, are not suited to every project. While they may reduce your code's complexity in the long run, there is a higher upfront technical cost. It often means integrating node, a local dev server like Vite, and using some sort of bundler/packer to convert the site from "React" files to pure HTML and JS. There will be dependencies and build steps. If you wish to integrate server-side elements like Next, that also adds additional complexity.
If you're building a simple app by yourself, there's often no need for this complexity. Using jQuery or even just vanilla JS is perfectly fine, and usually more performant. I typically start new projects this way to maintain lower complexity. But not all projects are simple, and sometimes "frontloading" the complexity by building on a framework like React can be better in the long run. The actual application code will often be more maintainable, and easier-to-understand at a glance (due to enforced conventions). So it's just a matter of choosing the right tool for the job.
I will note however that newer JS APIs do require a local web server anyway, so it's likely that some sort of local dev server will be required either way. I often use the integrated Python3 web server for this purpose.
A lot of people are suggesting React alternatives like Preact, Vue, Angular, and so on. I would say don't worry too much about it yet. Most of these frameworks accomplish the same goals, and even though they accomplish them in different ways, their designs are largely converging on the best practices discovered through years of use. If you learn any one, your skills will be mostly transferrable and the concepts will be familiar.
Now with all of that said, I'm not sure I'd recommend you learn React at this time. Based on your posts, I think you would be better served by first catching up on the foundations of modern JavaScript. I would spend some more time with ES6. Learn
fetch(), arrow functions,.map(), destructuring, and promises. Test out modules and strict mode. I think you'll find that modern JavaScript affords many of the conveniences that you once derived from jQuery.Once you're more comfortable with some of the newer ways of doing things, it should be a lot easier to pick up newer frameworks since they often rely on these ES6 features as part of their design. That will give you a better onramp for React, or any other modern JS-based tool you wish to learn.
Thanks, my post wasn't directly inspired by your earlier comment, the transition to newer ES6 paradigm or way of doing things is something I have in mind since a long time. As you said, I think exploring ES6 in some more detail will be far more productive for me at this point than getting into react directly. I think most open source projects have already moved towards that way and I don't think getting stuck in the past will be much use.
I don't use jqueryUI a lot, I rely on the underlying Bootstrap framework which provides most things out of the box like styling of form inputs, panel and card components, navbar and tables, etc. Occasionally, I have to use libraries like chart.js and fullcalendar.io for advanced use cases. I try to avoid jqueryui or plugins as much as possible in order to "future-proof" myself for the ES6 ways.
Presently, I use a local development server provided by PHP (
PHP -S localhost:8080) or even thepython.httpserver module in some cases. I've experimented with node and express "hello world" few times, even written this http live simulator as an exercise once. But I don't know how to integrate the react JSX thing in this toolchain, is there any good guide or reference on how to do it the right way with best practices? I want to practice this on the side to get a taste of how it works before making the whole paradigm shift.Previously, the standard way was Create-React-App (or CRA), which downloaded the dependencies for you from NPM. Nowadays it looks like React encourages you to use a "React framework" (sorry for the overloading of that term). They are projects that build on React to handle additional problems like routing and server-side rendering/hydration. I think this is overkill for a starting place however.
You can still use React without those additional framework features, and the best way to do that is probably with Vite, which I mentioned above. It's a development server that also handles all the rollup/build steps out of the box. It supports plugins for common frameworks like React and Vue.
If you just want to dip your toes in, I'd say download Vite, and use its guided install process to set up a basic React app. It should provide a basic Hello World example, which you can then experiment with from various online guides/resources.
I'm not a React developer myself, so unfortunately I won't be able to answer any further questions in that area. But take it slow, and try not to get discouraged from the hodgepodge of different tools/names. A lot of them are just iterations on previous ideas, so once you understand one thing, it helps you better understand the next thing.
This is a minor nit pick, but Next is probably less complicated than the alternatives given it is more “batteries included”. The installer will get you ready to write code in seconds.
That's fair, and you're right that "batteries included" does often mean an easier onboard. Though I'll argue that it also means that there's more complexity under the hood, and at certain points the developer does need to start making decisions and implementing the solutions made available by the framework, even though they don't really have the necessary context for that yet.
I'm a believer in the idea that you need to understand a problem before you can understand the solution. For example, if you haven't run into a situation where you have had to keep lots of DOM elements in sync with browser memory, then you probably won't see the value in data bindings. Or if you haven't created an SPA with components acting as "pages", then you probably won't understand why a routing library is helpful to you.
Once you've come across these situations, the tool's purpose just clicks. Oh, it lets me use the back/forward buttons, and the URL updates! That is useful. But until that point, it's just a bunch of words. Routing logic, bindings, hydration? You can follow a guide and everything will seem to be working, but you just don't have the context for what these things are actually doing yet.
That's why I recommend a more bottom-up approach. Start by identifying a problem, learn the tool, adopt it into your workflow, then move on to the next thing. It's slower, and I can see the argument that it's more complicated, but I really think this approach gives you a deeper understanding into the why as well as the how.
Of course at some level, a top-down approach is necessary too. You can't exactly teach kids to use computers by first soldering microchips. But for development, I think it's the better approach. I see a lot of cases of bootcamps churning out people that only know React, but don't understand any of the basics of how websites actually work. To them, it's all just magic under the hood.
I don't mean this specifically as a knock against Next. I haven't even used it, though I've heard good things! I just wanted to address the topic from more of a pedagogical angle.
I use Preact instead of React. It’s quite similar to React, but it’s a smaller and simpler library.
The problem with using a CDN is that you can’t use JSX without a build step, so you don’t have the nice syntax for embedding HTML templates into your JavaScript file. But it can be done. Here’s the getting started page for Preact, which explains how to use it with no build tools.
I couldn’t really say how much benefit you’ll get out of it. Maybe try it out and see if you like it?
Compared to jquery, the difference is that you don’t update the DOM directly. Every view is rendered as an HTML template. When you want to change the screen, you do it by causing the template to re-render with different data. For example, an event handler will change state variables. Preact will notice this and re-render. The library takes care of preserving any view state (such as whatever the user entered into a form field.)
I'm interested to hear what others have to say. I'm in a similar boat at work, we use .net core mvc pattern and jQuery/vanilla js to manipulate dom, handle ajax, etc. We use lots of razor syntax and generally get along quite well with this toolkit, but I've been watching job listings for a while now and I definitely feel like I'm putting myself in a hole by staying with how we currently do things.
The thing is though that react/angular/whatever just doesn't seem to have upsides compared to how I handle things in my projects. Our projects aren't rapidly changing in a way which would require backend or frontend overhauls independent of each other so the API pattern just doesn't have an upside for us that I can tell.
I'd love to be swayed, I don't want to stop learning but I'm not going to overcomplicate things for the sake of it.
It depends how much dynamic interaction there is on the site. The problem React tries to solve is that, if JS is managing a significant amount of a site, that DOM manipulations become a) horribly ugly and hard to reason about b) quite slow, because DOM operations are expensive.
With React, you can define the components declaratively, have a clean flow of state from top down passing between pure functions, fallback to redux when needed for complex state management, and minimize the amount of actual DOM calls you make.
For a simple widget, it's not important. If you're making google docs, it's pretty important to have some kind of framework.
I guess our webs are too boring to see the benefits. We have a lot of business logic and the front ends are typically CRUD, sprinkling in validation and modals and very little in the way of dynamic controls like a site like Google docs or Outlook 365 or something crazy like that. Most of our heavy lifting is all server side.
Still, it makes me wonder if the demand for things like react are overblown, a lot of jobs I look for are for similar roles that I currently have and from what they're describing they do, it seems like they wouldn't be benefiting from using angular or react over just using razor pages or blazor etc.
For a company, there's many reasons to start a new project with React. One is just the labor market; it's relatively easy to find React developers. You can throw them an OA to verify their experience, and get a baseline level of expertise in what your codebase will be in.
Second, is that the structure React gives vs cowboy JS changing DOM elements left and right is very helpful when you have a codebase that will have to be worked on by many people, and will have to outlive any particular developer. React is much easier to reason with, whereas literally any code anywhere could have made a DOM manipulation. If a widget is in an illegal state, well, we're working with global mutable state, so it could be anything. If it's React, then check the component for that widget.
If you are already using razor, you could also look into Blazor. I've been working with it for a bit now (Blazor WASM), and I am quite happy with it so far.
This is kind of where I'm at with it. I learned Vue but am rusty at it now because there's just not been any project I felt was complex enough to call for it. Likely the most complex one recently was creating an Amazon-like search/filter/count adjustable-length paginated listing of arbitrary data with arbitrary CSS (for use in listing large quantities of people, services, directory info, etc.). Vanilla modular JS with an event bus and classes that defined the DOM output and behavior of UI elements in consistent ways and standard JSDoc documentation inlined took care of it no problem. Everything's nicely organized, nothing about how it works is complicated, it's got thorough docs, zero dependencies, and weighs practically nothing. Plus it doesn't blow up if you're using a text browser or screen reader, so that's a plus. You just take absolutely any repeating DOM elements filled with whatever data you like and styled however you like, pop some data-attributes on them for filtering, and give the library the CSS selector to find them and it does the rest. To develop on it you just need to know vanilla JS.
It rarely gets more complicated than that at work. I've used frameworks in some personal projects and it was neat, but even there I often felt like I was using them just to use them, and cleanly-written vanilla JS would have done the trick just as well. I think the cutoff would have been if there were a significant number of UI pieces that users were generating/moving with their own input versus just a UI with only a few changing spots that I already had all the data for and knew exactly how it would be presented. Or perhaps if I was working with people I couldn't trust to write/edit vanilla JS in a safe, performant, and standard manner.
Edit: I guess technically it has dev dependencies like JSDoc, Gulp, gulp-minify, gulp-prepend, and gulp-rollup, but those are really just to bundle up the modular JS (which still works fine without rolling it into one file, but who wants to make all those requests), slap an incrementing version number on it, and spit out a nice documentation package.
It’s been a good decade since I have had to do any hard-core frontend web work, so take this with a caveat.
If you are looking for skills for your resume, learning React is probably the way to go. If you are just looking to incrementally upgrade some knowledge, there is something to be said for writing plain JavaScript files and not having a compiler behind your app. Old school angular 1 can replace query for a ton of use cases, and you do not need to use it as a single page app. It’s also darn old but slightly newer than good old jQ.
The resume part really depends on youe location. React seems to be way more popular than Vue or Angular in the US, while nj the Netherlands Vue, Angular and even Laravel and .net seem to be about as popular if not more so from what I've seen.
I would say the Shadow DOM is not that useful. WebAssembly and Canvas are much more interesting and performant technologies.
Given that you work freelance I think it makes sense to stick with jQuery for as long as you can. But given React's popularity I'm sure you'll be forced to work with it at some point. Alpine.js might be a good stepping stone between jQuery and React. There are some good ideas from both worlds in that small framework
Reading through these comments, I don’t think anyone actually answered whether you should consider the switch.
I would say no.
If you are doing freelance work for smaller projects, you’ll be better served by using what you’re comfortable with so you can have a higher output. The long tail of SMB (small & medium business) clients who need a relatively simple site or app are absolutely not going to know a difference (and probably shouldn’t even be aware or care).
Your job is to make something that fits their needs as fast as you can and move on (well, don’t discount maintenance contracts, but you know what I mean - you deal in volume).
It may be time for you to start exploring a more modern look, if your bootstrap stuff has the same look it did fifteen years ago, but I’m sure either new Bootstrap themes or Tailwind help you there.
And I’m actually excited to see what jQuery 4 is going to bring, too! Sure, a lot of stuff is now just as easy in vanilla JS as in jQ 3, but the team knows that, so we’ll see how v4 revolutionizes jQ.
Now of course there’s nothing wrong with learning something new, but I would definitely advise against using it in a real project while it’s new to you, because it will sneak up on you and steal your time, meaning not only will you fail to meet deadlines, but you’ll also fall behind with other clients, and end up less profitable.
Not exactly an answer, and I'm not the most qualified as I don't have much experience with jQuery, but I personally love Angular because there's almost a well-documented right way to do things which is standard and followed. Obviously projects don't always follow the guidelines. Still, there's a noticeable benefit in team projects when there's consistency in expectations from the framework itself. Certainly, people still write bad code, but you really have to fight the framework to write unmaintainable garbage.
I'd assume React has some of the same benefits, though my understanding is it comes with fewer tools and standards (and is more permissive for better and worse).
I am in a similar situation as we still use jQuery, bootstrap, and a few other libs for our sites. I tried out React and I just didn't find it was solving problems that I had and wasn't worth all the tooling and adding build steps to our process. From a resume standpoint, it may be worth making regular use of React or one of the other popular frontend frameworks. If you're going to go for it for this reason, I think it would be wise to go all in and embrace the tooling (npm, yarn, etc) as that is what most jobs are going to expect you to be proficient with.
You answered your own question: continued employment. :-)
I think I last used jQuery over 15 years ago.
I've been learning React on the job for the past several months.
It makes front end work very similar to programming ( more enjoyable for many ) and less like web design/arts & crafts ( non-derisive use ).
Does it have increased value? I can't say. Things that would be simple the old way can be time consuming in React. Perhaps the payback with React comes with very large projects.
Again, the value of being employed is enough. I almost never hear jQuery talked aside from the context of legacy tech.
I've been fascinated with Single SPA, though it is hard to find a lot to read about it. It COULD be the next big thing. It sure is fun and fascinating.