Live data from Hacker News

Turbopack, the successor to Webpack

vercel.com

251–260 of 331 posts

Re: Turbopack, the successor to Webpack

#251

Earlier quoted context omitted.

Sure, but Rome is being eaten by the other things Vercel has, such as SWC replacing Terser and Babel. Pretty soon all of Rome's niches will be already met by other tools, I'd wager. I think Rome simply does not have a large and well-funded enough team compared to Vercel and others like Vite.

I think this could benefit Rome. Both projects are written in Rust and so far they have a linter and a formatter and now they can integrate Turbopack, package it behind "rome build" and don't have to build their own bundler and transpiler.

IMO, The whole thing behind Rome is that it will have one tool to do everything (lint, prettify, minify, build etc), so every part in pipeline remains in sync. Using other tools for parts of it(build etc) would be against the philosophy

Re: Turbopack, the successor to Webpack

#252
Im using rollup now over webpack. The landscape of js is starting to diverge again so rollup isn't exactly solid ground for me, I'm waiting for the next big migration to get swept up with. Maybe turbopack is it, maybe not. From what I'm gathering turbopack is like webpack only faster.. that's ok but I'm not exactly a fan of the whole webpack system with its loaders, plugins etc and arcane bugs and fixes.

Re: Turbopack, the successor to Webpack

#253

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever type…

As others have said, the convention is to use tsc for typechecking and declaration file generation and babel (ie by way of webpack) for bundling. You should not have typescript mismatch issues if you follow good practices. You should get no mismatch with babel using one typescript version and your tsc command using another. Do not use a global tsc command for instance, typescript belongs as a dev dependency in your project

Re: Turbopack, the successor to Webpack

#254
post #246

Earlier quoted context omitted.

>Running the typechecker independently of the bundler is really common in TypeScript maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking an…

Webpack does not bundle the type checking by default - iirc it cannot handle typescript at all by default, it needs to be configured. The typescript plugin that you used may have included type checking, but it very much depends on how you set it up. Many common setups use Babel to compile typescript code, which doesn't do any type checking at all, just mechanically strips away the type signatures. I would be very sur…

I think maybe the underlying problem here is that some people somehow manage to write javascript inside .ts files and I haven't figured out how they do that. I doubt it though, I think there is no way. It always complains about lack of types, it wants me to add annotations. The promise of mixing js and ts is not real for me. It just defies belief for me that people actually want to write squiggly line, broken autocomplete type of code and have it compile a tiny bit faster compared to just having a single unified workflow where typing, build output and build information always matches and you don't have to guess and look up whether the build is already done, or maybe there was a build error or maybe this time one of the type checks that I ignored actually mattered for js also, not just for ts or maybe the error was actually not just a typecheck error but also a DOM api error and on and on it goes. To actually want to live in this world of uncertain, mismatched information and expect to be faster iteratively is not believable.

How is it not a problem for you that you make a change in a .ts file and then you are immediately in a world of uncertainty: Is the typecheck already complete? No clear progress on this. The js output is probably already here, but not sure unless you constantly want to check yet another terminal window. So can I reload the page yet? Oh no wait, a few more type errors popped up after all, so I can't yet. This all happens in under 2 seconds but those 2 seconds are uncertainty and slow you down far more than any wait for a normal sized typescript project where typechecking is done integrated with the build.

Re: Turbopack, the successor to Webpack

#255

Earlier quoted context omitted.

I outlined some of the downsides in the comment, more in another comment of mine. I thought about it even more and I think I can finally see the possibly true reason why people are developing these type of bundlers: The typescript projects that they have to work on are so huge that the typechecking is always going to be too slow so you don't want to deal with it, you rather typecheck only the file that you're current…

Typescript has an open bug to use multiple threads for compilation. That's why it's slow. It's also not a big deal because of parallel type checkers. > Yes I really don't think that omitting typechecking is the way to go for development. You've not really given a reason why. Just a rant about how other languages are different.

It is you who is ranting at me with this small comment complaining about a lack of reasons while I've given many reasons now across multiple comments while you have called me a ranter with two dismissive lines.

Re: Turbopack, the successor to Webpack

#256

Earlier quoted context omitted.

This has been a huge frustration of mine with webpack - you end up with relatively complicated configs and it sometimes feels like even if you copy and paste your config over, you end up still having to spend a ton of time fighting with webpack to actually get it to work

And when you try to upgrade just one plugin everything breaks and you have to upgrade everything.

This should be the universal byline for all JS projects.

Make a T-Shirt with this and get rich.

Re: Turbopack, the successor to Webpack

#257

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever type…

Thats not how one usually work. Whats the point in running tsc (the official transpiler) on each save? Plus, you are using an LSP client right? right??

Im a user of esbuild, and its so fast it can recompile on each save (see esbuild `serve` option) and i wont notice anything locally. Theres also a watch mode, and production build with minify.

So i work locally without a typecheck for my builds, and let my LSP client do the type checking. When i bundle for prod i run an additional tsc for type checks before the bundle is produced. Takes a few secs more (as tsc is slow) but this is a nonissue.

Re: Turbopack, the successor to Webpack

#258

After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…

Same here. I got dead tired and fatigued of all the JS ecosystem bundles and over engineered solutions. Today i mainly use a Makefile and esbuild. No config files at all! It has been a blessing!

Re: Turbopack, the successor to Webpack

#259
post #81

From my experience working with esbuild since it's early days, all I can say is to that there has been a very high bar set by esbuild's speed and ease-of-use. I've used it for all my web apps and services since and i've finally begun to like my front-end build chain, unbelievably.

This. esbuild has been amazing. Can never work without it. The only thing missing is a "vendor" kind of bundle. I wish i could specify dependencies and own code in two separate bindles. As the other wont change much, and could be cached.

Re: Turbopack, the successor to Webpack

#260

These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever type…

Thats not how one usually work. Whats the point in running tsc (the official transpiler) on each save? Plus, you are using an LSP client right? right?? Im a user of esbuild, and its so fast it can recompile on each save (see esbuild `serve` option) and i wont notice anything locally. Theres also a watch mode, and production build with minify. So i work locally without a typecheck for my builds, and let my LSP client…

I recompile on every save too, all with full typechecking in under a second. As I've suspected, this is probably because most people here work in bigcorp projects where there are so many thousands of files that you cant work like this anymore. It's not because it's actually better workflow wise, it's only better for you now because otherwise the compilation is too slow. Same as the situation that has developed with Rust.
Post reply on HN