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.

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.