[agumonkey]

yeah early releases made intermediate stuff very lean and fast (as a user), more so than ad-hoc event based vanilla/jquery logic spread around (good luck tracking dependencies).

but I admit something is off with react somehow (and i'm pretty favorable to it usually).

[theturtletalks]

Something seems off because marrying HTML, CSS, and JS is a complex abstraction and with trade-offs. Then you throw in SEO, so hydration gets created. Then JS can be used in the server too so you have to manage both states. Then, users don't want a blank screen, but a loading screen so they know the website is working.

Before you know it, you've created a whole new paradigm that has it's own sets of new problems, even those solved by the original HTML/CSS/JS model.

[emseetech]

I loved React when it first came out. I never got into MVC frameworks like Backbone or Angular because they felt too heavy, but React came as a promise that it was only the View layer and that provided a lot cohesion, as you say, compared to too much jQuery.

But now it just feels so heavy and that the initial elegance has been lost to history entirely.

[goostavos]

>something is off with react

The amount of rope it gave to hang yourself. Hooks were the harbinger of the sad state that what was to come.

The OG React was a breath of fresh air because it introduced the world to immutable data flow. The component model was dead simple. You had a fat (for better or worse) class that served as a management point for your side-effects and IO, then a bunch of stateless transformation functions / components.

The old class + lifecycle methods imposed a much needed friction on the development process. Their clunkiness was a feature (imo). It raised the cost of creating stateful components / performing side-effects wherever you wanted.

Then hooks showed up. In a lot of ways, it feels like React is now rediscovering the bad parts of OOP: uncontrolled mutation and side-effects. "Immutable data flow" means very little when everything is launching side-effects, updating some global store, modifying 12 layers of caches, writing to local storage, etc. etc. etc. etc.

It became a complete nightmare to reason about what an application was actually doing. Most of my experience with React (at least as of a year ago) was debugging performance issues, or UI quirks from component A clobbering updates from component B, because some special GraphQL caching magic modifies some global cache somewhere in some provider, which is 37 layers removed from the code you're actually looking at.

[ramesh31]

>It became a complete nightmare to reason about what an application was actually doing.

And anyone with any kind of software experience knew this was going to happen when hooks were announced. But the community bought it wholesale and dove in head first, so the rest of us were dragged begrudgingly along. I think it's been long enough now to resolutely say it was a bad idea and should have never been pushed the way it was.

[zogrodea]

The last paragraph hits close because I've experienced a similar issue recently. It turns out some component library was responsible for excessive rerenders even when idle (eating up the daily quota of read operations on some database for a small project).

As a stopgap, I just made a completely unstyled alternative to that internal admin dashboard that uses Handlebars HTML templating (no Javascript) on the server. Inclined me towards dependency rejection (which is an approach I was already taking for some side projects).

[JBits]

Would you have any recommendations for someone looking at learning vdom frameworks today?