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

171–180 of 331 posts

Re: Turbopack, the successor to Webpack

#171

Post by rattray »

jridgewell wrote: post #150
rattray wrote: post #132

Earlier quoted context omitted.

Right, they link to this docs page when referring to the memoization library: https://turbo.build/pack/docs/core-concepts And the github link at the top of the page links here: https://github.com/vercel/turbo but, despite being called "turbo", that seems to actually be the repo for Turbopack (the webpack alternative) not "Turbo" the library. Even digging a bit into the crates, I'm not sure where this supposed library…

The engine here are the creates called "turbo-tasks" and "turbo-tasks-*" extend it with more features. See a bit in https://github.com/vercel/turbo/blob/main/architecture.md#tu...

gotcha, cool – thank you!

Re: Turbopack, the successor to Webpack

#172

Post by rattray »

jridgewell wrote: post #149
rattray wrote: post #128

The Turbo memoization framework sounds interesting, but I don't see any code samples for what it looks like for Rust users, or how it compares to other Rust memoization/caching libraries…

Documentation here is one of the areas we need to work on. There's a bit in https://github.com/vercel/turbo/blob/main/architecture.md#tu... A small example of code that uses this is https://github.com/vercel/turbo/blob/main/crates/turbo-tasks... , which defines how we can load a `.env` file using FS read caching, cached `read` and `read_all` functions, etc.

Ah, very helpful/interesting – thank you! Seems neat.

Re: Turbopack, the successor to Webpack

#173

Post by nobleach »

cldellow wrote: post #69
rsanheim wrote: post #60

Looks impressive, but proof will be in the actual day to day dev experience and configuration, not the perf. Vite and esbuild are fast enough, and I feel the winner will be more about usability, docs, easy config, etc. That aside, it is just so frustrating and sad that this just continues the fragmentation in the JS build space. It is beyond exhausting at this point. I don't care about vite vs (or with) esbuild vs tu…

> special snowflake build toolchains That reminds me, wasn't there a build tool called Snowflake? Oh, it was called Snowpack [1]. And it's no longer being actively maintained. Yeesh. [1]: https://www.snowpack.dev/

The folks working on Snowpack didn't just give up. They transitioned over to working on Astro. It was a very positive move. I see great things coming out of that project as we move into a more "server rendered" future.

Re: Turbopack, the successor to Webpack

#174

Post by fragile_frogs »

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 browser and node.

I am manly building client side react applications, so your mileage may vary.

[1] https://parceljs.org/

[2] https://parceljs.org/getting-started/library/

[3] https://parceljs.org/getting-started/webapp/

Re: Turbopack, the successor to Webpack

#175

Post by moron4hire »

lelandfe wrote: post #169
adamparsons wrote: post #168

Earlier quoted context omitted.

Just migrated one of our projects from webpack+babel+tsc to just webpack with esbuild-loader, the difference is astounding. Just need to remove webpack itself now so we can use their transforms.

Doesn't esbuild skip Typescript type checking? https://esbuild.github.io/content-types/#typescript You'll still need to keep tsc around for that, though perhaps you're doing that with another step in Webpack...?

During hour to hour development, I just let Visual Studio tell me about the errors as they come up. On the rare occasions I don't already have the editor open before deploying, I have a shell script to kick off the right tsc invocation. Otherwise, bundling plus uploading to the server is just another shell script. Yes, a full type check from scratch is slow, but it doesn't come up that often.

Re: Turbopack, the successor to Webpack

#176

Post by 323 »

tln wrote: post #105
fabiospampinato wrote: post #88

Is there any actual proof that Turbopack is 10x faster than Vite at anything? I can't find any benchmark showing it.

I'm a little skeptical as well. Vite is fast I just checked a code base that's at ~900 modules, and vite is ready to serve dev requests in well under a second.

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.

Re: Turbopack, the successor to Webpack

#178

Post by [deleted] »

bdcravens wrote: post #159

I think the name isn't a great choice, given the already established Turbo ecosystem for Rails/Hotwire. Perhaps Rails can create a gem that makes migrating from one version to the next easier, a Version Compatibility Enhancement Library, calling it VerCEL for short.

[deleted]

Re: Turbopack, the successor to Webpack

#179

Post by rsanheim »

ksec wrote: post #20

I am wondering if Rails moved to esbuild a little too early.

esbuild remains a fantastic, stable, well documented choice. It does one thing, and does it very well, and is well beyond "version 1.0" quality software.

Comparing an alpha just open-sourced today to an established tool like esbuild isn't even a fair comparison, for either tool.

Post reply on HN