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.
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.
That sounds 100% reasonable.
Someone noticed it, pointed out it was a big problem for them and enough others it got reverted.
That seems 100% reasonable too.
My controversial opinion is still the same, the less front-end you have in your stack, the easiest you'll be able to scale.
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.
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.
This is such a lazy, grandstandy, unoriginal take.
>My controversial opinion is still the same
It's not controversial it's just tired and ignorant.
Tired maybe but not ignorant since I helped to maintain two React SPAs for 6 years now so I'm pretty aware how bad it is.
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.
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.
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?
Native apps do not suffer from this problem, your binary can add an extra 20mb without much downsides
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).
SPA assets (just like game assets) can be downloaded and cached on demand. They don't have to be bundled at all.
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.
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.
We can agree to disagree though.
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.
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.
My general complaint is the JS ecosystem in general and its tooling.
This is the most popular opinion on HN. If anything, it's controversial to say React isn't a dumpster fire
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).
I’m one of them.