You can just have a HTML file with an SPA that calls API. This is fine.
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!
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.
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 an incredibly polished server and it does a lot of complex stuff to be so fast, but it's also well documented.
RSC is a cool feature, but I'm still not convinced that the added churn of thinking about "colours" when building components and structuring the component tree is worth it for the benefits it gives.
The basic thing I instrumented in my projects was a count of calls to APIs and their total time. Same for DB access. Then push these out as server timings via http headers and see them in chrome.
Quick and dirty way to see what the server call was generally doing.
In addition to adding that to chrome dev tools, I had an extension that would consolidate all network requests for a given page and summarize them. Nice to show various teams how many darn db queries they were doing just to load a page.
Those days are gone. Scale your Next.js RSC app to anything larger than a toy or marketing site and get f'ing burned.
Are you using the pages router or the app router? If you're using the pages router you'll probably be fine.
When it works, it really is easy. But when it doesn’t work, it is absolutely infuriating. Too much magic going on, I guess.
A couple months ago, I was still under the impression that next.js is the easiest way to scaffold a simple site. I even tried hosting it on vercel for ultra-easy mode.
I got some inscrutable build errors that had like the thumbs-ups on an unresolved GitHub issue. So I tried running it from a VPS I already had, and it worked fine!
I would absolutely not use it again though. Vite is great, and if I need SSR at any point I’ll just hope that the tanstack SSR solution is 1.0 by then lol
I've noted a tendency to not log stuff in some js-first devs i know ... they all say 'i'll reproduce it locally'...
But you are of course also right that you can just attach a debugger. That's also called out in the article.
