Next.js is not what you may think it is

Understanding next.js when coming from the meteor paradigm.

A few weeks ago I wrote an article about web frameworks lock-in. I then criticized next.js as just the next iteration of shiny almighty tools we will have a hard time move away from in a year or so.

Now I believe I’ve been unfair towards this project. next.js has in fact a somewhat unintuitive, but well delimited scope. I believe it’s described best by Guillermo Rauch in this comment:

The biggest feature of Next.js is that it’s not a backend. It’s closer to what @getify calls a middle-end. A universal rendering frontend.
The best architecture that’s coupled with this is that Next.js queries data services in getInitialProps. REST micro-services, APIs and GraphQL are great complements to this architecture.

In other words next.js’s scope is to UI-rendering, while abstracting away the client/server distinction. If you need “proper” backend logic, such as a database or an accounts server, you should keep that in a separate server application.

If you come from meteor-land like I do, splitting concerns into different applications might feel strange. But this is where Arunoda Susiripala’s already year-old criticism of universal applications applies. As he comments in the same thread:

I’ve pretty good experience with Meteor. Full stack frameworks are not going to work in the long run. We learn it by the hard way.
I think our focus should be this as it mentioned on the description of Next.
A minimalistic framework for server-rendered React applications

I’m currently in the process of evaluating technologies to move my application away from meteor. It’s an awesome project, but I believe relying solely on npm libraries is going to be less risky in the long run. Follow me if you want to hear more news about this effort.

Update: I created a node.js (next.js) starter library that features a full accounts system, called Staart. Check it out live here!