top | item 28412299

(no title)

haywirez | 4 years ago

Had several requests lately for the exact opposite pattern — migrating bloated Next.js projects to vanilla React SPAs.

Razzle[0] seems like a workable alternative if you need static exports for optimizations such as link unfurling. Still looking for something that isn't based on Webpack (ideally esbuild or swc)— would appreciate links in replies.

[0] https://razzlejs.org/docs/static-export

discuss

order

lioeters|4 years ago

Razzle is what I used for a year or more, before moving over to Next.js. It's a solid static site generator and builder of full-stack applications.

Razzle is a far more hands-off approach, one of those tools that get out of your way, and disappears when you're using it. That has great value because it doesn't dictate how you write your application.

In contrast, Next.js is a framework, with its own universe of conventions, conveniences, ways to do things. It has a lot more functionality out of the box. Excellently documented, too.

I'd say Next.js provides great value in a team environment, to have a common, consistent and simple build configuration as well as application structure.

There's much to love about Next.js, but the only thing that bugs me is how they do opt-out telemetry. I have a postinstall script that runs "npx next telemetry disable", but it feels dirty.

---

As for "bloated Next.js projects", surely that's not the fault of the framework. It does its best to produce a lean production build, so the bloat is up to the user. (Unless you mean the size of the node_modules folder during development.)

wereHamster|4 years ago

Unlikely that Next.js itself caused the bloat. The same could happen with any framework, and just migrating to another one won't fix the underlying problem.

Next.js may switch away from webpack (to swc) at some point in the near future (they recently hired the developer of swc).

brundolf|4 years ago

What would make a Next project "bloated"? If you're talking about bundle size, most of the Next stuff should stay server-side. And if you're talking about dependency complexity, one benefit of sweeping everything under a does-everything framework is that you don't have to manage the ongoing complexity of all the dependencies yourself (contrasted with create-react-app).