If you had to list the characteristics of the perfect Node.js web application framework, you’d probably come up with something like this:

1. It should do server-side rendering, for fast initial loads and no caveats around SEO
2. As a corollary, your app’s codebase should be universal — write once for server and client
3. The client-side app should hydrate the server-rendered HTML, attaching event listeners (and so on) to existing elements rather than re-rendering them
4. Navigating to subsequent pages should be instantaneous
5. Offline, and other Progressive Web App characteristics, must be supported out of the box
6. Only the JavaScript and CSS required for the first page should load initially. That means the framework should do automatic code-splitting at the route level, and support dynamic import(...) for more granular manual control
7. No compromise on performance
8. First-rate developer experience, with hot module reloading and all the trimmings
9. The resulting codebase should be easy to grok and maintain
10. It should be possible to understand and customise every aspect of the system — no webpack configs locked up in the framework, and as little hidden ‘plumbing’ as possible
11. Learning the entire framework in under an hour should be easy, and not just for experienced developers

Next.js is close to this ideal. If you haven’t encountered it yet, I strongly recommend going through the tutorials at learnnextjs.com. Next introduced a brilliant idea: all the pages of your app are files in a your-project/pages directory, and each of those files is just a React component.

Everything else flows from that breakthrough design decision. Finding the code responsible for a given page is easy, because you can just look at the filesystem rather than playing ‘guess the component name’. Project structure bikeshedding is a thing of the past. And the combination of SSR (server-side rendering) and code-splitting — something the React Router team gave up on, declaring ‘Godspeed those who attempt the server-rendered, code-split apps’ — is trivial.

But it’s not perfect. As churlish as it might be to list the flaws in something so, so good, there are some:

• Next uses something called ‘route masking’ to create nice URLs (e.g. /blog/hello-world instead of /post?slug=hello-world). This undermines the guarantee about directory structure corresponding to app structure, and forces you to maintain configuration that translates between the two forms
• All your routes are assumed to be universal ‘pages’. But it’s very common to need routes that only render on the server, such as a 301 redirect or an API endpoint that serves the data for your pages, and Next doesn’t have a great solution for this. You can add logic to your server.js file to handle these cases, but it feels at odds with the declarative approach taken for pages
• To use the client-side router, links can’t be standard <a> tags. Instead, you have to use framework-specific <Link> components, which is impossible in the markdown content for a blog post such as this one, for example

#web