Hacker News Reader

Comment by benbristow | Hacker News Reader

How is using jQuery more satisfying and productive than using something like React?

You spend 10 times more time writing so much more code having to make the UI 'react' to the changes that you wish to see.

With React/Vue/Angular it's just a case of adding a conditional.

With jQuery you've gotta do something like

jQuery('.this').hide();

jQuery('.that').show();

jQuery('.thisotherthing').show();

Gets really confusing, hard to test and hard to maintain.

Then when you want to do things with fancy selects and dynamic option choices and all that good stuff it just gets even more unruly.

With modern JS frameworks you declare a state and your UI reflects your state. Rather than with jQuery having to manage both the state and the UI all at the same time.

I'm forced to use nothing but jQuery at work so I'm quite competent with it so it's not from lack of experience. It provides nothing but pain and misery.

View on HN

Eh. "10 times" is certainly possible, but it's not inevitable. Maybe the strongest load bearing statement in the GP is "If it ends up sucking, it's because I made it suck."

> With jQuery you've gotta do something like jQuery('.this').hide();

Sure, at some level, you're going to have define a relationship between your data and some display element (`jQuery('.this')` above), mechanisms for managing presence & visibility among other characteristics (`.hide()` in this case), and wiring that to state.

React is a set of shortcuts and conventions for doing this. It's a decent solution and saves on thinking about how to organize code for this task, and more important saves on bad thinking about how to organize an application (a savings that multiplies the larger the team working on it and range of experience within).

But it's certainly possible to write plain old JS (augmented with jQuery for convenience, if you like) where you define that relationship between your data and display element and accompanying mechanisms once and all the data->UI flow is encapsulated in functions where you don't worry about DOM specifics.

There's some marginal increase in verbosity, and you have to be the person who enforces the conventions (which is usually where this falls down), but OTOH, you get a little more control over how the semantics of your application are encoded. YMMV.

For the example above, you could collapse to:

$('.this, .that, .thisotherthing').toggle();

Or if you're looking to throw in a conditional, toggle takes a boolean argument:

$('.this').toggle( foo === undefined );

Really it depends so much more on whether or not you're designing a single page app or have some interactive elements on an isolated webpage. Use the correct tool for the correct job.

Actually didn't know toggle took a boolean argument, cheers, I'll probably end up using that.

But it's not just that. You've got to account for stuff like updating classes on elements, updating text (e.g you might have a dropdown and when you change that dropdown it updates a summary bar), managing configuration of various components on a page (like options within a select dropdown, available dates in a date picker) etc. etc.

All becomes a lot easier using something like React/Vue and they even throw in dev tools to make it easier furthermore.

This is the good old imperative-vs-declarative debate. jQuery is "(I think) I know what the current state of the UI is, make these changes", React is "I need the UI to be in this state, you figure out how to get it there".

In my experience, with jQuery you spend a lot more time making sure each and every event handler puts all UI elements in a correct state, often repeating yourself or calling the same helper functions. With React, all that computation is concentrated in render(), making it easier to reason about. And if you need to add a new UI element, reviewing all jQuery event handlers will again be a lot more work.

Of course, this assumes you are working on a real SPA with a lot of dynamic state, not on a reddit clone where all you need is a reply button to hide/show a textarea and a hidden field to track the parent post id.

Sometimes you just have a single element to show/hide on an otherwise static or very simple page. It's satisfying to make that work in minutes with just a couple lines of code, which you can craft/tweak in your browser dev tools console if you like.

If that's the case, then document.querySelector works like a charm.

So what you are saying is that if you want to show/hide something dynamically on the webpage you should use React? lol

Also, maybe it is from lack of experience. Because you can add classes to your elements and depending on them you can hide/show all of them with just

  $('.toggle-element').toggle();

Well it gets more complex when there’s more business rules. Like if you have 1 checkbox checked need to show this one bit but if you have 2 need to show all of them. It’s just an example.

Trying to scope it all gets a bit unruly too. Your example would target every element on the page. If you have nested components it’s a nightmare.

Reply on news.ycombinator.com