The Next team explains it because they don't want to solve this problem by shipping a definition of all the route of the app  because it does not scale. But while it is true, it makes dynamic routes extremely painful to use. Hopefully it will be fixed soon.
Another thing not mentioned in the blog post is they started to rewrite the core of Next.js in TypeScript too, which is a big move!
There is a bug right now related to query strings being hidden from the visible URL (they're still there as far as Next is concerned), but we'll be fixing that pretty soon.
Not sure if you've seen this guide here, but there is a way to setup dynamic routing with clean URLs that doesn't require adding your own server handler if you use Now v2 for deployments:
Also, I recently wrote about how I locally develop Now v2 apps with an example of SSR dynamic routes:
This is such an important piece of information. Imagine you opt for Next and have to rewrite your app soon. I know, APIs can be backwards compatible and Next's next version will be backwards compatible but there is always something which doesn't work, sending you down the rabbit hole...
Your apps should not be affected at all.
The parent says something different and if it were just about adding types then you need just to add a file to DefinitelyTyped which I guess happened already.
We're not even "rewriting everything in Typescript at once". We're slowly converting files over one by one. No public APIs are changed. Furthermore, we have an extensive test suite of end-to-end tests for both development and production behavior.
Some will tell you that it's for first time loading performance, but in this day and age, I doubt that even registers for business impact.
That they rewrite Next doesn't sound more convincing. And why do I need to sign-in on the learn page on Nextjs?
Sorry, not convinced. If you want some brute-force SEO, I'll write you anything in express/pug/style in one afternoon (with millions of landing pages, sitemap generation and smart routing, all comes out of the box with express), without all the baggage React brings along. Nothing against React, it's still one of the best SPA libs there but SSR, no way.
Maybe, I am still missing something but Next.js feels just like content marketing from its company Zeit trying to promote their commercial stuff.
Edit: guys, pls don't downvote if you disagree, downvoting is if comments don't add anything substantial to the discussion. I understand that Zeit is happy about the free promotion for Next on HN and doesn't like such comments but pls stay professional if people question your product without downvoting.
As to why SSR React, it's mostly going to come down to SEO, I don't know how much you'll get negatively impacted for being SSR vs SPA these days with proper routing myself. Google has been working on supporting client rendered scraping for at least 6-7 years now. And when a user hits more than one route, they've usually gained back anything they've lost for the extra load time.
I respect your experience and knowledge but people in this thread say exactly the opposite: Next.js' routing is actually not helping you.
The reason we actually went with Next is because it's relatively easy to drop if our needs diverge.
It's not hard to write code, it's hard to keep code complexity low and maintainable and IDK if Next.js helps here.
Some of the most SEO heavy websites are social networks, ecommerce sites, marketplaces and other interactive websites.
Even for corporate websites though, why should we degrade the user experience for SEO if we can easily have both?
And yes whether you agree or not (and by your comment I think you don't) the vast majority of users and UI/UX designers consider SPA to be a much better user experience than loading pages.
If you are making websites for a living, I suggest you come aboard the SPA train quickly or risk losing north of 90% of job opportunities.
Think Next.js not like a framework but an SSR version of create-react-app. It's incredibly easy to port into your custom thing.
It's a small library that lets you load data into Components - using the same code on both client and server render. You can use it to add server rendering to any existing React app. It's designed to just plug in and work. I'm the author :-)
You get to use all the modern tools that React gives you, an abundance of open source React components, and get an SEO and load time optimized website with minimal configuration. Building a server rendered, dynamic web app is non trivial. Next.js makes it a lot easier.
React coupled with Node.js has been used for SSR since 2015 in sites like PayPal so I'm not sure why you doubt it's veracity. React is a very strong UI library that is more than suitable for multiple rendering targets. It has never been limited to SPA apps. Facebook itself is not a pure SPA app.
Prefetching is a questionable and a lot discussed feature, do you want to prefetch all the 50 links on my page? Even if you think this a great feature, I am sure the user using your page doesn't like that you abuse his/her bandwidth. Especially those on mobile.
> code splitting
This is not a feature. Automatic code splitting is turn-key-ready in CRA. I wrote this now for the tenth time...
> server rendering
I explained this, if you really need SSR, a plain express/pug blows Next out of the water. Speed, flexibility, routing, everything. There is no single reason to use anything like Next.js. And writing a plain express/pug app is trivial and much easier than React, this is 10 years old tech.
I don't want to sound negative but again why is React as SSR 10x better than typical SSRs? It's not, React is great for real SPAs and Next feels to me like, let's jump on the React hype train and generate organic leads for Zeit.
Code-splitting in Next.js is fundamentally different than in CRA:
It's automatic, handled server side...and it gets hydrated on the server side if necessary with asynchronous data. The benefits of this on browser performance and developer performance should be self-evident.
Doing a truly isomorphic React app on your own with pure Node.js is non-trivial. As for using pug templates...just...no. You might want to read about why JSX is a thing to begin with.
It's not a hype thing. It's a tool that solves a problem. It's not needed for all applications. For many apps, a SPA is fine. That an engineer has to make evaluations on the trade-offs of various decisions goes without saying...But Next.js is a solid choice for a SSR framework.
If Next.js was good in SEO, nextjs.org would rank well on the search query 'react ssr' but you know what, it couldn't even rank within the top 10. There's nothing, no nextjs dot org, just a Medium article below the fold. Just want to see your face after you convinced your management and your entire team to move to Next and facing how your organic search volume is nosediving...
This whole thing is pure content marketing paired with forum spamming to get people converted to Zeit's products. I am bit surprised that not more 'real users' defend Next.js here, seems like just some maintainers/contributors could show up worshipping Next. This is all too obvious and maybe young devs fall into your trap.
Btw, I know what JSX is capable of and I prefer it over many things but it's not about JSX or pug or whatever. Next.js is abusing a powerful lib/framework for SSR and templating. SSR is much more, e.g. proper routing, read the thread, Next doesn't get routing (the #1 req of SSR) right and wants to do SSR? Sure.
What kind of argument is that? They're not in the business of SEO. If they were SEO consultants, you might have something there but SEO has nothing to do with their business model.
Also, Next.js isn't "good" at SEO, it allows you to server-side render your app, which is required for good SEO.
Sounds like you just have it out for Next.js, or the Zeit team altogether.
This isn't how Next prefetches with dynamic routing. It fetches the JS required to construct the DOM of those pages, but doesn't execute it. If on one page you have three links to /gallery/a, /gallery/b, and /gallery/c, then gallery.js will be prefetched once. You can confirm this in devtools. Also, prefetching is opt-in.
React is just another option for a stack - similar to express with pug, you can have express with React, without having to learn a new templating language if you already know React. And with things like TypeScript, you can have type checking into the mix too
The ability for us to write code that would work on the SSR portion & front end was also a big plus.
It's the same reason why Electron is so popular for desktop apps. On just about every measure, there's a better alternative available for that sort of thing -- native apps if you want speed and great integration with the host environment, Qt if you're willing to sacrifice on those fronts to get a single cross-platform solution. But Electron has one thing those alternatives don't, namely that if you're a Web developer you don't have to learn any new languages, toolkits, etc. to be productive with it. And it turns out that, for an awful lot of developers, "I don't have to learn anything new" beats just about every other consideration.
I'm okay with SSR, but often you get to a point where you want to mix in dynamic functionality on the client that just becomes more difficult with it. I think that Vue, React and others can be integrated into SSR, but doing SSR of React makes for a nice application development as a whole imho.
In the end, it's up to the developer. I will say with JS client and direct server there's less disconnect for most development, and the lack/reduction of context switching can be a huge productivity boost. I'm usually a proponent of a JS client talking to/through a JS API, that can talk to other things. SSR with that server platform just makes it a bit more coupled, which isn't in itself a bad thing.
The biggest value-add of using React on the server is being able to share our design library and business logic with our front- and back-end. We can develop the structure, style and behavior of our website as React components and deploy them server side or client-side. In general, our team has found that the component model is far more composable than templates like pug, PHP, etc.
You suggested Rails, but a big reason people like Next is exactly because it's an opinionated, batteries-included framework like Rails.
The "vendor lock-in" situation, which seems to be one of your main arguments, is exactly the same time. If you don't like vendor lock-in, I don't know why you'd propose Rails.
IDK, my dockerized express site loads much faster. At 20ms without network time (and this w/o caching). My real React SPA give you instant (0ms) page loads.
Nextjs.org initial load is at 580ms and the doc came at whopping 1.38sec (oh yeah) and page loads are not instantly... this thing doesn't make sense (for my use cases). If the only thing I know is React and JSX, then maybe but routing with express is much easier.
=> you want make serious money with SEO => get some real SSR environment
=> you want a great SPA, buttersmooth, interactive, maintainable code => React or other popular SPA libs
I wrote without networking time which includes DNS lookup
DOMContentLoad: 1.08sec, Load: 2.26sec
DOMContentLoad: 1.09sec, Load: 2.31sec
Unless you MUST have the absolute best SEO, I'm not sure that it really matters having SSR for most people/apps. I don't know how much traffic is really driven from search engines depending on the site, and I really don't know how much you get penalized for having an SPA anymore. I mean if your initial load is under 2-3s and in-site navigation is fast, you'll probably be fine.
The past few sites/apps I've consulted on got the majority of their traffic from outside SEO.
More relevant metrics are TTFB (time to first byte) and TTI (time to interactive).
I wouldn't want to implement a marketing site in express/pug. I want the flexibility of components and all the other benefits that React offers.
Me too. But if you ever did marketing landing pages for products you might know that one landing page is not enough. You need thousands which match to Ad Word campaigns or which are optimized to different SEO fields, domains and whatever. While you still could manage this with Next and nice components, Next's subpar routing might be an obstacle.
'web apps' is better.
The framework itself makes working with a React, universal rendering app much easier than other solutions I've worked with. It's doing a great job at starting very small while at the same time extending for your needs is pretty easy for most things (such as build configs, custom server, etc).
The community is growing and very helpful too.
I'm very glad to see it continue to move so fast and definitely already see it as a very strong option and probably becoming the de-facto solution for JS apps, just how Rails or Django are to Ruby and Python.
Thanks to the team for the great work :)
I've never used Gatsby so I can't really judge, but my understanding has always been that Gatsby is mostly focused on static sites. It can definitely do dynamic apps but it being not focused on this would concern me for support / experience of more complex things.
Sounds like a really nice alternative to Next.js and Gatsby. Does anyone have any experience with it?
One interesting comparison is on imports alone. The old site has 128 imports from gatsby* packages (it's not a very big site btw), the new site has around 10 from next* packages.
I'm not entirely sure what next.js does, but I would be wary of using this library due to the bad website experience on a non-optimal connection.
I've used react-redux-loading-bar in a recent small project of mine and it worked quite well so far.
I'm not sure about working with the native loading indicators though.
In general I quite like the way next.js is handling these things: It's pretty bare-bone but provides a lot of examples of how to do more advanced things.
There's even an example for loading indicators: https://github.com/zeit/next.js/tree/canary/examples/with-lo...
Thank you for your feedback @Ndymium, we've shipped a new version of the website that has a loading indication (based on the with-loading example posted above)
SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes.
Using Pre-Rendered CRA addresses both the SEO and performance concerns around using CRA without the complexity that Next.js introduces
SSR: Server-side rendering
CSR: Client-side rendering
The cold-boot problem is an interesting one, it's heavily correlated to the serverless function size, this is why we implemented a complete output target for serverless, to output the smallest possible function that is completely standalone, no dependencies. This makes cold-boot considerably faster. For example on https://next-news.now.sh/ it's hard to tell the difference between cold-boot and warm functions.
Just to explain the reason there is a login at all, this is mostly for historical reasons. The original learnnextjs.com built by Arunoda was based on another project he created for teaching Meteor.
Anyway as said we're rewriting /learn, using MDX (http://github.com/mdx-js/mdx) for content and the quizzes will store the result in your browser.
Thank you for providing feedback in a friendly way, we're always happy to improve where possible! In case you're curious we have a WIP pull-request: https://github.com/zeit/next-site/pull/159
If you don't like Next or don't see its usefulness thats fine, but 30,000 stars on Github and pretty varied list of companies seems to suggest that some people do find it useful.
I am not affiliated with Zeit or Next.js in any particular way. Just a happy user of Next and appreciative of all the hard work put into it.
Next = SSR + React
Nuxt = SSR + Vue.js