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.
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?
dbbk|1 year ago
You can just have a HTML file with an SPA that calls API. This is fine.
sibeliuss|1 year ago
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!
sesm|1 year ago
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.
datadrivenangel|1 year ago
te_chris|1 year ago
afavour|1 year ago
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.
kobalsky|1 year ago
it's an incredibly polished server and it does a lot of complex stuff to be so fast, but it's also well documented.
jjordan|1 year ago
logankeenan|1 year ago
meiraleal|1 year ago