Hacker News Reader

Comment by samuelstros | Hacker News Reader

Vercel is on a streak. I am curious whether Turbopack elapses Vite like Vite elapsed Webpack over the past 12 months.

If the configuration is a nightmare like webpack then not likely.

Webpack has a reputation that was deserved in early versions. More recently it's not so bad unless you have very specific needs. If all you're doing is building a standard app from things like JS or TS, a CSS processor, and maybe a framework you probably won't need more than half a dozen lines of config that you can paste from Webpack or your framework's docs.

Currently looking at a 1000 line webpack config..........

You're either doing something complicated or you're not using Webpack very well. Most Webpack config I've worked with isn't like that.

It's justifiable for the level of complexity it is handling, but it does mean that trying to switch to a different build process is gonna be painful.

What does your 1000 line webpack config do?? I think part of the problem with webpack is it gives users the freedom to create 1000 line configs even though they’d be fine with a smaller more simple config

Problem with webpack is that freeform JS code is not "configuaration". Configuration presumes set amount of features driven by declarative statement. Most of what I've seen done "in Webpack" in fact is shitty scripting in an awful language. I'm very happy to see movement away from this criminal waste of everyone's time.

Not gonna get into the details, as it's company proprietary code, but we aren't talking about a weekend project. This is a large, complex product that has a significant user-base, and it also has to handle a bunch of legacy stuff.

Sure, I did not mean you are doing something bad. I just happen to hate JS and Webpack with passion ;)

No worries! I like js, I'm just feeling the pain of trying to move off webpack.

It is still in alpha, I am guessing a lot of backward compatibility might still be added to it before the stable release.

And the article exclusively testing it against just Next.js build could be an indicator as of how optimized it is for the meta framework probably?

according to the article, Turbopack is 10-20x faster than Vite. I wonder how they were able to edge it out so significantly!

I would guess they're factoring this in:

> Turbopack is built on Turbo: an open-source, incremental memoization framework for Rust. Turbo can cache the result of any function in the program. When the program is run again, functions won't re-run unless their inputs have changed. This granular architecture enables your program to skip large amounts of work, at the level of the function.

Which would make that multiple an extremely rough estimate, highly-dependent on the situation. But it's still an exciting development

I wonder how they make that robust, given that Rust isn't pure and there's no way to force a function to be pure either.

It's not very hard to stick to a pure-ish style even in languages that don't statically enforce it; JavaScript's MobX framework has the same constraint, as do React functions, and computed properties in Vue, etc. You don't really get any static help with functional purity in those cases, but thousands of programmers do it successfully every day

And while Rust doesn't strictly enforce purity, it does make it a lot easier to stick to in practice with its explicit `mut` keyword for local variables, references, and function arguments (including for the `self` argument on methods). There are various ways like RefCell to get around this if you're really trying to, but you have to go out of your way.

The answer seems to be caching (https://turbo.build/pack/docs/core-concepts), lots and lots of caching. Which enables it to reuse a lot of already computed stuff for incremental rebuilds.

Which makes me wonder if the speed comparison graphics are solely about repeat builds.

Vite uses esbuild for transpiling and rollup for bundling. esbuild (written in go) is already pretty fast for transpiling but there might be a lot of possibilities to optimize in rollup as rollup is written in JavaScript.

Coincidentally, the primary maintainer of Rollup mentioned plans for a rust rewrite in his recent talk at Vite Conf.

Incremental compilation plus not having each dependency be its own network request (I work on Turbo, but not Turbopack).

Rust is a hell of a drug.

My guess is some combination of dropping support for older browsers, supporting fewer features, and optimizing for the common case at the expense of edge cases. In a few releases, once all those are added back in, it will be no faster than Vite.

Reply on news.ycombinator.com