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

291–300 of 331 posts

Re: Turbopack, the successor to Webpack

#291

Post by wruza »

pas wrote: post #289
wruza wrote: post #207

Earlier quoted context omitted.

Parcel felt really fast, zero-conf and “opinionated” in a good way. But I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command, with modules shared across sides. This frontend/backend separation is too alien to my idea of development (coming from desktop programming), and it feels like some artificial border. Thankfully, No…

Rust :) https://m.youtube.com/watch?v=oCiGjrpGk4A but more importantly, I recommend embracing the frontend-backend separation. it's important in desktop contexts too. after all, you don't want to block the UI thread with waiting for I/O, right? of course the last ~2 decades were about coming up with various hacks, workarounds, solutions to make the whole threshold easier to pass (from Java applets to Ajax/XHR, comet/…

I think your comment is mixing two kinds of separation together: process/thread separation and project separation. To me, a project is a single concern, monorepo or not, and dividing it along a particular api border seems unnatural.

Anyway, I’m looking for a tool that could make this part of development simpler by joining all these efforts in a “project and process manager” way instead of maintaining multiple toolkits/configs or generators. The latter I know how to do. Been there, done that, fed up.

Re: Turbopack, the successor to Webpack

#292

Post by Nathanba »

i_like_robots wrote: post #285
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,…

> Webpack's loaders can't really check your types because, without doing a lot of extra magic, they operate on one file at a time. This is the point folks really must understand when setting up a new tooling pipeline to deal with TypeScript. Certainly all of the module bundlers I'm aware of operate in this way. To explain further for anyone curious; for TSC to work effectively it must construct and understand the ent…

But in theory type checks could be cached too. Why this isn't currently done is because it's probably more work and requires very deep knowledge of the typescript language and parsing. Meanwhile the bundling itself is a simple affair of combining text files together. So these tools instead just fork the typechecker for some minor gain but in practice you could absolutely cache type information. That's what every IDE does with their intellisense database. I think in this thread we are essentially talking back and forth over the current state of bundlers and most here rationalize why it's okay (if not better!) for type checking to be separated from the compilation but the reality is that it's a fairly arbitrary state of affairs. It could easily all be efficient so that type checking is just as parallelized and incremental as bundling and therefore requires no separation into a different process. As we know, after all a binary produced by c++, rust or c# is also a "bundle".

Actually this painfully reminds me why I found it so weird that tsc doesn't simply offer bundling itself. Why wouldn't it? It should be very easy for the compiler to do this as it has all the information and on top of that, tsc also has an incremental mode already. That definitely means 'incremental' for type information.

Re: Turbopack, the successor to Webpack

#293

Post by munbun »

jacquesc wrote: post #239
cantSpellSober wrote: post #198

> Currently, migrating to Turbopack from Webpack is not yet possible Bummer! Do I need a turbopack.config.js? I've still got my package.json, tsconfig.json, .env, and postcss.config.js apparently. > [Turbopack cannot currently be configured with plugins. We plan to make Turbopack extensible, likely with an altered API] Will I be able to use my current plugins? Where does config for these plugins live? > [SCSS and LES…

What's wrong with SCSS modules? It has a lot of really useful functionality that frontend developers like me love.

`node-sass` was the fastest solution (node bindings to a C++ library) was deprecated a few years back.

`sass` (dart-sass) is the current iteration but it’s an order of magnitude slower for larger projects with many small scss module files. I’ve seen it add +10 to 30 seconds.

`sass-embedded` will be the next iteration for dart-sass but in its current form still suffers from similar issues.

I believe using postcss for nesting support + css variables is a better alternative, considering that css will likely get native nesting support in a few years.

https://www.w3.org/TR/css-nesting-1/

Re: Turbopack, the successor to Webpack

#294

Post by Nathanba »

Vinnl wrote: post #277
Nathanba wrote: post #260

Earlier quoted context omitted.

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.

>Your assumption (from your first comment) is that people only run bundling

that was never my assumption

Re: Turbopack, the successor to Webpack

#295

Post by rpwverheij »

jridgewell wrote: post #123
dinvlad wrote: post #44

Curious if this will be supported by react-scripts. Or is it Next.js-specific?

It's _currently_ Next specific, but we plan on making it generic and usable in any setup.

that's a crucial detail that I did not read in the article. I've seen Next.js mentioned a lot, but havn't gotten to trying it yet. Reading the article I wasn't sure if this meant I would have to adopt Next.js. I definitely suffer from build tool configuration fatigue, so if it had to be through next.js (a new system for me) it's a lot less interesting, for me, in this moment.

Re: Turbopack, the successor to Webpack

#296

Post by pas »

Nathanba wrote: post #292
i_like_robots wrote: post #285

Earlier quoted context omitted.

> Webpack's loaders can't really check your types because, without doing a lot of extra magic, they operate on one file at a time. This is the point folks really must understand when setting up a new tooling pipeline to deal with TypeScript. Certainly all of the module bundlers I'm aware of operate in this way. To explain further for anyone curious; for TSC to work effectively it must construct and understand the ent…

But in theory type checks could be cached too. Why this isn't currently done is because it's probably more work and requires very deep knowledge of the typescript language and parsing. Meanwhile the bundling itself is a simple affair of combining text files together. So these tools instead just fork the typechecker for some minor gain but in practice you could absolutely cache type information. That's what every IDE…

tsc already has incremental mode, also there's the LSP, the bundler in watch mode could keep a persistent TS language server running. if the typecheck succeeds the bundler emits the new bundle, easy peasy.

If I remember correctly gulp(js) was perfectly able to do this.

Re: Turbopack, the successor to Webpack

#297

Post by Nathanba »

MrJohz wrote: post #263
Nathanba wrote: post #254

Earlier quoted context omitted.

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

> I think maybe the underlying problem here is that some people somehow manage to write javascript inside .ts files[...] I don't think that's it. I write pretty much exclusively typed code, except in places where I've not managed to get everything set up properly (mainly old Vue2 code). And even then, imports are unidirectional: JS can import TS, but TS can only import other TS files. As to the "world of uncertainty"…

>with live reload and a good configuration (that's harder to achieve on some projects, I grant you),

right but livereload has the same problem as you: The build is already done so it reloads but lets say the typecheck will error out because surely you save a file more often than you want to recompile. So your page just reloaded which you didn't intend, in fact, it might actively have destroyed a debugging session which you didnt want to reload yet. How do you configure that away to make it work sensibly? And here is the kicker: I know you can configure your livereload build so it only reloads after the build and the typecheck are done. But this is precisely how we ended up discussing this.. now you always depend on both the typecheck and the build to end before you can test your change anyway.

Re: Turbopack, the successor to Webpack

#298

Post by [deleted] »

andsoitis wrote: post #153
derekdahmer wrote: post #116

Earlier quoted context omitted.

Webpack 5 was that push to fix the monolith. I would guess that after that herculean upgrade effort that the creator of Webpack has a pretty good idea of what’s fixable and what’s an inherent limitation of the existing tool.

Microsoft has been able to evolve Windows and Office and SQL Server for decades, with huge customer bases…

[deleted]

Re: Turbopack, the successor to Webpack

#299

Post by Nathanba »

pas wrote: post #296
Nathanba wrote: post #292

Earlier quoted context omitted.

But in theory type checks could be cached too. Why this isn't currently done is because it's probably more work and requires very deep knowledge of the typescript language and parsing. Meanwhile the bundling itself is a simple affair of combining text files together. So these tools instead just fork the typechecker for some minor gain but in practice you could absolutely cache type information. That's what every IDE…

tsc already has incremental mode, also there's the LSP, the bundler in watch mode could keep a persistent TS language server running. if the typecheck succeeds the bundler emits the new bundle, easy peasy. If I remember correctly gulp(js) was perfectly able to do this.

>easy peasy

but how do you do it? this is not as easy as it may seem. Of course it's possible but the value here is that I don't have to do this for every IDE and/or the LSP when I use webpack where waiting on the typecheck is an integrated feature.

Re: Turbopack, the successor to Webpack

#300

Post by 323 »

tln wrote: post #216
323 wrote: post #176

Earlier quoted context omitted.

That is misleading. Open the browser and request the app and you'll see the first cold load will take many many seconds since Vite didn't load and compile the app yet. If you reload the second time will be much faster since it will serve from it's memory cache.

That does take a few seconds, for me. But I could see how that could get painful on larger apps. I'm not trying to mislead... but it would be good to know what they are actually measuring.

They are measuring the time until Vite is ready to serve requests, but then they compare it to the time of the webpack dev server, not mentioning that WebPack will have everything compiled at that time unlike Vite.

Vite is indeed much faster than webpack, but they use this highly misleading "vite ready to serve in 100 ms" stat.

Post reply on HN