Comment by josephg
17 hours ago
> React is a relatively well-designed library that isn't really that bloated.
I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior. But it leaves the question of why react is still so popular. I think the biggest reason is all the non-technical aspects of react:
- They have excellent documentation. And have, from day 1.
- They produced videos, sample projects, and all sorts of "getting started" documentation.
- They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP.
The amount of hype around it made it really feel like the next big thing. Between the very well funded react team and the outside developer community, there was real momentum. People learned it in droves. Taught students. Built websites with it. When react's poor design choices caused issues (and there were a lot of issues), then you were blamed for holding it wrong. (Component classes, state, CSS, hooks, webpack and babel taking ages, big bundle sizes, slow re-renders, and so on.)
By the time the next generation of JS frameworks broke onto the scene, there was a collective moan from the community. "Oh no, not again - we just relearned how to make websites." React was the wave, and in its wake we all had Framework fatigue.
Software doesn't get popular without a lot of work by dedicated people. I really admire the work standards bodies do. But they rarely bother to take the time to produce documentation, videos, tutorials, starter projects, blogs and podcasts and all the rest of that work.
> pretending like they invented FP
More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary. The creator of React, Jordan Walke, was big into OCaml and one might even say he got some of the ideas of React through working in OCaml, so much so that he tried to bridge both by making ReasonML which is an alternative syntax for OCaml which has JSX and React bindings.
> More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary.
It doesn't seem all that different from doing your rendering in the WM_PAINT handler, which was already how things were done in the ancient Win32 API (although it's possible [0] to draw outside WM_PAINT).
[0] https://learn.microsoft.com/en-us/windows/win32/gdi/drawing-...
As a web developer in 2014 when I first heard about react, I had never heard about WM_PAINT as I was not a Win32 developer.
1 reply →
Yeah, there's a lot of people who have either forgotten or never knew that the context React came into was a world full of JQuery and AngularJS two-way bindings. I started my internet touching career having to work on that stuff, and boy, so much of it was a nightmare that just got endless workarounds heaped on top for basic performance issues, let alone other complications.
There really isn't anything in react that is inherently "bloated", most companies were indeed using it wrong, or at least in a naive way. Over-reliance on useEffects, re-render issues, non-memoized components etc. When used correctly, react 18 provides really fast web apps on whatever scale (small one pager app to massive enterprise apps).
> most companies were indeed using it wrong
If everyone is using react wrong, react has a design flaw. Other frameworks aren't slow by default.
React is very similar to PHP in this regard. PHP has (had?) several major design flaws, and yet it became the default for people with less experience.
I don't think that React is as problematic as PHP ever was, and also frameworks like Laravel have improved the PHP experience tremendously, so there is now a way for less experienced people to use it.
IMO: the problem here is pretending that everyone has an innate right to use React right when it's clearly a library that works better when people have a bit more experience than the average web dev.
We as an industry tell people "don't do your own crypto, it's hard to get it right". We don't blame crypto for being hard, or demand new frameworks. Same for things like assembly, C++, Rust, formal proofs, writing an OS, operating BGP infrastructure, etc.
But with React it has to be "kid gloves on", otherwise it's shit?
This is perhaps a bigger problem in our industry: lack of experience is not seem as an individual problem, and we blame-shift, blame marketing, blame Facebook, Dan Abramov, trends...
Perhaps we should be saying "React is not for beginners", same as "don't do crypto".
5 replies →
> If everyone is using react wrong, react has a design flaw.
You're asserting that everyone is using it wrong. It's your personal opinion, and a baseless one at that which is based on a personal belief that everyone around you is incompetent and incapable of critical reasoning. It's silly posturing.
In the meantime, React is by far the most popular web framework in production. Some surveys list React with a market share of between 60-75% of all web frontend projects. It's so popular that it even leaked into GUI programming with native GUI toolkits.
It's rather obvious that assertions such as yours are detached from reality. Naturally the dominant framework will also dominate the number of newbies taking their first steps as well as drive-bys. It's also natural that the dominant framework will be targeted by the "aktually" crowd, invested in contrarian self-promotioj comments instead of doing anything constructive.
But to assume everyone is incapable of using something... That takes a lot of self delusion.
4 replies →
If most people can’t use it properly perhaps the problem is in react itself and not most people. React is the only framework that will blame the user for its own mistakes.
I haven’t found a front end library I like more than React except maybe Astro.
I didn’t really like Svelte and I am pretty opposed to htmx. It is certainly better than Angular and Vue, though Vue 3 is tolerable. Maybe there are more popular options nowadays but tbh I am not really looking to move from React. I have zero complaints other than maybe the push towards server rendering and partnering with Next.js
React is simple and I like that it feels a bit like FP. I love that I can write just about my entire application in TypeScript with all of the benefits that incurs. It requires some knowledge/discipline e.g. around useEffect.
If you care to use native browser APIs and features you can have lightweight, performant applications that behave well in the browser.
Most devs don’t do this, even with vibe coding. It’s a very easy way to filter for those who care about what they are building.
I have to step in here to say that, at least documentation wise, this is revisionist history.
The original react documentation is fine, but focused almost entirely on class components. What was there on hooks was either outdated or outright harmful.
It's not until 2023, 4 years after react hooks launched, that the new react docs which focused on them were released.
React has an incredible ecosystem, it's almost synonymous with web development. The available render backends alone, namely React Native, are currently unbeaten.
As interested as I may be in the alternatives, they simply don't have this.
Alternatives might not need this though.
What about NativeScript?
> I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior.
I don't really think that React is necessarily the best possible library, but there is certainly more to a UI library than simply compiling out the need for diffing. For one thing, I find JSX to be a relatively unobtrusive addition to the language. It is implemented by a variety of things and is a pretty simple transform as far as things go; basically pure sugar, it's possible to avoid it if you want. It could be better designed than it is, but I think it's at least sufficiently general - it is feasible to say, use an alternate library with JSX, like Preact.
Svelte on the other hand by its nature just simply requires a more complicated compiler step to work and deliver on its promises. That's a trade-off. Whether you think it's worth it is up to you, but presenting it as an objectively technically superior design is disingenuous. Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?
> The amount of hype around it made it really feel like the next big thing.
We are a really long way away from the hype of React. I would argue that hype stopped carrying React a long time ago. Momentum? Sure, but if something was truly dramatically better, then I think it would have a fair shake at beating out React.
The problem is that the web isn't microbenchmarks and developer experience does matter to some degree, so the trade-offs that seem so good on paper don't always pan out.
I'm not a hater of Svelte. On paper, it is a very elegant idea. However, when I actually tried to use it, I genuinely came out feeling that it was simply not for me, and the benefits it has are not enticing enough for me to continue experimenting. My React apps are not particularly slow or bad at handling huge amounts of data. (One of my apps has no problem handling a file grid of over 1 million items, and in fact, I run into issues with browsers not being able to handle a large enough scroll area long before performance of my React code is a problem. That is good enough for me.)
I should probably be more balanced when criticising react. React moved the state of the art forward when it came out. Compared to the other options we had at the time, it was excellent. But it's not better now. At least not for technical reasons.
> Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?
Virtual dom diffing is pure overhead. It increases the JS bundle size (react is big). Vdom diffing is really slow. And it's simply not necessary.
I agree that if you make heavy use of comparator functions, react apps can feel ok to use. But most sites don't do that. Look at the new reddit site. Insanely slow and insanely inefficient. They've improved it a lot since the new design landed. But it's still 19mb of javascript or something, and much slower than it should be. Maybe reddit is only slow because they're holding react wrong. But if everyone holds react wrong, it's react's fault.
If you don't like the asthetics of svelte, check out SolidJS. Solid is aesthetically almost identical to react. Solid - like react - only needs compilation if you're using jsx. The difference between solid and react is that solid only executes component functions once. Reactivity is implemented via fine-grained signals. Solidjs apps perform better, because there's no vdom. The default way to use solid is already fast.
> if something was truly dramatically better, then I think it would have a fair shake at beating out React.
Eh. Lots of old technologies are still in use. Most software engineers don't enjoy learning new frameworks every few years. And react still works fine, even if there are other options today. I think solid and svelte are better, but they might not be better enough to displace react for the average web developer.
If you like react, give solidjs a try. It's essentially "react with signals", which I find to be a significant improvement. You get much smaller JS bundles, better performance and better state management. All while keeping a lot of the best parts of react's design philosophy. It's great.
I don't think React pretended like they've invented FP, and I've always heard them be pretty open about FRP work existing in the past and them leaning on it.
I mean, prior to React the big Framework at the time was AngularJS 1 - a hellscape of two way data binding.
Talking about one-way data flows was an excellent way to speak to a lot of tortured souls at the time (who had just found out they were going to be forced to migrate their projects to something else anyway due to Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").
The first time my team uses AngularJS professionally, we spent a month to learn the framework, then the velocity and quality were good. The client reported a funny "bug" that the loading icon didn't show, it turned out the async request was too fast that they couldn't see to loading, a fresh experience for them at the time.
> Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").
Angular 2 came out in 2016, without the two way binding design issues of AngularJS. Google ended support for AngularJS on Dec 31 2021, so there was 5 years of overlap between the two. They even had migration paths that allowed AngularJS and Angular 2 application code to live together from the initial release of Angular 2.
They announced that AngularJS was being rewritten in 2014 with no obvious migration path and didn't release Angular2 until 2016.
That was 2 years of "well, everything you write will be legacy"
> They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP.
When you have to resort to outright lying about something it's usually a good sign your argument is flawed.