Next.js is an awesome framework, but dynamic routing is still a mess, and clean URL masking [0] is unnecessary complicated: you have to add a route handler to Express.js, and you have to use 2 different props to your <Link> components to make it work.<p>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 [1] because it does not scale. But while it is true, it makes dynamic routes extremely painful to use. Hopefully it will be fixed soon.<p>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!<p><pre><code> [0] https://nextjs.org/learn/basics/clean-urls-with-route-masking
[1] https://github.com/zeit/next.js/issues/4989#issuecomment-442024894</code></pre>
What I don't get: Either you go full SPA <i>or</i> SSR. And If you go for latter then you can choose any stack, e.g. Rails, express with pug, Django, PHP, etc. Why do people take React's constraints to the backend? No bashing, really wondering what's so much better then. I know why a React SPA can be better than a SSR. But what is better about a React SSR vs the typical SSR?
I've been using Next.js for a fairly big e-commerce project for a client, and I have to say it's great.<p>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).<p>The community is growing and very helpful too.<p>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.<p>Thanks to the team for the great work :)<p>edit: typos
Holy crap, these pages load fast. Honestly the best possible advertisement for a javascript framework at the moment is how quickly the page paints. For me it was virtually instantaneous. Bravo.
Interesting read from Dec 2018 [1] about Next.js:<p><i>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.<p>[...]<p>Using Pre-Rendered CRA addresses both the SEO and performance concerns around using CRA without the complexity that Next.js introduces</i><p>[1] <a href="https://codeburst.io/next-js-ssr-vs-create-react-app-csr-7452f71599f6" rel="nofollow">https://codeburst.io/next-js-ssr-vs-create-react-app-csr-745...</a>
Here's the PR to Webpack:<p><a href="https://github.com/webpack/webpack/pull/8609" rel="nofollow">https://github.com/webpack/webpack/pull/8609</a>
Interested to see serverless as part of a web framework. My understanding was AWS Lambda and similar platforms were best for asynchronous workloads, but for web stuff the cold start could be too long for things to feel snappy. Has that changed recently?
One concern on mobile where I find the scrolling is not respond for a second or longer whenever I swipe back to previous page in Safari, applicable in some of the showcases in Next.js too, is it the expected user experience?
If you are going to use it as a static site generator, you should also try Hugo + the Mainroad theme, generated files are super light and easy to style as you wish.