I'm so done with React. Since Vercel kidnapped it everything is done for/because of their platform and their interests. Most evil company I've seen in a long time.
The article says that React was about to make a change, the community pointed out it had bad trade-offs, and React backed off. What does that have to do with Vercel? Where's the problem with React here?
Vercel is a (more?) opinionated ecosystem that influences higher adoption of Server-Side-Rendering and other features. This encourages projects to use more niche APIs like Suspense, and due to the capital, marketing, and bearish adoption of Vercel products by vocal parties (startups) - will influence React's developers to cater to them.
I'm agnostic because I quit full stack web development ~6 months ago. I think the product development story sucks and combined with the market economics of the current tech industry is just not fun or profitable to invest my career in.
It's -probably- a good thing that stuff like SSR becomes mainstream/required. But I really don't like that one of the main entities behind it, Vercel, has raised $563M as of their latest Series E as they steam towards an IPO of their Framework/Cloud offerings.
So they made the choice that worked well in the mega-scale application they tested with and performed worse with the pattern they didn’t think was too widely used/would be much of a problem. And it would make planned future features easier.
That sounds 100% reasonable.
Someone noticed it, pointed out it was a big problem for them and enough others it got reverted.
Sadly, many products require sophisticated frontends, the FE is often a core part of the value proposition. React may be overkill in smaller cases, but it's a good tool in these cases of complex dynamic UIs.
Exactly. Things like LiveView (Phoenix) are changing the game somewhat, but if you need a sophisticated frontend, React is still a good way to go. PWAs in particular I think still have a lot of promise, even if they are being (intentionally) stifled by tech companies that have competing interests and want web apps to be as impotent as possible.
For simple frontends that don't need to be complex UIs, I definitely don't turn to React (I love simple tried-and-true templating systems like ERB and/or EEX), but I definitely think React has it's place. Not everything should be SPA, but that doesn't mean nothing should.
Heavy use of interactivity is hard. React makes it maintainable. It was hell before.
I've been working with React (and RN) since it came out and I've had nothing but good experiences, especially compared to the previous decade before React.
My motto is local-first, the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do.
Move everything to the client, especially the database. Let the database do the syncing. Plus you get offline and undo/redo basically for free. Pagination? Fuggetaboutit.
The more stuff the client does, the higher the payload is going to be and the more complex the bundling and tooling will be.
I'm in a company with around 100 devs now and I can certify you that front-end SPA do not scale at all unless you throw a insane amount of devs hours in the tooling, even then it barely does.
That's not mentioning the insane npm churn that you have to maintain, the testing story which is pretty abysmal outside of a few top libraries, the typescript tooling which is eating so much ram that I'm changing my laptop.
And I'm not sure why you mention the pagination as a plus where it's one of the big downsides of the front-end stack, there's a lot of hacks to make it behave okay in most situations.
> I'm in a company with around 100 devs now and I can certify you that front-end SPA do not scale at all
What is the difference between SPAs and other monolithic architectures, e.g. on desktop, that makes it so?
Why can’t you go with OSGI-style plugins, for example? Loose coupling, separate SDLC and deployments etc?
The reason it works fine in a native app and not on a browser is that the browser streams documents over the network. It's pretty much the worst place to download large payloads on demand.
Native apps do not suffer from this problem, your binary can add an extra 20mb without much downsides
Native apps do network downloads of comparable or even bigger size too. I do not see how this can be an argument in SPA vs MPA decision making. „Rich client“-server architectures existed long before SPA became a thing and on much slower networks, so pretty much every problem modern SPAs face, from UX to performance to change management, was already solved by someone. Isn’t it actually ignorance of JS frontend community which has reinvented many wheels in rather ugly way, that causes the trouble?
It's fine to stream 20mb in a browser as long as it's not part of the core JS.
Browsers can handle many GBs of storage. You can even store them via OPFS directly on the native filesystem if supported. There's also Chrome File Storage API and if all else fails IndexedDB (which is more limited, but works decent for synced databases).
This isn't the use case of an SPA though since those extra megabytes would end up in the bundle, this is more like a game. Ironically I would agree that games are better suited to the browser than SPAs because you can afford to wait, you use wasm and you don't have to reinvent the wheel of the basic browser features.
I'm aware of that, that's why I pointed out the insane complexity of the bundler tooling. Splitting in chunks isn't a solution, it's adding fuel to the problem.
Not really, it's just a solution to the need of complex apps and the need to support the ability to load pieces of the app without having to download and install it like a native app.
Native apps can do similar things with dynamically linked libraries, and there's a lot of complexity when it comes to compiling native code.
The web bundler tooling really isn't that complex nowadays, especially with Vite. It's one file usually 10 lines long. It can use SWC and LightningCSS, written in Rust. They're safe, fast, and require minimal config.
I'm also aware of those, that's exactly what we're using in my company. It's a power hog, so much so that I had to change my laptop to run the SPA properly. The local experience is absolutely terrible since it has to disable the bundling to use hot reload (at least that's what I guess is happening) and each browser reload takes >1min to load.
Then there's the complexity of the caching in continuous deployment, we literally have a custom metabase dashboard to make sure the caching isn't too bad and lasts a few days.
Then the default config doesn't scale either as you can guess and we have our own.
There's a reason I have this opinion, I know what I'm taking about, I've been using all those tools and they add a lot of complexity to your app.
The reason it works on an native app is because loading a dynamic library is essentially free, it's just stored alongside the binary.
That's exactly what I meant by "not scaling". Sure if you have much less developers than us and you don't make 100 deployments per day, maybe an SPA can work. I can assure you that when you need to support a complex product, it absolutely doesn't scale at all, even with some developers full time to try to fix the stack.
Our full bundle itself is close to 70mb and still growing every week, that's absolutely insane.
There's a reason why Vite has a default bundle chunk warning of 500kb.
There's really no reason it should be that large. If you just lazy load each route your chunks should distribute into manageable size pretty much automatically.
It sounds like you may also have a bunch of dependencies. Which can happen in a native app, but in a web app as you know you'll have limited resources so size is important.
You're all over this thread saying "We couldn't scale it, so you little plebs certainly can't." I'm sorry it didn't scale for you, but it's telling that you think your experience is THE experience. Facebook uses it, I think your company of 100 devs could scale it fine, as many do.
> Heavy use of interactivity is hard. React makes it maintainable. It was hell before.
Agree, React is great for UI interactivity.
> ...the more stuff the client does, the cheaper it is to scale and less bridging between the server you have to do.
Disagree. The most costly form of scaling is people. UI + business-logic + data-modeling + data access (ACL) all held in async client concepts is a complexity nightmare in my experience. Even for my team-of-one side-projects.
Server <-> client bridge is a feature for managing complexity over time. I may agree that added ceremony could make 95% tile app experiences default harder. But for anything that's not a toy, the #1 risk is always team/people/communication complexity.
average HN commenter: React is artificial complexity, you should be able to make any website using jQuery and plain HTML, because that's what I did when I last did front-end development in 2007.
also average HN commenter: If you use Python for your backend you're a moron, you need to use Rust so the API calls for your 0.5 requests/sec web app finish in 100ms instead of 125ms (note: 99ms is waiting for the database).
No one is saying that. People are starting to realize is that JavaScript frameworks are an unnecessary complexity to web application development. People have been seriously turned off by things like angular and react, and with good reason. With the advent of things like hotwire and htmx those JS frameworks are no longer strictly necessary, and many people welcome the news that their importance is fading away.
I've been maintaining React SPAs for 6 years now so I absolutely know what I'm taking about when I say that it doesn't scale. I experienced all the pains of the js ecosystem.
