[luketheobscure]

This is an unfortunate comparison. I actually chose Next.js because of its similarity to Rails - it's a batteries included, opinionated framework that favors convention over configuration (though it's not sold that way since these are not the currently trending buzzwords). There's absolutely nothing preventing you from using both tools. Rails works great as an API supporting a Next.js UI.

[caiohsramos]

I'd say Next.js is the opposite of a "batteries included" framework. No abstractions for ORM, background jobs, sending emails, managing attachments, web socket communication - all very basic stuff when dealing with a production application.

[luketheobscure]

It is a batteries included _front end_ framework. You don't need to worry about compiling, routing, code splitting, etc. Most of the things you described should be handled by the back end service

[Onavo]

All these features are stateful or realtime. In a cloud/serverless world, they are all separate managed services ("compute/storage separation"). That's the trade-off of Next.js, greater productivity by standing on top of more hosted dependencies. Theoretically unlimited (within datacenter limits) scaling, bottlenecked only by your credit card.

[sankumsek]

Do you have a suggestion for a more Rails-esque framework (maybe Django)?

[pier25]

Next is definitely not "batteries included". It solves close to nothing on the backend (like all fullstack JS frameworks).

[rglover]

Well, not all of them [1].

DB access (drivers are automatically started, connected, and wired for use), queues, cron jobs, websockets, uploads, API helpers, simple routing, caches, indexes...

It gets ignored, but there are (sane) options. I'm quite proud of the APIs, too. Easy to learn, tidy, and everything just works.

[1] https://cheatcode.co/joystick

[rohan_]

wouldn't using the nextjs backend / server components be far simpler and and streamlined