There's a disconnect between how a computer wants to do things and how a human wants to do things. This disconnect isn't so noticeable on the backend where the problems are generally related to scaling (as there isn't a generalized solution). On the frontend though, this disconnect is everything. This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules.
This leads to a loop of unrealistic optimism.
1. Library X promises to abstract everything away in an easy-to-use way
2. Devs adopt X and it makes work fast and fun.
3. The human element forces in tons of edge cases.
4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things.
5. Devs start looking for an abstraction that works and goes back to the first stage.
I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years.
Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later.
If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous.
The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all.
I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs.
DRY is a means to an end rather than an end in itself.
> This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules.
This exists everywhere. But the churn only exists in the NPM section of the JavaScript world. QT, SDL, GTK, Cocoa have very stable paradigms to do UI. Even the DOM api is stable. But in the NPM world, nobody wants to actually stick to an API, instead they insists on supporting edge cases that should actually be an extension or another library.
Like a challenge to write better code that is still bad enough to throw away as soon as possible, I think there's something to scripting that feels enticingly ephemeral.
This leads to a loop of unrealistic optimism.
1. Library X promises to abstract everything away in an easy-to-use way
2. Devs adopt X and it makes work fast and fun.
3. The human element forces in tons of edge cases.
4. Devs hit the abstraction limit and start needing elaborate workarounds to do simple things.
5. Devs start looking for an abstraction that works and goes back to the first stage.
I'd note that a decent portion of this loop is powered by the explosion of FE devs. There were probably just a couple hundred thousand frontend people when Chrome launched in 2008 (and most of them were design guys rather than programmers). Today, there are millions and most of them have been programming for just a couple of years.
Devs (especially senior devs who make architecture/library decisions) and their managers need to realize that there is no panacea. Fast time to market followed by slowing development speed is expected. It seems like every blog brags how "we rewrote 80% of our app in 3 months" but seldom mentions that they are still at just 95% done 3 years later.
If you started with React in 2013, you'll still be using it 12 years later (11 years if you were using Vue). If you stuck with Redux, you'll still be using it 10 years later. If you used basically any of the abstractions layered on top of these basic libraries, you have probably been through several rewrites none much better than the previous.
The key is not abstracting too much. Repeat yourself just a little more and you'll find the edge cases easier to deal with and changing something basic in 5 files is easier and faster than trying to wade into a single very complex component and change something. You'll find that lots of those abstraction libraries you were using aren't actually buying you much at all.
I should also mention Typescript. Basic types are a great resource. When you are spending hours wrangling your complex type soup to fix something you know can be solved with just one simple change, this is an indicator your types are hurting your project. These types are almost always a reflection of your abstraction and indicate that you are abstracting too much. These types also indicate your code is highly polymorphic and will have terrible performance on modern JITs.
DRY is a means to an end rather than an end in itself.