Next.js: For Next.js 10.0 use Snowpack instead of Webpack as bundler

[mysticaltech]

Feature request

Is your feature request related to a problem? Please describe.

I am developing a small SPA with Next.js 9.4.4 and on my optimized Macbook Pro 2012 i5 processor with 8GB, it takes a few minutes to hot reload / fast refresh.

A clear and concise description of what you want

I would love that the next major version of Next, i.e. 10.0 switches to a more modern bundler like Snowpack. In uses ESBuild underneath and the build times are just out-of-this-world fast, like millisecond range even for big projects.

Describe the solution you'd like

Replace Webpack by Snowpack. Yes I know, it's going to be painful but that is what major versions are all about, the benefits will be immense and it will make Next.js many folds stronger and better.

Describe alternatives you've considered

Vite is an alternative, but without deep analysis, it seems that Snowpack is better and is more widely used.

[timneutkens]

I am developing a small SPA with Next.js 9.4.4 and on my optimized Macbook Pro 2012 i5 processor with 8GB, it takes a few minutes to hot reload / fast refresh.

This sounds unexpected and unusual. It's likely changing bundlers will not solve the issue in your application. Can you share a reproduction? I also wonder if "minutes" is an exaggeration or not.

[ljosberinn]

Can confirm this is very most likely a setup issue. I'm occasionally developing on a Late 2011 MacBook Pro and hot reloading takes a few seconds on a medium sized project.

[Timer]

On macOS, a Fast Refresh should never really exceed 2-3 seconds with the p90 being under 1s. This might be _slightly_ longer on older hardware (5+ years old).

If you have a project which reliably reproduces this taking longer than this threshold, please share it so we can fix it.

[mysticaltech]

@timneutkens Yes, "minutes" might be an exaggeration, but not far from it. And yes, I do have a custom setting in next.config.js that maybe could be causing this issue, @Timer brought my attention to this. Also, I am using one central React Context for my app, no idea if that could be contributing too. I wish I could share the source but it's a work related project, I'm not allowed. Going to close this issue and look more into my code.

[ScriptedAlchemy]

Webpack 5 build times are blisteringly fast. Rebuilds that took 10 seconds before now take a fraction of that. Even fresh builds are significantly faster with its new caching mechanisms.

[mysticaltech]

If that's the case, if Webpack is evolving in that direction (which would be the smart thing to do), then this issue is indeed irrelevant. Thanks for pointing that out @ScriptedAlchemy.

[ScriptedAlchemy]

No worries. Ive been using WP5 for a few months now and rebuild times are way Better. I believe we saw sub-second rebuilds in dev mode if memory serves

[markschellhas]

I think you're all missing the point, @mysticaltech has a great suggestion. Snowpack is really the future of module bundles and would indeed be, as @mysticaltech mentions, a great improvement.

And Next.js is getting famous for slow dev builds. I've been using Next.js for years and slow dev builds have _consistently_ been an issue. Yes, setups affect builds but it's time to really get past having to reconfigure the codebase with every new Next.js release. Snowpack is a great new paradigm for 2020.

[ScriptedAlchemy]

Webpack 5 offers a significant amount of power and its builds are much faster. A prod build on a raspberry pi takes 20 seconds, used to take minutes

I'd argue that v5 with Module Federation is the future of app architecture and a new paradigm on its own. Which also solves slow builds at scale.

I'm not sure if snowpack has a intricate enough api. Snowpack is very appealing, but webpack has enterprise level apis to extend for anything.

[mysticaltech]

@markschellhas, yes true indeed, but I later realized that shifting away from Webpack completely for NextJS would be too "breaking" even for a major version release. People are doing complex setups in _next.config.js_, this needs to be backward compatible, or at best, migration must be easy enough.

It's a sad reality, but if Webpack 5 with module federation works, like @ScriptedAlchemy mentioned above, that would be awesome!

I am sure that sooner or later Webpack is going to inspire itself from Snowpack. The great thing about Golang is that it easily compiles down to binary formats that are easily reusable.

[ScriptedAlchemy]

V5 has lots of room for growth, api was designed to keep us on v5 for a longer time with now more breaking changes.

ESM is coming, if not already there (need to check the source)

Module federation lets me deploy code independent and webpack stitches it together at runtime. Behaves like a monolith, shares dependencies and all that. So instead of giant monoliths, we can break them down without losing the optimizations.

It's dynamic and at runtime. You simply use normal import statements and it'll get chunks from other bundles. Kind of like code splitting between many bundles.

It also makes stuff very modular. Easier to make a next powered header and do enterprise migrations to the platform.

I've had MF in production since February, before it was even in a webpack beta npm release.

It's also a key reason I'm advocating for v5 over another bundler. There's nothing else that has this capability. At scale it's desperately needed. If I'm able to port it to other bundlers in full, then we could have more options (maybe)

ESM doesn't support the capabilities of MF either, nor does import maps.

You could enable modern bundles experiment in next for dev, also that would cut out a bunch of Babel transpiles- in my experience, sass and Babel are the slowest loaders. Babel accounts for like 70% of compile time. So if you use modern bundles it'll ship as esm, granular chunks which are faster to rebuild compared to 200kb page or something

https://github.com/module-federation/module-federation-examples

[ScriptedAlchemy]

We could use this. Replace Babel loader with esbuild. Much faster. I don't think webpack is the biggest slow part. I'd love to see if this improves. I'll be trying it tomorrow. https://github.com/privatenumber/esbuild-loader

[mysticaltech]

Oh wow, yes that seems like something that could seriously be good. If I am not mistaken snowpack itself uses esbuild behind the scenes.

[ScriptedAlchemy]

Yep that's where it's speed is in part (it does pass transforms too)

What I do is configure both es and Babel loaders so my macros still work but stuff like node modules or other files that don't depend on Babel.

Then webpack cache should cover faster builds and rebuilds. Once the cache is warmed, even prod builds are pretty fast