> The library has a gigantic developer share..
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.
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.
React has too many sharp edges, it'll only be here until something shinier supercedes it.
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.
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.
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.
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
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.
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.
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.
A similar thing happened to CoffeeScript: no one uses it anymore because nearly all of its good ideas made their way into JavaScript itself.
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.
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...