Live data from Hacker News

Turbopack, the successor to Webpack

vercel.com

321–330 of 331 posts

Re: Turbopack, the successor to Webpack

#321
post #263

Earlier quoted context omitted.

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

I don't think I really understand your objection. Live reload, at least as I've got it set up, doesn't really work that way: it won't interrupt an in-progress debugging session, and the application state is retained (at least if one sets everything up correctly). Besides, type checking in my editor doesn't normally require me to save the file, so I usually know whether the code is valid or not before the build starts. So I don't have the problem you describe in the first place. Moreover, as I pointed out, I find it useful to be able to occasionally run code that doesn't type check, so there's a very real downside to waiting for the type checker to finish before building.

I suspect we're just used to building code in very different ways. If you've not tried approaching typescript as a linter rather than "just" a compiler, I really recommend giving it a proper go - it feels very freeing, and I think is one of the biggest advantages of typescript as a tool/concept. (It obviously has its own disadvantages compared to how, say, a traditional AOT compiler would work, namely that tsc can never really take advantage of types at all during the compilation, but it gives you a lot of flexibility during development - essentially the best of both worlds for dynamic and static type systems.)

That said, if you've already tried it and know it's not for you, then fair enough - ultimately all of these tools are just ways for us to write code, so if you write code best in this way, then I don't want to try and force you to do it some other way!

Re: Turbopack, the successor to Webpack

#322
post #53
post #4

My prayers for another JavaScript bundler have finally been answered!

There's always such a mixed response when new web tooling gets posted here that I really can't tell if this is sarcastic or not. Regardless, I like that this is fast and it is probably going to get a lot of adoption since it will be included with Next.js.

I'm sure it will be good, it's just so JavaScript for there to be another one of these.

Re: Turbopack, the successor to Webpack

#324
post #100

Earlier quoted context omitted.

As a performance nightmare you can't wake up from, SCSS can't die soon enough. As someone who depends on it currently though I def understand the frustration with losing support.

The new version (written in Dart of all things) seems pretty fast. The old ruby implementation was insanely slow, and the nodesass rewrite was insanely broken. Whatever they got now though is just about perfect for me

Embedded SASS promises to be faster anyway, though still slow IMO..

There are some issues with realizing the potential though. Namely, a standard-ish CRA React app will have thousands of SCSS compilation entrypoints due to importing SCSS in individual component modules.

Lack of process reuse is causing many to see slightly SLOWER compile times. Next you have:

* Lack of tooling support: Vite?

* Need to migrate SCSS syntax

* ??

As soon as it's a free-ish upgrade with high ROI on swapping it in, I'll take it! I think SCSS is a dead-end though. Modern CSS + postcss for some CSS-Next polyfills is the way forward IMO.

Re: Turbopack, the successor to Webpack

#325
post #277

Earlier quoted context omitted.

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

Did sound like it:

> why would anyone want only bundling

Re: Turbopack, the successor to Webpack

#326
post #274

Earlier quoted context omitted.

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.

My point is not that it’s impossible to write fast JavaScript, it is that creating performant abstractions is very hard in JavaScript. So performant code ends up not using many abstractions, and becomes difficult to write and maintain. Or well-abstracted code which is easy to write and maintain is slow.

Re: Turbopack, the successor to Webpack

#327
post #291
post #289

Earlier quoted context omitted.

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

> [...], and dividing it along a particular api border seems unnatural.

this boundary is inherent in client-server software/systems/applications, there's just no avoiding it. every other API is basically unimportant and arbitrary.

the whole Web paradigm, the fact of "you need to download the site and run it" and the consequences and trade offs that it implies are basically unavoidable.

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

completely understandable, and we're in total agreement. I also think that this is an underserved problem.

It's ridiculous that we still don't have near-perfect abstractions for these.

Re: Turbopack, the successor to Webpack

#328
post #327
post #291

Earlier quoted context omitted.

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

> [...], and dividing it along a particular api border seems unnatural. this boundary is inherent in client-server software/systems/applications, there's just no avoiding it. every other API is basically unimportant and arbitrary. the whole Web paradigm, the fact of "you need to download the site and run it" and the consequences and trade offs that it implies are basically unavoidable. > Anyway, I’m looking for a too…

every other API is basically unimportant and arbitrary

Well, frontend-to-backend api is also unimportant and arbitrary, unless it’s designed for public use. Since for a user the page is always in sync with its server, this api is an implementation detail as much as any other internal api (e.g. between service processes or between async-threads)

Why do you think that the project separation is unavoidable in this case? E.g. some of my sites are simple express apps serving scripts and resources. I don’t have integrated build pipelines there because… well, that is exactly my concern. There seems to be no reason that we couldn’t have an ~isomorphic project with multiple entry points on multiple “ends” and a single build system for all of them.

Re: Turbopack, the successor to Webpack

#329
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.

Have you tried vite? Its been a similiar experience for me

Re: Turbopack, the successor to Webpack

#330
post #328
post #327

Earlier quoted context omitted.

> [...], and dividing it along a particular api border seems unnatural. this boundary is inherent in client-server software/systems/applications, there's just no avoiding it. every other API is basically unimportant and arbitrary. the whole Web paradigm, the fact of "you need to download the site and run it" and the consequences and trade offs that it implies are basically unavoidable. > Anyway, I’m looking for a too…

every other API is basically unimportant and arbitrary Well, frontend-to-backend api is also unimportant and arbitrary, unless it’s designed for public use. Since for a user the page is always in sync with its server, this api is an implementation detail as much as any other internal api (e.g. between service processes or between async-threads) Why do you think that the project separation is unavoidable in this case?…

I don't think it's unavoidable, but in practice it is two separate components with markedly different concerns and trade offs.

For example if we don't use any client side JS, use only a templating system, it becomes easy to keep it one project.

Eg. there's NextJS, which is a bundle of React and a NodeJS backed in one project. (And while it provides a getStaticProps and other gimmicks it doesn't really do much to make client-server state sync seamless. I still have to manually write the /api stuff.)

Post reply on HN