It's a server side rendered framework for React. It can also do static sites but doesn't have as many plugins as Gatsby JS, which focuses on static site building with React.
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."
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.
Do you get type safety in Handlebars?
But... let's forget Handlebars because Typescript/ES6 allows you to write code like this:
mythings.map(thing = `<li>${thing.name}</li>`).join();
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.