Indeed. "Oh but SPAs are so complex!" Folks are completely and utterly brainwashed by Vercel's marketing.
Pondering an SSR rendered SPA with a wildcard route that calls `React.renderToPipeableStream` (or even simpler, uses `react-streaming`) and some `import()` statements sprinkled about, dropped into a tiny vite config: OMG! a handful of lines of code. Such complexity! Such slow performance! and massive bundle sizes!
Capture the market, complexify everything, then overcharge for hosting. Thanks Vercel. Love your docs!
> What exactly does it improve over lets say PHP or Rails
Uses the same code to render on server and in browser, enables moving render logic from browser to server and vice versa without doing a complete rewrite.
That is greatly compensated by the low quality of the generated code. Vercel's landing page for example takes 12 seconds and 1.4mb of files to load just a bunch of text.
Difficult question to answer because it's difficult to know what you're asking. What is "it" here? Next.js? OpenTelemetry? This specific implementation?
PHP is a programming language, Rails is a framework. They're quite different propositions. What you're seeing here is equivalent to poking around in the guts of Rails, which assuredly has plenty of complexity hidden inside it. I personally have a negative reaction to this amount of stuff in a project but I feel similarly about Rails.
Next’s big “thing” is one codebase that runs both on the server and client. That introduces complexity where you might not expect it. But a Rails app and a totally disconnected JS front end will also introduce complexity, just a kind you’re more familiar with.
It's far too much magic for my taste. I'm really looking forward to the first non-beta release of Tanstack Start. It offers many of the same advantages without the overkill.
I don’t think this answers the parent question. Database queries still needs to be made and a view still needs to be rendered. What complexity does next.js solve?
> Uses the same code to render on server and in browser, enables moving render logic from browser to server and vice versa without doing a complete rewrite.
However, the next question is, does it solve these without adding needless additional complexity of it's own?
I can't help but feel, while I'm using it, that surely it shouldn't feel this overengineered and unintuitive. I mean, I like React, and I understand it well, footguns and all.
I feel like there might be better solutions out there - even using React - and if it wasn't being heavily promoted by a large corporation then something else would be in it's place.
Also, how much of the functionality of Next.js (Image component processing, for example) is designed to funnel you into using Vercel rather than being genuinely the best solution?
in our case it solves performance, it actively keeps cache warmed up preventing it from ever serving a stale page or serving a non cached hit, preloads content for fast navigation, optimizes images, it's lightweight, scales horizontally, it's stable.
it has all the bells and whistles the big boys have, for free, you almost don't need to think about it, just follow some guidance.
while people say it's too much magic (there are 4 cache layers), you are always free to pop up the hood and read the documentation, which is excellent.
You can just have a HTML file with an SPA that calls API. This is fine.