Webpack creator Tobias Koppers announcing its (Vercel-funded) successor:

Turbopack is built on a new incremental architecture for the fastest possible development experience. On large applications, it shows updates 10x faster than Vite and 700x faster than Webpack. On even larger applications, the difference is greater—often 20x faster than Vite.

Turbopack is open source and still in alpha. Here’s what the future may hold:

To start, Turbopack will be used for the Next.js 13 development server. It will power lightning-fast HMR, and it will support React Server Components natively, as well as TypeScript, JSX, CSS, and more.

Turbopack will eventually also power Next.js production builds, both locally and in the cloud. We’ll be able to share Turbo’s cache across your entire team, using Vercel Remote Caching.

Webpack users can also expect an incremental migration path into the Rust-based future with Turbopack.

I’ve had my eye on esbuild for awhile now (because I’m impatient), but there didn’t seem to be an easy way to use the Go-based JS bundler with our current webpack setup. (I want speed, after all, but I don’t want to have to work for it!)

I’m pretty excited by esbuild-loader, because its README says:

It makes sense to use [esbuild] over Babel/TSC with webpack to take advantage of both worlds (Speed and the webpack ecosystem).

That’s music to my ears, right there. I’ll report back how it works for us. ✊

We sit down with Tobias Koppers of webpack fame to talk about his life as a full-time maintainer of one of the most highly used (4 million+ dependent repos!) and influential tools in all of the web.

Things we ask Tobias include: how he got here, how he pays himself, has he ever gotten a raise, what his typical day is like, how he decides what to work on, if he pays attention to the competition, and if he’s ever suffered from burnout.

We continue to use bundlers even though ES Modules (the new JavaScript module system) runs natively on the web. Why?

Over the last several years, JavaScript bundling has morphed from a production-only optimization into a required build step for most web applications. Whether you love this or hate it, it’s hard to deny that bundlers have added a ton of new complexity to web development – a field of development that has always taken pride in its view-source, easy-to-get-started ethos.

Related ~> JS Party #69

Carmen Bourlon, writing on her personal blog:

A browser will check in with a service worker every 24 hours and re-initiate the process, but only if there are changes. You might change your app’s CSS or JavaScript, but without a change to the service worker, the browser will never go and update your service worker. And if the service worker never gets updated, the changed files will never make it to your user’s browser!

Fortunately, there’s a pretty simple fix – we’ll version our cache…

Thanks to Carmen for this fresh take on service workers from an offline-first point of view. If you dug this, you might want to get on the list for her book “Let’s Take This Offline” — a book about service workers with a focus on helping users without a consistent internet connection.

Jetpack can be used instead of webpack, webpack-cli, webpack-dev-server and webpack-dev-middleware without writing any configuration. Jetpack is a thin wrapper around webpack, and can be extended with any of the webpack configuration.

Taking the configuration out of webpack seems like a recipe for success.

This project is an exploration of some ideas accumulated over a few years using webpack in a variety of projects. Webpack is a very powerful and flexible tool. It applies to a lot of use cases and that is one of the reasons it has so many configuration options. Webpack also evolved over the years but preserved backwards compatibility as much as possible to support the large ecosystem built around it.

I’d be surprised if some of the good ideas in Jetpack don’t find their way in to webpack proper.

Webpack and Babel are awesome, this article isn’t trying to say otherwise. We wouldn’t be able to use a lot of things if it weren’t for them, but the experience of using them together needs to get better. I faced many of these issues over the course of many months and understanding them/finding solutions was incredibly difficult (error messages don’t exactly tell you what went wrong and searching for them doesn’t always give relevant results), and I hope this article can act as the guide I had hoped to find back then.

I love posts these where you take your hard-won learnings and share them with the world in an attempt to save others from the same headaches.

Cowboy 2.1 supports H2, but Plug and Phoenix haven’t released their official support yet. In this article, Chase Gilliam walks you through the steps to get your Phoenix app up and running with the new HTTP standard today.

Slack chose webpack as their build tool, but it wasn’t fast enough.

Our build took minutes, not seconds: a far cry from the sub-second concatenation we were used to. Slack’s web teams deploy up to 100 times on any given work day, so we felt this increase acutely.

Let’s just say they went to work and came up with several techniques to speed up the build process.

webpack is a fantastic, versatile, tool that does not need to cost the earth. These techniques have helped us reduce our median build time from 170 to 17 seconds and, while they have done much to improve the deployment experience for our engineers, they are by no means a complete work.

A very intelligent browser based Webpack dashboard

Visualization tools for our build tools. What a day to be alive! Also gotta respect how hard the author worked to get that acronym to fit: Just A Rather Very Intelligent System…

This JS lib automatically offloads modules into Web Workers on the fly, saving you time/effort while making your code run faster. Using Webpack? Check out workerize-loader