[mc3]

Yeah the idea of building a 100% static site in react seems a bit ironic to me. Handlebars is so much simpler to work with for a static site (like a blog) that isn't going to "spring to life" and become a SPA.

But I can see it being useful in the niche area of someone who needs to do server side rendering for performance (every millisecond to first render counts), while keeping the code simple by not having a second technology to do that rendering, and they need the same thing to be a SPA. Maybe a GMAIL type application? And again the user has to care - I don't care if I wait 10 seconds for my mail app to load as I'll be spending minutes in there once it does, and you've locked me in for other reasons anyway.

This might matter for SEO but to be honest you could just have a non-JS version of the same page which looks different for SEO purposes.

Next.js seems pretty hot, so I am probably missing something :-).

I'd rather not use JS on the server myself, so for my projects I'd either make a SPA with API backend and no server side rendering. Or just a classic "rails style" crud app with a sprinkle of JQuery.

I hope someone chimes in and tell me what I am missing and why to use Next.js other than "I only want to do JS and React for all the things."

[justsee]

Next.js positions itself as a hybrid framework, and is recommending SSG (static site generation) by default over SSR.

See this discussion [1] with the response from rauchg (framework author and Zeit founder) outlining where they are heading.

This ability to easily mix SSG and SSR pages within the one project, the PHP-inspired philosophy of simple file-based routing for pages, and pre-configured babel / webpack with easy customisation are a few things that draw people into next.js dev.

Like anything that deals with reasonable complexity there are a bunch of concepts to understand, but once that happens next.js feels like a thin layer around "it's just react".

I particularly like being able to drop api functions with a standard req / res signature into `pages/api` to immediately have some server-side api endpoints available, which can be deployed to Zeit's now as Lambdas with minimal fuss. It significantly reduces the friction of thinking about and implementing front-end sites with custom api endpoints for whatever you're building.

[1]: https://github.com/zeit/next.js/discussions/10437

[mc3]

Does this mean I can treat it a bit like PHP hosting of yore, where I upload a single file and stuff just works? No NPM etc? That would be compelling!

[madeofpalk]

Some of the benefits of "React" don't come from React itself, but rather the ecosystem. Webpack, Typescript, CSS Modules, etc are all things that work well in the "react ecosystem". Certainly possible outside of that, but its going to be harder.

Do you get type safety in Handlebars?

[mc3]

Correct AFAIK you can't get end to end type safety in Handlebars, in that if you treat a string as an array it will silently not render something, whereas in Typescript / React you would notice.

But... let's forget Handlebars because Typescript/ES6 allows you to write code like this:

    mythings.map(thing = `<li>${thing.name}</li>`).join();

And this is React-free and arguably a lot simpler for the needs of a static site, and actually more flexible as your are controlling the character by character output.

And the question is do I want to pull in not just React but Next.js and learn all of it's ways to do this? I think for a static site no.