> I'm not sure if this effects other frontend frameworks as much, but it does seem like React was always pushing for a "new way to do things" every year.
In my experience, it purely depends on how you regulate the code internally. You can always find developers using something shiny every week when you already solved the problem the shiny thing solves like 100 times in your codebase. I had the same problem with some random integration of Blazor recently in a .NET codebase. Some had the same problem (apparently, I came later) integrating Primefaces to a JSF codebase.
It may be amazing tech, but do you really need it if you can KISS without it?
I am only half joking when I say that most developers would say yes due to Resume Driven Development
The whole idea of React performing a bunch of tasks in the background and updating everything when it feels like is just all a bunch of silly magic. In fact, my state of JavaScript 2021 would be pretty damning, but because of the libraries used instead of JavaScript (like React and TypeScript), not because of JavaScript.
React presents a simple view of the world, but in doing so, you now have no idea what is actually happening, and you need to know that. This isn't like an array in JavaScript that is abstraction of an array in c that needs memory allocated and new arrays created and so on. You don't need to know how that works other than that the JavaScript version is a bit slower and you accept that. You need to know how all of the stuff React hides actually works to create your program.
In terms of hooks, there are so many "rules". Instead of seeing an API, the API is moved into the documentation and not visible in the code until run-time when you get one of the many errors like not adding a dependency to a hook, using a hook outside of some specific area, etc, etc. It isn't JavaScript at all, so you no longer have the tools of the language to freely use to make your life easier.
1. Escape hatches are good. Designing an API is hard, and supporting every use case within that API is harder. Providing a way to make sure you don't get backed into a corner means you can continue building things.
2. State updates -> View updates seems perfectly reasonable to me. I don't think I've ever wanted a view to use a stale piece of state in one section and an up-to-date piece of state in another.
3. Reconciliation is just React's way of saying "we are trying to make things fast." I generally don't have to worry about how this happens while I'm building things: I can just build things. A library that let's me focus on business logic rather than boilerplate or implementation details is one that I want to continue using.
4. "Thinking in React" I put into two buckets: The first is easier to grasp, in how to reason about state (propagating down in one direction) and how to keep things in "React" land (don't manipulate the DOM directly, React won't "know" about it). The 2nd is in the API, and I'll admit does take some time to get used to. Lifecycle methods I think can be learned faster, but knowing the lifecycles around hooks also can be learned, of course. Plus, the abstraction and co-location benefits of hooks outweigh the learning curve IMO.
5. The [rules of hooks][1] that React provides is just two items, hardly overwhelming. The actual API of hooks (e.g. the need for a dependency array, return function from useEffect to cleanup on unmount, etc.) is larger and takes longer to fully grasp, but being able to have a linter catch a large chunk of these is a good thing in my book. Plus, no library is without its footguns. In the jQuery days there were plenty of times I'd forget to remove a listener, create race conditions in ajax stuff, etc. Learning a library's API is just that, its API. You are writing in Javascript, but of course no one is saying "the idea of dependency arrays is 'Javascript,'" although that concept definitely appears in other computer science / programming fields.
React is the exact opposite of that. Endless boilerplate, abstractions and unwritten rules. As the reality of large projects sets in, they look nothing like the starter examples.
Actually, I create a library github.com/thebinarysearchtree/artwork which I use but haven't documented for public use. You can probably see some earlier versions of actual components in the history with the initial commit. I think I created a login component or something. The essential concept behind it is that html is no longer necessary in a component world, where everything is broken down into little pieces and spread out inbetween loops and so on. Removing html and having access to the live dom elements, and using modern JavaScript and dom API features is now a better alternative than all of these ridiculous libraries that are just variations of React or Vue or insane with their own compilers and virtual doms and god knows what else.
>State updates -> View updates
state updates -> query updates
state updates -> url / history updates
>A library that let's me focus on business logic rather than boilerplate or implementation details is one that I want to continue using.
From my experience, these implementation details are important. The library I use is less code than React and shows the implementation details so you know what is happening.
>The [rules of hooks][1] that React provides is just two items
That definitely isn't correct. It is missing the warnings about dependencies, where async methods can run, and a lot more. There is a list of eslint warnings somewhere. There are a lot of rules of React and hooks and the different types of hooks and they are all in the documentation and not visible in the code. The order of your setState calls is important, you can't use async in certain places, the state has to be assumed to be stale unless you do setState(a => a + 1) etc. It is quite frankly ridiculous. There is so much happening that is all hidden in magic.
Bluntly, I think it is all complete garbage that is more complex than it should be and there are now so many people writing incompatible React instead of standard JavaScript that works for everybody. I just find it hard to believe that there is anybody who has written a large project in React and has come away with any conclusion other than that React is complete and utter garbage. It is a failure and it will not stand the test of time. The only people who could think otherwise: have some kind of cocoon set up by a large tech company and they basically just write demo code all day, or they haven't worked with React long enough.
My library, which I have used to rewrite a large application with, is less code, faster, and easier to understand. I proved that React is complete garbage to myself by doing that.
At some point you need to accept the underlying stuff just works and build on top of existing layers. That's what DHH calls "conceptual compression" I think, and that's also how science works. Building everything from scratch so that you understand it doesn't work, specially in a business context and usually ends up in worse home-made frameworks.
I don't think I'll be looking to work in a react codebase in the future again. I don't know what was wrong with class based components, especially the lifecycle methods, they were so easy to understand/read. But almost every react codebase is now a combination of classes/hooks or 100% hooks which imo is so messy/unreadable...
When I will be looking for a job change I'll definitively look for angular only jobs (or even better, backend only)
http://mikehadlow.blogspot.com/2014/12/the-lava-layer-anti-p...
Depends. Angular is the same old solid brick you can toss towards your enemies since 2017 or so. Vue has had at least one major breaking release, but there's a migration path, so it's not impossible to transition(although I know of one instance where the team opted for not doing that because of uncertain estimates).
But none of them have this goldfish-memory-like attraction to the new and shiny.
