What advice would you give to someone who has coded in jquery for years and now wants to gracefully switch to modern js?
Title says it all. Bootstrap+jquery has been my default route and path of least resistance when it comes to web development. Perhaps because I'm coding since a long time and belong to the old school when modern libraries like react weren't yet invented yet?
I had tried to meddle with Angular.js 1.0 back in those days but was soon disillusioned! It was cool and cutting edge but highly opinionated. It tried to do so many things under the hood that I soon quit the effort and the word "Angular" was stigmatized in my mind ever since! I don't know how different today's typescript based Angular is but that stigma or phobia prevents me from even looking at that direction!
React is another cool technology which everyone is talking about and I'm sure it has some merits. But I'm not sure exactly what React brings to my development workflow which jquery doesn't already do. Can you tell me some specific advantages or pros of react over jquery which can motivate me to learn the former and let go of the latter? What should I do?
IMO there's one big, fundamental, primarily positive change that's been popularised by React: interfaces are now declarative rather than imperative. This isn't limited to React alone, isn't even limited to JS or web development, but React was definitely the library that brought it to the forefront. For me, this is as significant as the change from manual to automatic memory management all those years ago: it removes a major chunk mental overhead and associated boilerplate from the development process, eliminates whole classes of bugs, and in 95% of cases is only taking control of things that developers weren't or shouldn't have been doing directly anyway. People in that balance 5% generally know who they are and have alternatives available if they need them.
In terms of what that actually means: with jQuery, you write instructions. Page starts in state A; user logs in, change these six UI elements to account for that, now we're in state B; user clicks to expand the comment tree on a post they're reading, append a whole new HTML fragment in the correct position, call that state C; user receives a DM, update the navbar to flag that and show a short floating preview in the top corner, state D; three seconds later automatically hide the preview, state E; etc. etc.
This can be fine for small and relatively static applications, but it gets harder and harder as you scale. Firstly, you need to manually track each possible event (e.g. login success) and its associated UI changes. When you're editing things 18 months down the line, it's very easy to miss one of those six places that the interface should update on login, and now you've got a bug where they're still seeing the "Sign Up" link in the footer - minor, perhaps, but little glitches like that can quickly snowball into more serious problems.
Secondly, and more importantly, you're applying these changes onto an unknown and broadly unknowable previous state. In each transition from A to B to C to D in the example, the exact UI mutations you need to perform depend on what the previous state of the system is, and reaching an identical state D from a different initial state X might need different mutations. You need to manually account for all the possible combinations and edge cases: what if a DM comes in while the rest of the UI is in a loading state and the expected target element isn't there? What if the user navigates to another article after clicking to expand a comment, and the XHR callback gets triggered on a different page to the one that initiated it? What if one of your previous transitions did have a small bug, and now the HTML you're applying a change to is unexpectedly inconsistent? Every instruction needs to account for the impact that every previous instruction may or may not have had, and you as a developer need to keep track of all that as you're coding.
Declarative UI is a direct mapping from data state to interface state. Data goes in, UI comes out. Data gets updated, all parts of the UI that depend on it get updated. The same data object will always return the same UI, regardless of what the previous state might have been. The exact transition from state C to D, or from state X to D, is tracked and calculated by the library - at its core that's what React really is: a diffing engine for UI states. Each element can be coded independently and composed together if needed, only considering the input data, without worrying about mutations leaking from one to another or events getting applied inconsistently.
I'd say the specific tooling you choose is separate to that whole conceptual change. I was never a great fan of Angular, they describe it as a "platform" rather than a library and it always felt inflexible because of that. React is really just a UI layer, and I prefer to have that and make my own decisions on the rest of the architecture, although there are larger frameworks like Next.js that bundle it up into something more complete out of the box if that's what you want. There are also options like Svelte, that figures out all the possible mutations for you at compile time rather than diffing at runtime, or Flutter, that skips the DOM entirely and uses its own pixel level rendering layer.
Excellent explanation, I'll elaborate from a slightly different point of view.
With the shift from imperative to declarative came the now well-developed concept of components. These are much more than templates - they form a tree of objects with lifecycles and affordances for robust abstraction and communication. It's similar to the difference between hygienic macros (Rust/Lisp) and string substitution (C macros).
Before React we had Backbone/AngularJS/Ember/others all taking templates further towards components, but React was the first to popularize components in their modern form, which all the major frameworks use today. This means that if you learn the component model, you can much more easily move between React, Svelte, Vue, Angular, Solid, etc.
On the word "framework", IMO the library/framework distinction can be unhelpful. I consider all of them component frameworks. They organize your code and mind around components.
I'm a biased user but Svelte is my preferred framework. With React you'll be learning more concepts that are React-specific, but it has by far the most helpful ecosystem of resources and libraries.
So-called meta frameworks or app frameworks like Next.js, SvelteKit, and Angular are where I would point beginners, I use SvelteKit which recently hit 1.0. They're both powerful and flexible and make basic usage much easier unless you want to get deep into JS tooling. (most don't, here be dragons)
Thank you for such a lucid elaboration! I'm highly skeptical of new and shiny libraries/frameworks because I've had bad experiences of burning my hands while trying them in past (like the old angular 1.0, for example). But react seems like a very good and stable library, I'll try to include it in my workflow.
I'm gonna be one of those assholes and tell you you don't need jQuery or any of the advanced JS libraries to run modern JS well.
jQuery started as a polyfill of sorts: its primary goal was to make writing cross-browser JS easy, to a point where you absolutely, positively didn't have to think about one vendor's implementation of a particular function over another's. It did so remarkably well, hence its staying popularity even now, when you no longer need it.
JS has been extended quite a bit since the days of jQ, in a way that makes no-dependecies coding a viable choice. (Granted, larger projects may still require a framework to make sense of the infrastructure – something like React – but that's another story.) This write-up of all the features added to JS/ECMAScript (a non-Oracle-associated name for the language/standard) since 2015 sums it up pretty well. It's by no means perfect or feature-complete right now, but as the famous site says, You Might Not Need jQuery.
May I suggest figuring this out first, then moving picking up another framework? Depending on your goals, you might not need one.
It's difficult to convey how incredibly productive a good React workflow is; but @Greg has managed to do so really well.
I am today able to built applications in a matter of a few hours, things that would have taken me several weeks to build in my jquery/bootstrap days, even with more experience.
Really, it's nuts.
Are you just looking to update your skills or do you have another goal in mind? For instance do you have a project that you need to switch to a newer tech-stack for some business reason?
Assuming your main goal is to learn then just get started building! If you already have an app you are familiar with then try rewriting it in new technology X. If you have no suitable candidate, then start with a simple todo app just to get the basics.
As for advantage of newer frameworks over something like bootstrap I think the main advantage comes down to better tooling. Typescript + react + webpack is quite enjoyable to work in. There are still some gotchas, but the main workflow is quite polished IMO. Comparing it to working with jQuery I think the main adjustment is to accept that it is much more opinionated. With jQuery it's quite easy to just flip a class on some DOM element to achieve some visual effect. In react land you'd likely achieve the same thing by rerendering a component. Mostly I'd argue this is a benefit, your less likely to take shortcuts I'd the tool pushes you away from that. OTOH it can feel a bit wasteful sometimes.
FWIW Angular being highly opinionated is one of the main features.
A hiring manager looking for an Angular dev can expect the new dev to be productive much faster.
I haven't kept up with web development, but I got into it again last year and found the combination of Preact and esbuild to be pretty good for a small app. I never liked Angular much.
I don't know anyone who genuinely likes the original Angular framework. I remember trying it out early on and the documentation on it was pretty horrible; it had a tutorial that you could theoretically use to learn how to use it but it was fairly useless because it didn't actually explain to you how or why what you were doing to make those changes. I'm sure that the newer versions are much better but I'm still not going to give them a second chance if I can avoid it.
Beyond that, I honestly don't trust Google for frontend work these days. About 80% of websites with UI problems I come across are Google properties.