The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.
Unless I'm selling a render solution, I don't want to be maintaining a render solution. Maintaining glue code might suck, but writing everything from scratch limits the scale of the work that a person can accomplish. I liken it to polishing gears rather than driving the car.
It's people that think electric motors are always the right solution to every problem and it's only a matter of rube Goldberging it up to shoehorn electric motors in to places that that's better without them.
It's against arrogant dogmatic rose colored glasses fanboyism being mistaken for software engineering
And this isn't straw-manning, the internet is full of these evangelists that exist as effectively marketing arms, as if they're bicycling around wearing nametags on behalf of the Church of Current Day Frameworks.
All it does is create messy piles of tangled garbage that wastes people's times and gets thrown away to be rewritten when the next flashy thing comes around. It's hot fashion for programming
It's gross and needs to stop. Seriously. Let's build the future, help fix the world's problems and quit fucking around.
This fetishism for shiny things have left us impotent executioners of meaningful change and thus we are amidst the tech stagnation
The implication was that we're in a transition like that presently.
Not saying it will never go away, just that, maybe the front-end world has finally, significantly slowed down in churn. Things could always be better (Svelte is nice) but overall, React does what I need and I rarely curse at its design.
From jQuery’s release to 2014 there were multiple phases of front-end frameworks.
Backbone, Knockout, AngularJS, Ember. All of these had their time in the light during that phase. Most companies were already switched over to one of these frameworks. React was the new kid on the block at this time.
You Don’t Need jQuery was out well before 2014.
It’s also a bit difficult to compare jQuery since it’s a library that can linger in a codebase indefinitely. It’s not a framework.
Also jQuery release date was 2006, so the equivalent year 9 would be 2015. By which point React migrations were in full swing. I wrote my first on the job React + Flux application in 2014 and then joined a new larger company in 2015 where we were making plans for a React migration.
So did jQuery, and that google framework used to create Gmail, what was it called?
Oh yeah, nobody cares anymore because they're irrelevant in 2022.
Even if the React development team would stop the framework will for sure be around for a couple more years and receive at least security patches.
My opinion of each of those parts has been primarily down to the developers, not the underlying choice of framework.
Things that work in production last.
React has too many sharp edges, it'll only be here until something shinier supercedes it.
It’s a mature, stable technology, still in wide use - and not really a competitor with react. That you claim it’s “no longer interesting” says more about your own preferences and ironically makes it sound that you are personally interested in the newest shiny fads - so I’m confused, what is your objection to react then?
Angular isn’t exactly dead - and is a more apt comparison.
Edit: 3,700,000 downloads per week on npm alone. That’s not a complete or perfect representation of usage, but that’s a significant number
I suspect people still reach for jquery for similar reasons. They know it makes complicated stuff work, it’s reliable, they don’t need to think about the specifics of the problems it solves… As a result, they’re less likely to discover that it’s no longer necessary in the first place. They’ll just keep using it.
These mostly come down to
1. It’s no longer the fastest, in fact it’s barely competitive speed wise with many things that have come after it.
2. It’s architectured in such a way that it is fundamentally misaligned with the rest of many web standards (I.e the DOM) which made a lot of sense when it was released but is now a major liability.
3. It now has to ship around a lot of code that now lives natively inside the browser and is now rather bloated as a result compared to newer iterations such as Lit as mentioned in the article.
Personally, I think it’s fatal in the sense that they have painted themselves into a very specific corner with no obvious engineering solution to get them back on the standards path. Its problems as a result aren’t really fixable without major architectural changes that would fundamentally change the project. On top of that they are only going to get actively worse over time as more things get moved into the browser and they are still stuck shipping a bunch of JS code to do the same thing. In short they are on a bad long term path with no clear off ramp.
I wouldn’t start a major project in React in 2022 for something I wanted to be around in 5 years from now as a result.
A similar thing happened to CoffeeScript: no one uses it anymore because nearly all of its good ideas made their way into JavaScript itself.
I don't find many sharp edges in day-to-day React work. I say this having once been a very strong proponent of framework-less frontends, before trying Vue, then Svelte, and then settling on React.
And this isn't an issue of me not understanding React or hooks, I would consider myself to be as expertly acquainted with hooks as it's possible to be.
Now, do I still use React for everything? Yes. Do I prefer hooks to class components? Also, yes.
Okay I can criticize React and its weird solutions until the cows come home, but this is a pretty weird one because it’s entirely an implementation detail. No one working with Suspense ever needs to know that’s how it works unless they’re building a library to be compatible with its behavior. Otherwise it’s just trivia.
Admittedly, I haven't tried debugging React 18 yet, so I don't know if that actually happens in practice.
Hooks are called every render, which is a relatively transparent process that happens all of the time. All hooks have to be called every render, otherwise you're breaking the rules of hooks. The reason why is because the only way hooks know which hook they even are, is the order in which you call them.
For example, if I have
const a = useRef(true);
const b = useRef(false);
Then there are all of the closure problems with useEffect and useCallback that I see people really struggle with.
And useState...lordie. The fact that it defers setting the state value, whereas useRef will immediately have its value updated. Deferring useState has caused so many bugs.
The programming paradigms I like best are declarative and make invalid or undefined behaviour impossible to represent. Hooks do the opposite: they're procedural, make it very easy to write a program that compiles with subtle errors, and don't have compile time checks to stop bad code.
I still see it on resumes today.
> that google framework
Seriously, Google stuff is infamous for being smothered by Google itself, what's your point
> nobody cares anymore
Literally the only non-Google example you could think of is still popular. But jQuery wasn't a graceful idea with a strong implementation, it was a wrapper to alleviate the pain of browser APIs. React is a wrapper to alleviate the pain of JS. Thus my original claim: "[a] world where React isn’t used and remembered is one where the web isn’t based on the same primitives". I don't see that happening soon.
Web components were proposed 11 years ago. Widely available for at least six. When will it stop being "early days"?
Now all the air in browser development has been sucked out of the room by them. Instead of actually moving the web forward browsers are busy patching holes and problems created by web components because they are horrendously badly designed.
And they still have an issue list as long as the equator. Any framework in such a state in "early days" would be laughed out of the room.
Custom Elements weren't available until 2018. So unless you are referring to the chrome-only experimental v0 version, I don't think you can say it has been widely available for more than 4. And there will likely be substantial improvements to it before it starts dominating web development.
Yes, my timeline was off.
> And there will likely be substantial improvements to it before it starts dominating web development.
I'm definitely veering away from my original statement, but here goes :)
There won't be any substantial improvements in web components. It's painfully obvious how many shortcomings they have, and how many holes have to be patched before they can become actually useful. I mean, they had to come up with a whole new Javascript API just to make them participate in forms.
And now their existence taints and poisons most other improvements to the platform. For example, Scoped CSS (which on its own would solve a huge chunk of what web components offer) now have to be twisted to accommodate web components, and will likely be a worse spec as a result.
Chrome "developer advocates" will incessantly berate and gaslight other projects and frameworks, and will claim that web components are a success because companies with billions of dollars in revenue and thousands of developers use them to create a yet another avatar or breadcrumbs component. That... that is neither success nor a path towards any substantial improvement.
"It's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1] And the future is likely to be component-less [2]
If the tens of millions of dollars that Google alone has poured into Web Components had gone into something meaningful like https://open-ui.org we'd have a significantly better and a substantially more future-proof web. Alas.
[1] https://twitter.com/Rich_Harris/status/1513668040784814084
[2] https://dev.to/this-is-learning/components-are-pure-overhead...