7 votes

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?

8 comments

  1. [2]
    Greg
    Link
    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...
    • Exemplary

    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.

    12 votes
    1. noble_pleb
      Link Parent
      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...

      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.

      1 vote
  2. unknown user
    Link
    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...

    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.

    7 votes
  3. Adys
    Link
    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...

    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.

    • React takes care of giving me a structured, easy-to-understand, scalable imperative interface framework
    • Typescript is a very, very strong insurance on how consistent my code is; it allows me to very quickly refactor huge parts of the code which means I am not constantly trying to keep track in my head of what my objects and functions look like, so I am not distracted by those details and feel very free to experiment rather than get things right ahead of time
    • The rich JS ecosystem as a whole means I can very quickly find libraries which fit exactly my use case, and fairly reliably judge their code quality based on how maintained they are.
    • The newer native web interfaces are a breath of fresh air over the APIs of old that needed something like jQuery to keep sane; they're standardized and, when browsers don't support them, usually polyfilled somehow.
    • And if I want to build an actual web app, NextJS just takes all this, adds its own sauce and turns it into a wonderful framework which gives me the ability to create great full-stack JS apps. (I still use Django for APIs though, via Django Ninja, so YMMV there) - And something like Vercel / Cloudflare Pages allows me to deploy all this in minutes, be live very quickly, and have analytics, monitoring and what have you without worrying about infra.

    Really, it's nuts.

    4 votes
  4. archevel
    (edited )
    Link
    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...

    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.

    2 votes
  5. vord
    Link
    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.

    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.

    2 votes
  6. [2]
    skybrian
    Link
    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 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.

    1 vote
    1. Akir
      Link Parent
      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...

      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.

      2 votes