4 ms·

The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to

The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to show a dynamic site is a recipe for bad performance.

Griffinsauce 6y ago
Isn't SSR (or even better SSG) the M in JAM? It's a marketing term anyway and it doesn't really need to "lose", we can just talk about the technologies instead. Next.js gives you a great toolbag to choose from for each challenge, it's definitely going to stay around and keep growing like crazy.
- k__ 6y ago
  I thought so too. JAMStack is Next.js with SSG+CSR.
- stevebmark 6y ago
  I believe the M is static HTML, not dynamic SSR HTML
eyelidlessness 6y ago
I would also prefer something like Next.js with partial hydration. But what I want in that is probably a much bigger ask: I want the partial hydration to be performed automatically with static analysis. Something like Svelte (real DOM codegen, no need to ship a library to the browser) would be especially nice, but I don’t want to give up JSX. In the end, this is probably well outside the scope of a framework coupled directly with React, and I suspect that if I want it badly enough it’s something I’ll need to build myself.
- stevebmark 6y ago
  I'm not sure if we're saying the same thing, by partial hydration I mean only wiring some specific client side components for interactivity. As in only shipping the react components over the wire that need to be rendered on the client for user interaction. Meaning the overall page is vanilla HTML, but some subtrees are React wired components. Complete with state management that can work between all of them. In which case I'm thinking it would be fine to mark components individually as server/client.
  - eyelidlessness 6y ago
    Yes, that was what I meant as well. But as I’ve read about the approaches currently available, all of which require manually opting in per component, I’ve had two thoughts: 1. Manually marking a component for hydration likely means shipping the whole structure below as JS, which may hit diminishing returns fairly quickly. 2. At least if you’re using TypeScript, enough is known (or could/should be) to determine which components are truly static. Next.js already has a rudimentary version of this. That kind of analysis could be a huge DX improvement.
gherkinnn 6y ago
You can use much of the J and the A during the SSG stage that then delivers the M to the user. And very user-specific and/or dynamic things will have to remain some sort of generated shell and the content fetched on the client anyway. JAM has other problems. I don't think that's one.
esistgut 6y ago
I am currently working on projects with Django (jinja2), Laravel (blade), Node (ejs) and Next. I can't possibly understand how so many people in this thread are preferring server rendering frameworks. As soon as you have a non hello world application (= complex state shared across multiple components / page) a SPA application is so much easier and productive. And Next brings this experience back to public facing frontends because it supports prerendering along other things.

Griffinsauce 6y ago

Isn't SSR (or even better SSG) the M in JAM? It's a marketing term anyway and it doesn't really need to "lose", we can just talk about the technologies instead. Next.js gives you a great toolbag to choose from for each challenge, it's definitely going to stay around and keep growing like crazy.

k__ 6y ago
I thought so too. JAMStack is Next.js with SSG+CSR.
stevebmark 6y ago
I believe the M is static HTML, not dynamic SSR HTML

eyelidlessness 6y ago

I would also prefer something like Next.js with partial hydration. But what I want in that is probably a much bigger ask: I want the partial hydration to be performed automatically with static analysis. Something like Svelte (real DOM codegen, no need to ship a library to the browser) would be especially nice, but I don’t want to give up JSX. In the end, this is probably well outside the scope of a framework coupled directly with React, and I suspect that if I want it badly enough it’s something I’ll need to build myself.

stevebmark 6y ago
I'm not sure if we're saying the same thing, by partial hydration I mean only wiring some specific client side components for interactivity. As in only shipping the react components over the wire that need to be rendered on the client for user interaction. Meaning the overall page is vanilla HTML, but some subtrees are React wired components. Complete with state management that can work between all of them. In which case I'm thinking it would be fine to mark components individually as server/client.
- eyelidlessness 6y ago
  Yes, that was what I meant as well. But as I’ve read about the approaches currently available, all of which require manually opting in per component, I’ve had two thoughts: 1. Manually marking a component for hydration likely means shipping the whole structure below as JS, which may hit diminishing returns fairly quickly. 2. At least if you’re using TypeScript, enough is known (or could/should be) to determine which components are truly static. Next.js already has a rudimentary version of this. That kind of analysis could be a huge DX improvement.

gherkinnn 6y ago

You can use much of the J and the A during the SSG stage that then delivers the M to the user. And very user-specific and/or dynamic things will have to remain some sort of generated shell and the content fetched on the client anyway. JAM has other problems. I don't think that's one.

esistgut 6y ago

I am currently working on projects with Django (jinja2), Laravel (blade), Node (ejs) and Next. I can't possibly understand how so many people in this thread are preferring server rendering frameworks. As soon as you have a non hello world application (= complex state shared across multiple components / page) a SPA application is so much easier and productive. And Next brings this experience back to public facing frontends because it supports prerendering along other things.