React is holding me hostage

Not sure I understand your point, can you elaborate?

My point is that updating the state for a single element causes React to compute the state for the whole page, and diff the whole page virtual DOM against the whole page actual DOM, before pushing the update of that single element into the DOM. With pure JavaScript, you can skip all that and directly update a single element. This is often in practice much faster.

JavaScript brings together so many paradigms, I can see strong cases for multiple different expressions of the language.

We didn’t have classes until ES6. And they’re not real classes, they still use prototypical inheritance under the hood.

If you want truly idiomatic JS, you shouldn’t be using classes. You should only be writing functions, and build your class-like objects with prototypes.

On a practical level, I absolutely recommend new engineers learn React. The job market is enormous, it’s a skill the market still rewards well.

And it’s a very productive framework. It rewards you for learning it, with better collaboration and velocity.

I would say the same for the other major view frameworks too, but React still has the biggest job market.

Until ES5, the industry thought JS was a Frankensteinesque monster.

Until maybe 5-7 years ago, anything that wasn’t OOP was considered a bit weird.

Calling any of these languages weird, is like policing English speech. We borrow so much from other languages that’s words have multiple meanings. Pronunciation follows contradictory rules, and regional dialects can be hilariously incompatible.

There’s a few languages closer to French, which has a strict control on what the French language is. For example, Go. There’s really only one paradigm them, only one way to do things.

Like it or not, pushing the boundaries of language design and framework design is how we improve as an industry.

You can’t not like a new thing because it’s weird at face value. You risk missing the forrest for some moss on a tree, and being left behind.

And sorry, that’s the same article this comment thread spawned from. I didn’t find it convincing at all, it’s let down by a lack of understanding in a few key areas.

They’re not the same statement. Both are correct. But as always, the nuance is critical.

All declarative code eventually runs something imperative.

And anything non-theoretical is going to have side effects somewhere.

Painting to a screen is a side effect.

Reading a file is a side effect.

Software gets messy when it intersects reality.

But, we can do quite a lot by staying in a theoretical realm. You can build a whole UI in the theoretical realm, where no side effects exist.

When you actually need to run it though, you drop out the the theoretical and into reality. Now there’s side effect’s everywhere.

So you contain them. Encapsulate those side effects into composable blocks. Test them extensively. Offload that work to someone who’s just focussed on managing them.

Updating the DOM is a side effect. Making a network request is a side effect.

Contain them, test them, and then you can stop thinking about them.

If someone else has done all the work to contain side effects, you can build a UI without them.

I have a few problems with React hooks.

1. I’m not sure what they have in common with each other. What exactly is a React hook. Nearly every hook is its own thing, with its own purpose, use, etc. With the new “use” hook, even the original hooks rules don’t apply anymore.

2. Related to the above, every hook is an entirely new concept. Learning react you would think once you learn “hooks” you will be able to understand basically what they did. Much like once I learn “classes” or “functions” I can figure out what they are. But every hook is its own concept, with its own rules, and gotchas, etc. Sometimes I wonder if the reason they’re called hooks is to present them as a single Concept, otherwise it would be too obvious that React replaced a few concepts, state, and component lifecycle, with about 3-5 concepts in the library in the early versions, and many more now, with an infinite possibility of concepts through custom hooks.

3. No one in the React world seems to have a clear mental model of what hooks are. useEffect is the most egregious here, but the name (and the original React docs) indicated it was for side-effects. But then it’s also used for lifecycle management. Finally, it appears that now the React devs have started pushing the idea that it’s to keep “components in sync with an external system”. And useEffect is probably the most used hook outside useState.

To be fair, usually descriptions of concepts can change with time. But with useEffect it’s not just the description that’s changing. It’s the entire mental model, which makes it seem that the React devs themselves are not clear what useEffect is supposed to be.

Fundamentally, hooks seem to be a bunch of ad-hoc solutions that React devs use to solve specific problems they notice in the wild. But there doesn’t appear to be any fundamental consistency to what they really are.

Rust, which is the greatest new hotness in the backend world is from 2015.

Other major languages in the backend world are at least 2 decades old (C#, Java, Python, C++, Ruby, etc).

C# with the .Net framework is an interesting example. Microsoft realized their original windows only approach was a dead end. They created .Net Core. But someone moving from .Net framework to .Net core didn’t have to relearn much at all, beyond initial config/bootstrapping, and which subset of the APIs had been implemented, because MS completed the implementation in stages.

On the flip side you have React, where you’re ostensibly using the same library for a decade, except halfway in between they made a change which completely flipped how developers weee supposed to use the library.