Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turbopack, the successor to Webpack

vercel.com

Post reply on HN
Print view View original

271–280 of 331 posts

Re: Turbopack, the successor to Webpack

#271

Post by johnny_reilly »

Nathanba wrote: post #230
bichiliad wrote: post #225

Earlier quoted context omitted.

Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because,…

>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…

ts-loader maintainer here. webpack never did typechecking. It's possible to run ts-loader in two modes; with type checking active and with it disabled. For years I've been advising running type checking as a separate process to improve the development workflow:

https://blog.johnnyreilly.com/2017/09/07/typescript-webpack-...

Exciting news about turbopack - the world is about to get much faster!

Re: Turbopack, the successor to Webpack

#272

Post by hamandcheese »

Nathanba wrote: post #238
victorvosk wrote: post #237

Earlier quoted context omitted.

Why would you want your tooling to be coupled when it doesn't have to be with zero downside?

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…

For typical workflows, I’m not looking for type errors on the CLI. I’m just running webpack in watch mode in the background, while I edit and get typescript errors in my editor.

This is how the majority of people write typescript, and there is only upside from splitting out bundling and type-checking for these people.

Re: Turbopack, the successor to Webpack

#273

Post by throwaway4good »

Remember jikes - the java compiler written in c (or something)?

I think writing build tools for JavaScript in anything other than JavaScript (or language that compiles to js) is a dead end.

How would you write a plug-in to this? Or a programmatic configuration. So much gained from staying on js.

Re: Turbopack, the successor to Webpack

#274

Post by joppy »

throwaway4good wrote: post #273

Remember jikes - the java compiler written in c (or something)? I think writing build tools for JavaScript in anything other than JavaScript (or language that compiles to js) is a dead end. How would you write a plug-in to this? Or a programmatic configuration. So much gained from staying on js.

On the flip side, it’s very hard (sometimes impossible) to make highly performant abstractions in JavaScript, which makes it difficult to make fast tools which do complex work. Most JS-based programs choose to either be fast and difficult to program, or easy to program but slow.

The advantage of having an incredibly fast build tool can already be seen with Vite and esbuild, which hot-reload modules at speed. Fast tools can change the way work is done.

Re: Turbopack, the successor to Webpack

#275

Post by Vinnl »

friendzis wrote: post #269
bmy78 wrote: post #244

Earlier quoted context omitted.

JavaScript is a dynamically-typed language. Parallelizing the type checking with bundling gives you the best of both worlds: the speed when writing in a dynamic language and the type safety that comes with a static-typed language. For me, I like to write my code and not too concern myself with types until I’m close to committing; that’s when I fix type errors.

> I like to write my code and not too concern myself with types until I’m close to committing I'm genuinely curious here. How do you ensure contract correctness? The whole point of static typing (or rather explicit typing) is to declare and enforce certain contract constraints prior to writing [client] code, which prevents certain bugs. What's the point of using type-safe language if you deliberately circumvent type…

You ensure contract correctness by encoding it in the types. However, while developing, you might still be figuring out the contract.

Re: Turbopack, the successor to Webpack

#276

Post by Vinnl »

Nathanba wrote: post #230
bichiliad wrote: post #225

Earlier quoted context omitted.

Running the typechecker independently of the bundler is really common in TypeScript. Typechecking takes time, and blocking on it to transpile and bundle your JS doesn't really add any benefit. Most build systems run the checker in parallel because it cuts down on build time. Plus, Webpack doesn't really do transpiling or typechecking for you — your loaders do. Webpack's loaders can't really check your types because,…

>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…

One thing I haven't seen mentioned yet in the replies is that often, people will already have type checking in their editor, with inline feedback. The iteration speed when it comes to fixing type errors is much faster that way, and then running type checking again to serve it up in the browser is unnecessarily slowing you down (and the type checker isn't really fast).

Re: Turbopack, the successor to Webpack

#277

Post by Vinnl »

Nathanba wrote: post #260
phplovesong wrote: post #257

Earlier quoted context omitted.

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 R…

I don't, and I think maybe you should reconsider your assumptions about literally every single person replying.

Your assumption (from your first comment) is that people only run bundling. That's not the case. People run bundling in parallel to type checking, rather than in series. You still get the type checking benefits without blocking your build on it and thus slowing down your dev process.

Re: Turbopack, the successor to Webpack

#278

Post by Vinnl »

andrew_ wrote: post #200
domoritz wrote: post #109

Earlier quoted context omitted.

Yes. I mostly build libraries and rollup still beats everything in compatibility (esm, umd, cjs, etc) and output quality. It's slow, though, and I would love a faster alternative. Esbuild doesn't do tree shaking as well as rollup.

Vite uses it under the hood and has it running crazy fast.

I think Vite only uses it for the production build, no? As far as I know Vite doesn't do bundling (yet) in dev mode.

Re: Turbopack, the successor to Webpack

#280

Post by throwaway4good »

joppy wrote: post #274
throwaway4good wrote: post #273

Remember jikes - the java compiler written in c (or something)? I think writing build tools for JavaScript in anything other than JavaScript (or language that compiles to js) is a dead end. How would you write a plug-in to this? Or a programmatic configuration. So much gained from staying on js.

On the flip side, it’s very hard (sometimes impossible) to make highly performant abstractions in JavaScript, which makes it difficult to make fast tools which do complex work. Most JS-based programs choose to either be fast and difficult to program, or easy to program but slow. The advantage of having an incredibly fast build tool can already be seen with Vite and esbuild, which hot-reload modules at speed. Fast too…

I doubt it; most speed improvements comes from taking a different approach (ie. caching or ignoring time consuming typechecks), not a difference in the speed of language or platform.
Post reply on HN