Turbopack, the successor to Webpack

https://vercel.com/blog/turbopack

by nutlope • 4 years ago

626 312 4 years ago

vercel.com

tylermcginnis• 4 years ago

Excited to play around with this. Congrats Tobias, Jared, and team!

samuelstros• 4 years ago

Vercel is on a streak. I am curious whether Turbopack elapses Vite like Vite elapsed Webpack over the past 12 months.

hmillison• 4 years ago

according to the article, Turbopack is 10-20x faster than Vite. I wonder how they were able to edge it out so significantly!

minimaxir• 4 years ago

Rust is a hell of a drug.

maxfurman• 4 years ago

My guess is some combination of dropping support for older browsers, supporting fewer features, and optimizing for the common case at the expense of edge cases. In a few releases, once all those are added back in, it will be no faster than Vite.

brundolf2• 4 years ago

I would guess they're factoring this in:

Turbopack is built on Turbo: an open-source, incremental memoization framework for Rust. Turbo can cache the result of any function in the program. When the program is run again, functions won't re-run unless their inputs have changed. This granular architecture enables your program to skip large amounts of work, at the level of the function.

Which would make that multiple an extremely rough estimate, highly-dependent on the situation. But it's still an exciting development

fabian2k2• 4 years ago

The answer seems to be caching (https://turbo.build/pack/docs/core-concepts), lots and lots of caching. Which enables it to reuse a lot of already computed stuff for incremental rebuilds.

atfzl• 4 years ago

Vite uses esbuild for transpiling and rollup for bundling. esbuild (written in go) is already pretty fast for transpiling but there might be a lot of possibilities to optimize in rollup as rollup is written in JavaScript.

hardwaregeek• 4 years ago

Incremental compilation plus not having each dependency be its own network request (I work on Turbo, but not Turbopack).

vidyesh• 4 years ago

It is still in alpha, I am guessing a lot of backward compatibility might still be added to it before the stable release.

And the article exclusively testing it against just Next.js build could be an indicator as of how optimized it is for the meta framework probably?

JoshGlazebrook• 4 years ago

If the configuration is a nightmare like webpack then not likely.

onion2k2• 4 years ago

Webpack has a reputation that was deserved in early versions. More recently it's not so bad unless you have very specific needs. If all you're doing is building a standard app from things like JS or TS, a CSS processor, and maybe a framework you probably won't need more than half a dozen lines of config that you can paste from Webpack or your framework's docs.

wilg2• 4 years ago

My prayers for another JavaScript bundler have finally been answered!

aobdev• 4 years ago

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.

wilg2• 4 years ago

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

awestroke• 4 years ago

Very nice

cercatrova4• 4 years ago

As Lee Robinson mentioned and as I had said before [0], Rust and other compiled languages are the future of tooling. We should optimize for speed for tooling, not only whether people can contribute to it or not. We can always have a JS layer for configuration while the core runs in Rust, much like for many Python libraries, the interface is in Python while the computation happens in C++.

I was also looking forward to Rome (a linter, formatter and bundler also built in Rust but still under development) [1] but looks like Vercel beat them to the punch.

[0] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[1] https://rome.tools

arvigeus• 4 years ago

Turbopack is just a bundler, while Rome is the whole package. I think only Deno strives for the same, but still can’t replace things like eslint

arafat_stan• 4 years ago

Is Rome being used anywhere? I haven't heard about it for a while. Kinda figured it was dead tbh

cercatrova4• 4 years ago

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.

akira2501• 4 years ago

How often is bundling happening relative to loading the bundle that 5 seconds of savings is pertinent?

There's this fairly recent notion that speed rules everything. Perhaps maintainability and releasing non-alpha quality software could have a day or two in the sun as well?

cercatrova4• 4 years ago

On a large team, it happens quite often in the CI infrastructure, as well as testing on local machines.

There's this fairly recent notion that speed rules everything

Recent? I'd say it's very old, then got outdated as everyone moved to dynamic slow languages like Ruby (for Rails), Python (Django) and JS because of their perceived productivity improvements over typed languages like Java around 15 years ago. The pendulum is simply swinging in the other direction now.

Eduard• 4 years ago

We can always have a JS layer for configuration while the core runs in Rust, much like for many Python libraries, the interface is in Python while the computation happens in C++.

And this behind-the-scenes-native code-but-pretending-to-be-Python is the reason why most Python stuff I try fails to run on the first tries.

Half of them I give up because I don't get them running after going down the weirdest error rabbit holes.

No matter whether Debian, Ubuntu, Windows 7/10, Cygwin, WSL2, Raspberry Pi, x64, ARM ...

cercatrova4• 4 years ago

What are you running? I've done multiple large deployment for machine learning work and they all work fine, stuff like numpy, scipy, pandas, pytorch etc which are the primary technologies I've seen written in C++. I wouldn't expect normal libraries to be so however, since they're likely not speed critical; Django for example I'm pretty sure is just Python.

Emigre_• 4 years ago

If it combines the flexibility of Webpack with the performance of esbuild this is going to be great.

ssalka• 4 years ago

Literally 1 day after my team migrates our build to Vite :')

rk064• 4 years ago

While turbo pack may be faster, you should take such benchmarks with a huge grain of salt. At least, they are peer verified

szundi• 4 years ago

At least that is stable now, be happy

squidsoup• 4 years ago

Stable API perhaps, but vite has issues with memory leaks, which can break builds in CI.

https://github.com/vitejs/vite/issues/2433

paulbgd• 4 years ago

Vite isn’t tied to its internal tools that heavily, in theory they could switch to using turbopack internally if they wished.

ramesh31• 4 years ago

esbuild is good. you made the right choice.

somishere• 4 years ago

Lucky, that could have been an uphill battle

andrew_5• 4 years ago

you made the right choice.

tr1ll10nb1ll• 4 years ago

You don’t have to migrate to the “fastest and the greatest” right away. Do it when you feel the need for it or starting something new.

himujjal• 4 years ago

Squeezing unnecessary performance for no reason is just stupidity and time wasting at best.

When I say turbopack, I was thinking why the hell would someone need this. Vite is fast enough for everybody. Quite fast indeed. Then there is Parcel which is also quite good and reliable.

I never felt with Vite performance was an issue at all. Everything is so dang fast in my company's website. We are unnecessarily optimizing stuff!

jdelman• 4 years ago

Very excited for this if the configuration and behavior is 1:1 with Webpack. The primary reason I haven't moved to other "more efficient" build tools is having to learn how to do various optimizations and getting the artifacts I expect.

TheRealPomax• 4 years ago

God, I hope not. If there's one part of webpack that needs a complete overhaul it's (1) how you set up complex workflow configurations and (2) proper documentation for all aspects of that. And yes, that's one thing. Code without docs is not production-ready code, but code with bad docs isn't even PoC-ready code.

crucialfelix• 4 years ago

I think webpack has overhauled 1 and 2 every major release.

Accordingly the docs and API and blogs are littered with a mish mash of all previous APIs.

Thats the whole problem with webpack-its always changing.

fabian2k2• 4 years ago

Webpack has a huge API. It's extremely flexible and extensible, which is a big reason why it's so popular.
We're planning on making Turbopack very flexible and extensible, but we're not planning 1:1 compatibility with Webpack. This lets us make choices which improve on Webpack's API, and let us optimize for speed and efficiency.

https://turbo.build/pack/docs/migrating-from-webpack

pelagicAustral• 4 years ago

This now has really started to feel like the last days of Rome.

michael_michael• 4 years ago

Bread and Javascript bundlers.

fny• 4 years ago

For context: https://rome.tools/

ntonozzi• 4 years ago

Some extra context: https://en.wikipedia.org/wiki/Fall_of_the_Western_Roman_Empi....

fragile_frogs7• 4 years ago

I think this might have just made their lives easier, from the projects website:

Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Since both projects are written in Rust, the Rome team could use Tubopack to build/bundle projects and focus on the other features they are planing: https://rome.tools/#supported-features

ksec• 4 years ago

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

jbverschoor• 4 years ago

You know. This thing is created by the creator of webpack. The site looks very polished. His name, photo, and fancy autograph is there. Seems there's too much ego involved in this project.

I tend not to trust architecture / quality / performance of people who made my programming life worse. :)

I get a lot of deno feels here. I'll just be happy with esbuild.

n42• 4 years ago

you weren't kidding; that autograph is pretty tacky. the ego and marketing that goes into JS tooling is nauseating.

johnnypangs2• 4 years ago

This is using swc under the hood which as a transpiler is usually slower than esbuild. What makes Turbopack faster is caching not the transpiler. Rails (or vite or whoever) can implement similar caching speeding things up as well.

Why I wouldn’t choose, esbuild is because they don’t support the automatic React runtime and don’t seem to have plans to (or at least last time I checked.) Swc does… So as long as you’re okay with that limitation I imagine you’re probably fine.

You could also potentially use Bazel for remote caching in your rails app, though I haven’t used it myself so I don’t know how well it would work.

rtsao• 4 years ago

Automatic JSX runtime was added to esbuild in 0.14.51: https://github.com/evanw/esbuild/pull/2349

petepete• 4 years ago

I'm a huge fan of esbuild. Whether it's 'the best' at everything or not, our build process is now so simple I can understand it with barely any effort. Webpacker never gave me that confidence.

Not mentioning speed at all here, it was never my biggest concern.

omnimus2• 4 years ago

esbuild is just fine. It's so much easier to use than webpack. Speed is not only reason why people like esbuild over webpack.

rsanheim3• 4 years ago

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.

nickjj• 4 years ago

The Rails https://github.com/rails/jsbundling-rails gem lets you pick between esbuild, rollup and Webpack. If Turbopack ends up being popular then jsbundling should be able to support it.

The nice thing about Rails now is there's no massive direct integration like Webpacker once was. Now we can basically use the JS tool straight up and Rails will just look at assets in a specific directory, it doesn't matter what tool generated it.

qbasic_forever2• 4 years ago

Wow remote caching like Bazel is wild to see in a bundler. It's nice to see someone realize that JS bundling is more or less like compiling and linking in the native code world and we just need to accept it and optimize the hell out of it.

colordrops• 4 years ago

speaking of which, is it reasonable to use Bazel instead of webpack?

qbasic_forever2• 4 years ago

Bazel is just the infrastructure to run webpack. You'd need to do some work to make webpack's state be cacheable (I dunno what options and such it has for this, maybe it's already there as an option). But if you're looking at Bazel for JS work you probably just want to use the existing and maintained rules for it: https://github.com/bazelbuild/rules_nodejs It's been a while since I last looked at it but I don't think it has any caching for webpack.

bombela• 4 years ago

I have used bazel (with remote caching) to cache the output of webpack before.

Webpack was driving the typescript compilation and had some plugins/extra codegen steps to run too. I tried to move as much as possible to bazel but I quickly found out the JS ecosystem likes to produce massive balls of muds. Very hard to break down and separate the various steps.

hamandcheese2• 4 years ago

With rules_nodejs you can transform your source with whatever node-based packages you’d like. But be prepared to be more or less entirely on your own to figure out how to make it all work.

Oh and if you create many smaller packages (as is best practice in bazel to get good cache efficiency and parallel builds) be prepared for nonexistent editor/IDE support.

Aeolun5• 4 years ago

Does it make sense to cache something that takes 1.7 seconds though?

hobofan• 4 years ago

Yes. The nice thing about Bazel is that it'll also be able to do the same caching and cache invalidation across your build graph, so for a decently sized project the savings can be much bigger. I think [0] gives a decent overview.

[0] https://blog.aspect.dev/rules-ts-benchmarks

renewiltord4• 4 years ago

Is there a place I can find a "current state of the art" on this stuff? Once upon a time a quick-start option would have been. For instance, I may have done Rails+React+Babel+Webpack to get a quick backend JSON-API and a front-end web-app that consumes it.

Not for something that "scales to 100 teams", just something for me to spin an app up in quickly. i.e. 0 to 1 is the only thing that matters.

Vinnl7• 4 years ago

Next.js is pretty much that. Not much configuration needed, and it wires up all the tools for you behind the scenes. If a new tool comes out that's worth it (like potentially Turbopack, although that's by the same company), they'll do the migration for you.

cal852• 4 years ago

Rails also has a whole model/database thing going on.

Next.js is just front end focused and has always left it up to the user to decide about data persistence.

So to answer the original question, an equivalent would be Next+Database, and there is obvious stand-out answer for what Database should be. I often get stuck deciding what that Something should be when trying to go from 0 to 1.

gmaster1440• 4 years ago

Bummer that we have to wait for Svelte support, but seems worth it. Hope to see it bundled with Svelte Kit soon!

https://turbo.build/pack/docs/features/frameworks#vue-and-sv...

andrew_5• 4 years ago

Vite's momentum is too much to stop right now imho

bovermyer• 4 years ago

I wonder if I can use this to replace Rollup for my Svelte SPA...

rk064• 4 years ago

Not yet. They don't have plugin support yet. And they are prioritizing Nextjs for obvious reasons

thatswrong0• 4 years ago

This looks great, but I feel like calling this a successor to Webpack in its current state is disingenuous, considering the roadmap literally says: “Currently, migrating to Turbopack from Webpack is not yet possible.”

At least the marketing website is snazzy ¯\_(ツ)_/¯

josefdlange• 4 years ago

Not to mention explicit language about _not planning to support the Webpack API 1:1_...

ohbtvz• 4 years ago

It's led by the creator of webpack, and they are working on an incremental migration path. What more would you expect? If you want to keep the exact same API, stay with webpack...

RussianCow• 4 years ago

Indeed. Calling it a "spiritual" successor would have been more honest.

adammarples• 4 years ago

Heir apparent maybe?

dinvlad• 4 years ago

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

jridgewell5• 4 years ago

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

rpwverheij• 4 years ago

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.

Scarbutt• 4 years ago

Is nextjs the modern rails?

o_m• 4 years ago

Kinda, but not really. There are still lots of parts you'll have to implement yourself if you want to create a CRUD app. The mainly focus on the frontend part with the help from the backend.

Combine next.js with https://blitzjs.com/ and you'll have something that looks like rails.

nullandvoid• 4 years ago

To throw another in the ring, I recently stumbled on https://github.com/t3-oss/create-t3-app. Lots of buzzword tech in there, but the setup looks very interesting.

Looks like blitz is tRPC + next auth?

wtf242• 4 years ago

No. It's been awhile since I played around with it, but it's a front end framework that depends on react, that's really good at generating static pages

reducesuffering2• 4 years ago

Yes, it really is. Startups these days aren't using traditional rails anymore as much as either full-stack typescript w/ React (a la Next.js) or Next to make SPA and hitting a more full-featured REST API.

There is currently a lot of cutting edge engineering focused on the Typescript ecosystem (Vercel, Cloudflare, Deno, etc) vastly outpacing things being done around Rails, Django, PHP, etc.

bluelightning2k• 4 years ago

Stuff like this is why I obsessively read HN. Love it. More nice work from Vercel!

jaxn• 4 years ago

I read this while taking a break from trying to find the problem with our pnpm/turborepo monorepo. Works in a clean devcontainer, fails in CI, fails on multiple dev machines.

Currently. I’m skeptical.

rsanheim3• 4 years ago

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 turbo. I just wanna `script/build` or `yarn dev` and not think about it anymore.

It seems like collaboration and consolidation around common tooling is just impossible and not even considered a possibility at this point. We are forever stuck in this world of special snowflake build toolchains for damn near every app that wants to use modern JS.

TAForObvReasons• 4 years ago

Specific to build tools, a number of projects are VC-funded. Rome raised millions of dollars in VC money (https://rome.tools/blog/announcing-rome-tools-inc/). This offering is now funded by Vercel.

The same problem plays out in the JS engine space (Deno raised $21M and Bun raised $7M) and in the framework space (e.g. Remix raised $3M). As long as there's money to be made and investors to fund projects, there won't be consolidation.

cldellow• 4 years ago

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/

WorldMaker5• 4 years ago

My disappointment related to this is that I still think Snowpack's philosophy was the right one for JS present and especially for JS future: don't bundle for development at all because ESM support in today's browsers is great and you can't get better HMR than "nothing bundled"; don't bundle for Production unless you have to (and have performance data to back it up).

I know Vite inherited the first part, but I still mostly disagree with Vite on switching the default of that last part: it always bundles Production builds and switching that off is tough. Bundling is already starting to feel like YAGNI for small-to-medium sized websites and web applications between modern browser ESM support, modern browser "ESM preload scanners", and ancient browser caching behaviors, even without HTTP/2 and HTTP/3 further reducing connection overhead to almost none.

But a lot of projects haven't noticed yet because the webpack default, the Create-React-App default, the Vite default, etc is still "always bundle production builds" and it isn't yet as obvious that you may not need it and we could maybe move on away from bundlers again on the web.

nobleach• 4 years ago

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.

tshaddox2• 4 years ago

I don’t think any of the current options are good enough that I would want the community to settle on one of them at this point at the expense of any innovation or experimentation.

andsoitis2• 4 years ago

We’ve been doing JavaScript development for how many years now? And still no bundling options that are good enough? Or at least one that can continue to evolve vs. creating a successor, etc.

WorldMaker5• 4 years ago

That seems to be the chicken-and-egg problem here: the current problem is endless repetitions of "none of the existing options are good enough, let us build a new option". The call above is "just pick one and everyone work together to make it better", but we're back to "none of the existing options are good enough".

danenania• 4 years ago

An explicit goal I would personally like to see from build tools in the JS world is long term stability. I don't want my build tools to have a new major version every year. Semantic configuration improvements simply aren't worth all the churn. Adding new functionality is fine and great, but keep it backward compatible for as long as you possibly can.

This is an area where we could learn something from the Golang ecosystem. You're always going to end up with some warts in your API. Tools with warts that are consistent, documented, predictable, and long-lasting are so much easier to manage than tools that are constantly applying cosmetic revamps.

shrimpx2• 4 years ago

Is rollup still a thing?

netghost• 4 years ago

Rollup is used by some of these tools. For instance vite uses rollup for production builds.

TN1ck• 4 years ago

Yes, e.g. Vite uses Rollup for production builds. Vite uses esbuild for development with plans to make it usable for production builds.

mklepaczewski• 4 years ago

What do you mean by "still"? I just learned that it exists a month ago! I wish I was joking...

JS is not my main language, true, but damn it's hard to keep up. I think it took me less time to be productive with Typescript than with webpack.

chrisoakman• 4 years ago

Build tooling stability is one of the great undersold benefits of the ClojureScript ecosystem IMO.

The build process is defined by the compiler (using Google Closure tooling under the hood) and has not significantly changed since the introduction of ClojureScript in 2011.

Since all CLJS projects use the same compiler, the build process works the same everywhere, regardless of which actual build program is being used (Leiningen, shadow-cljs, etc).

melony• 4 years ago

And that's one of the reasons why people don't use clojurescript. Arbitrary npm package import and interop was not possible until late 2018 with shadow-cljs. Build tooling "stability" is only a thing if you believe in reinventing every wheel, not using third party dependencies, and pretending that the half-baked "clj" tool doesn't exist.

lewantmontreal• 4 years ago

JS has 10x the amount of developers of all other languages combined, that translates to a lot of ideas on how to progress the different avenues of JS land.

encryptluks22• 4 years ago

It is also the primary language taught to bootcamp developers looking to get started, and so a lot of suggestions and ideas come from people without any real experience.

jacquesc3• 4 years ago

Agreed. Every time NextJS changes out their build system for speed, its users lose out on all kinds of functionality that they were depending on before.

Moving away from Babel to SWC meant we could no longer use SCSS within JSX styled components. We first switched everything to plain CSS, which was a nightmare IMHO. Now slowly switching things to SCSS modules.

Now with Turbopack, we lose that too: https://turbo.build/pack/docs/features/css#scss-and-less

"These are likely to be available via plugins in the future." Fantastic

pjmlp2• 4 years ago

Yeah, it really pains me that Sitecore is doubling down on them as the main FE framework.

Rapzid4• 4 years ago

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.

michaelmior• 4 years ago

Looks impressive, but proof will be in the actual day to day dev experience and configuration, not the perf.

I think it really depends on the use case. I use Webpack, but it's all configured for me by create-react-app and I don't have to mess with it. If my configuration could automatically be ported from Webpack to Turbopack and my builds got faster, great :)

Of course, that's not the only use case and I agree that speed alone won't decide the winner.

eurasiantiger• 4 years ago

    // @TODO implement and publish
   import { webpackConfigTranslator as translate } from ”turbopack-webpack-compat”;
   import webpackConfig from ”./webpack.config.js”;

   const turbopackConfig = translate(webpackConfig);

   export default turbopackConfig;

Any takers?

verisimilidude2• 4 years ago

Fully agreed.

I would add that esbuild has set the bar very high for documentation and configuration. I come away very impressed every time I need to touch esbuild, which is not usually my expectation when it comes to the JS build-and-bundle ecosystem.

And while vite is still young, it does a good job integrating itself with many different JS stacks. The docs are also great, and the project has incredible momentum.

Between esbuild and vite, I feel pretty set already. Turbopack will need to be that much better. Right now, it doesn’t look like much more than an attempt to expand the turborepo business model. Let’s see where they take it.

fragile_frogs7• 4 years ago

I just wanna `script/build` or `yarn dev` and not think about it anymore.

Parcel might be a good fit for you: https://parceljs.org/

rsanheim3• 4 years ago

We've already migrated our old webpack rails front end to esbuild as of a couple months ago, and couldn't be happier.

Aeolun5• 4 years ago

Vite

On large applications Vite is fast to build, but loading your application in browser issues thousands of http requests, which is tragically slow.

Esbuild is basically instant to build, and instant to load on the same application. It’s a shame it doesn’t do hot reload.

If Turbopack can give us the best of both worlds, then that’s absolutely an improvement I want.

Rapzid4• 4 years ago

Yeah, working on app with >8k modules seeing >4s page loads on refresh. It's also weird how it wants to force you to not use deep imports on package deps, but then doesn't want you using index files in your own code..

I believe there are areas for improvement here that Vite can make though. They need to implement finer grain browser side module caching, dependency sub-graph invalidation(Merkel tree?), and figure out how to push manifests and sub-manifests to the browser so it can pro-actively load everything without needing to parse every module in import order making network requests as it goes..

Lots to do lol.

orra• 4 years ago

A rather niche question: The blog says Turbopack is fast thanks to using Turbo, a library for incremental memoization. I wonder how Turbo tcompares to Salsa, the latter which was developed in tandem with rust-analyzer.

mosdl• 4 years ago

Parcel is another one of these that started promising but the longer we use it the more issues crop up (caches need to be pruned, performance issues).

buf• 4 years ago

Feels like the rails community is going to be confused by the naming.

Toutouxc• 4 years ago

The Rails community has been confused for the last X years by having to switch JS toolchains several times without anything getting easier or faster.

hit8run• 4 years ago

The webpacker rails 6 approach was a mistake that has been fixed with rails 7. Rails 7 offers a very good solution.

riquito• 4 years ago

A bit of a bummer that "get started" requires nextjs, and there's no documentation for a frameworkless build (I understand it's labeled as alpha but if you're going for such grandiose announcement an "how to bundle a vanilla/frameworkless app" would have been nice)

jridgewell5• 4 years ago

Our initial development cycles were dedicated on getting Next working. But we absolutely plan on expanding the to support generic bundling and will include that in the docs.

encryptluks22• 4 years ago

Same... I went to build from source and can't even find it in their source files. I didn't realize alpha releases meant build from branch tip.

IceHegel• 4 years ago

If I want to write a plugin does it have to be in rust? I like rust but we're not going to add rust tooling to our dev env just for one plugin.

jridgewell5• 4 years ago

We plan on supporting both. We're still in the alpha phase, and have not designed the plugin API yet.

stillbourne• 4 years ago

Does it have module federation?

TomatoTomato• 4 years ago

Well thats going to cause some problems

https://twitter.com/ScriptedAlchemy/status/15850274824321802...

fantasticsoul2• 4 years ago

You can try hel-micro(https://github.com/tnfe/hel) A runtime module federation SDK which is unrelated to tool chain，It means that any tool system can access module federation technology in seconds ， Users do not need to be bound to the webpack system。

samhuk2• 4 years ago

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.

frizkie• 4 years ago

Yeah, as someone who focuses primarily on back-end but occasionally finds the need to dive into front-end, esbuild has virtually eliminated the pain I had with front-end bundling/packaging when I was using Webpack. At least it has in my situation, which involves mostly standard needs and very little customization.

verisimilidude2• 4 years ago

esbuild shines even brighter when you do need to customize. The API is outstanding. Docs are excellent. I've been able to do most things myself, without hunting for plugins and examples.

adamparsons• 4 years ago

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.

lelandfe3• 4 years ago

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

pkrumins• 4 years ago

Same here!

gingerlime• 4 years ago

esbuild is great, but our only blocker for using it was that there was no way to control the number of chunks. On a moderately sized modular app, this can slow down things significantly[0]

[0] https://github.com/evanw/esbuild/issues/2317

phplovesong3• 4 years ago

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.

tylergetsay• 4 years ago

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

no_wizard• 4 years ago

Really hope this gets a competent library mode. Webpacks library mode never really evolved to meet the needs of things. Vite has a good library mode but it has its own limitations.

Pure rollup is still the best for building libraries, by and large (maybe esbuild now? but I think rollup is more efficient in its output still).

If this has a good, solid library mode that works like rollup with the power of the webpack-like asset graph, it'd actually be amazing for the community as a whole.

domoritz• 4 years ago

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.

beezlewax• 4 years ago

Can esbuild support esm or umd etc via plugins? I've looked at using it but these formats are an unfortunate requirement for the builds I need to do.

I noted that esbuild doesn't fully support es5 transpilation and this will hold it back from some usage.

andrew_5• 4 years ago

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

fabiospampinato• 4 years ago

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

tln2• 4 years ago

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.

omnimus2• 4 years ago

Just note it's not Vite but esbuild that's doing the dev bundling.

3232• 4 years ago

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.

ohmahjong• 4 years ago

Here is the benchmark section of the site, although I don't see a definitive source for what is being run.

* https://turbo.build/pack/docs/benchmarks

EastSmith• 4 years ago

Too much marketing speak I think.

We're planning Turbopack as the successor to Webpack. In the future, we plan to give Turbopack all the tools needed to support your Webpack app.
Currently, migrating to Turbopack from Webpack is not yet possible. In the future, we're planning to offer a smooth migration path for all Webpack users to join the Turbopack future.

arthurcolle• 4 years ago

Was Vercel the original creator of webpack?

cramforce• 4 years ago

The Turbopack project is led by Tobias Koppers, creator of Webpack

eins1234• 4 years ago

Are the benchmarks used for generating the results on the website available for us to poke around in? https://turbo.build/pack

I'm curious about the "Cold Start" time for 30k modules taking 20s, which still doesn't feel like the best possible experience, even though it's a significant improvement over the other contenders listed.

Is there a separate, faster "Warm Start" time after everything is cached? Or is this it?

rattray6• 4 years ago

Surprised not to see much mention of plugins and how they will work (unless I missed something?).

Plugins are the big differentiator between Webpack and existing "webpack but faster" tools, and presumably the reason most people still use webpack. What's the plan here?

esamatti• 4 years ago

They say they plan to support Vue and Svelte via plugins so I guess it is a thing or will be.

"In future versions, we'll be supporting Vue and Svelte via plugins."

https://turbo.build/pack/docs/features/frameworks#vue-and-sv...

thedanbob• 4 years ago

https://turbo.build/pack/docs/migrating-from-webpack

It sounds like plugins will be a thing but existing webpack plugins will need to be ported.

rattray6• 4 years ago

Ah, nice find. They seem to imply plugins can be written in JS, with an API that _may_ be similar to Webpack, but definitely not drop-in compatible:

We're planning on making Turbopack very flexible and extensible, but we're not planning 1:1 compatibility with Webpack … most Webpack plugins won't work out of the box with Turbopack. However, we're working on porting several of the most popular Webpack plugins to Turbopack.

rattray6• 4 years ago

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…

leighmcculloch• 4 years ago

In several places it is mentioned as a Rust library, but I don't see any links to it. Using google search I'm not finding a Rust library named "Turbo". Is the library open source, or available on crates.io / in a public repo somewhere?

rattray6• 4 years ago

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 lives: https://github.com/vercel/turbo/tree/main/crates

jridgewell5• 4 years ago

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.

rattray6• 4 years ago

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

javiercr• 4 years ago

JavaScript is basically a Game of Thrones spin off by now.

Escapado• 4 years ago

I'm trying it out right now and currently figuring out how to add tailwindcss as a sidecar process since it's not supported yet. I'm so excited about this! I can already see myself pitching this to our project management in a few months.

desireco42• 4 years ago

I will be completely honest, Next.js is amazing and with each version it is getting better. This turbopack thing, I think they made mistake and it is distraction. This is not a problem anyone had, at least that I know. Vite is amazing and they should've built on work of others.

This is one of the Rust things, we just have to build everything from scratch :).

ilrwbwrkhv• 4 years ago

How does it compare to bun. That is what got me excited after a very long time.

sbf501• 4 years ago

How does it handle native libraries in non-main entry points?

bdcravens2• 4 years ago

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.

sharno• 4 years ago

Naming is hard, it's hard to expect everyone to be aware of all ecosystems' names and trends to choose something non-conflicting

bdcravens2• 4 years ago

Sure, though I think I'd at least Google "javascript {my cool name}" and see what comes up (in this case, the top result is Hotwire)

omnibrain• 4 years ago

The "original" Turbo is from Turbo Pascal. There still is the ancient Delphi library/component collection of Turbo Pack around: https://github.com/turbopack

EGreg2• 4 years ago

When I built the Q Platform originally, I put so much work into it, but showing it to people I mostly got one piece of feedback without them even looking: "it's called Q... and there is a library for promises called Q that is way more popular. Rename yours."

I tried to explain that it was a completely different field, and that this was a web development framework. And that we had started ours way before this library for promises. But people told me I was foolish, and refused to look at it. I think it was here on HN somewhere around 2012 or so.

Well, promises are now native in browsers and no one remembers the Q library. But I did rename our library to "Qbix". I wish though that I hadn't listened to them... things come and go, just do name it what you like!

EGreg2• 4 years ago

Here is the thread! See for yourself what happened

https://news.ycombinator.com/item?id=6053227

https://news.ycombinator.com/item?id=6053211

fragile_frogs7• 4 years ago

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/

VoidWhisperer• 4 years ago

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

fragile_frogs7• 4 years ago

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

threatofrain• 4 years ago

I kind of don't understand pure bundlers for the individual dev level; I feel that they are made for other ecosystem authors to package into a "meta-framework", such as NextJS (which used to use webpack). The devs at Vite said something similar, that although they provide a great developer experience with no/low configuration, they're really meant for other ecosystem authors.

wruza3• 4 years ago

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, Node and browsers slowly converge, so isomorphic code is less and less of an issue.

Btw, how does HN develop solo-dev apps? Do you switch between two projects? Run two separate webpack configs simultaneously? How do you share code/typedefs/dtos between them? Do you use or want to use backend HMR? Backend webpack-like import extensions?

got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works

When I finally built my perfect set of webpack configs, I deleted them after a couple of months. This complexity is “fun” to set up, but maintaining it is not something I want not working as a “devops” full time. Achievement unlocked, so to the trash it goes.

Aeolun5• 4 years ago

I use Next.js, which does both front and backend in one command. It may not be powerful enough if you need truly large API’s, but for anything I build it’s more than enough.

random_kris• 4 years ago

https://github.com/t3-oss/create-t3-app + Pnpm monorepo

trinovantes• 4 years ago

You can cut down the duplicate config with webpack-merge package. I start with a common config object that defines loaders, aliases, etc. and it gets imported by my frontend/backend/cronjob/worker targets that simply describe the entry/outputs

I also recommend installing ts-node and writing your configs in Typescript to avoid typos

Here's an old side project of mine that has 3 targets [1]. I personally don't think it's that complex but it does have hundreds of lines altogether.

[1] https://github.com/Trinovantes/MAL-Cover-CSS/tree/master/bui...

pas4• 4 years ago

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/long-poll, websockets, server sent events, localstorage, WebSQL, WASM, service workers, and so on), but the basic architectural separation of concerns remains.

...

regarding sharing things between frontend and backend: OpenAPI + openapi-generator; monorepo works okay in VSCode, etc.

many people opt for RoR-like frameworks where they don't have to write frontend JS if they can avoid it (see also htmx)

fragile_frogs7• 4 years ago

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

I did create a proof of concept how this could be done in parcel https://github.com/mochicode/parcel-fullstack-poc.

The /src folder contains:

1. /api => backend

2. /app => react frontend

3. /shared => shared code

Once everything is installed, just run "npm start" and it will:

1. build and watch your src folder

2. react hmr/fast-refresh works

3. nodemon will reload your node server when things change

4. serve your react app on localhost:8000/frontend, currently hard coded, but I could also load this from the package.json file.

Not zero-config, but it almost gets you there.

crummy• 4 years ago

Parcel seemed to fail when I had multiple entrypoints into my app that shared code. Is this such an unusual scenario?

https://github.com/parcel-bundler/parcel/issues/6310

simooooo• 4 years ago

I think this is the exact thing that caused me to leave parcel for webpack

chillfox• 4 years ago

I just spent an entire evening a few days ago trying to make Parcel work for a new project and I just couldn't get it to spit out working js and css.

The project is just a small server rendered web app (using Crystal) that I wanted to add papercss, trix, hotwire/stimulus and hotwire/turbo to (using yarn). Anyway, I never got it to output the css for papercss or the js for trix.

Webpack on the other hand, I had working in about 20min. Yeah, the config is verbose and tedious, but at least there are a lot of great docs/tutorials for just about everything for it.

fragile_frogs7• 4 years ago

IMO where Parcel shines is when you are building client side single page apps or JS/TS libraries.

I could see that it won't be the right tool for a multi page server rendered app.

phplovesong3• 4 years ago

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!

Stamp012• 4 years ago

Well, crap. I literally just moved to Vite.

ec965• 4 years ago

At this point, Vite is mature and production ready. Turbopack is still just in alpha. Doesn't even have plugins yet.

Stamp012• 4 years ago

Thank you!

agumonkey• 4 years ago

All these lazy graph recompute reminds me of 90s dag based "procedural" modelers who achieved near real time re-rendering of extremely complex data through just that.

I assume the mainstream is ready to swallow the idea.

esskay• 4 years ago

oh yay more fragmentation

DrFell• 4 years ago

You either die a JavaScript fanboy, or you webdev long enough to see yourself walk away from the unending parade of needlessness.

cantSpellSober2• 4 years ago

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 LESS] don't currently work out-of-the-box with Turbopack

Keep it this way! LESS has been dead and SCSS dying. Focus on CSS Modules please!

jacquesc3• 4 years ago

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

cantSpellSober2• 4 years ago

They still require a preprocessor. Let's push to get that stuff into CSS! Worst case run `npm install sass`.

munbun• 4 years ago

`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/

andrew_5• 4 years ago

Ah, so this is why Vercel hired Tobias. Makes sense, and it could only gain traction with a company like Vercel behind it. Webpack is legacy now, supplanted by Rollup/Vite, ESBuild, et al. The only folks I know still using webpack are stuck with it (e.g. Next users)

whalesalad• 4 years ago

Been loving vite these days and can’t think of a compelling reason to leave that ecosystem - but I’ll take this for a spin for sure.

Nathanba12• 4 years ago

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 typescript version is hidden inside your bundler, good luck dealing with constant mismatches when there are errors on either side.

EDIT: The responses pointed out that the author is the maintainer of webpack, I removed that part of the comment calling it deceptive. Maybe the entire intent is to deprecate webpack. I still think that it should be renamed to "Turbopack: our webpack successor" because calling it 'the' successor is a bit presumptuous and the article doesn't even directly say that.

dietmtnview3• 4 years ago

use webpack for bundling and typescript for typechecking. not that far off from the typescript + babel workflow and way less overhead. just use tsc as a linter.

https://iamturns.com/typescript-babel/

and someone else pointed out that esbuild drops typechecking.

https://news.ycombinator.com/item?id=33336803

Nathanba12• 4 years ago

use webpack for bundling and typescript for typechecking

This is my point, that's what I'm doing. Webpack does the typechecking and the bundling together, you don't get broken bundles when the typecheck didn't succeed (unless you really want to, you can configure that too).

and someone else pointed out that esbuild drops typechecking.

yes I know, these "faster" bundlers all drop typechecking which results in these unfair comparisons. Then I always end up spending a somewhat large amount of time checking these tools out only to realize that they are not doing a fair comparison.

bichiliad6• 4 years ago

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, without doing a lot of extra magic, they operate on one file at a time. If you use Babel with Webpack, for example, Babel just strips out your TypeScript annotations and calls it a day.

All that aside, it seems like Turbopack was literally developed with Webpack's maintainer, who claims it to be a "rust-powered successor to webpack" (his signature is quite literally on the homepage[0]).

[0] https://turbo.build/pack

Nathanba12• 4 years ago

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 and you have to wait for the IDE based type checker anyway. On every build. It just doesn't make sense to work this way, you never want a fast, silently broken build which is what you get with non-typechecked fast builds.

i_like_robots• 4 years ago

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 entire "compilation". To do this it starts by performing a glob match (according to your include/exlude rules) to find every TypeScript file within the project. Resolving and type checking the entire compilation every time the bundler calls for a transform on a file is very slow due to lots of repeated and unnecesssary work so most TS bundler plugins have to work around this. Unfortunately, they're still relatively slow so type checking and bundling code separately is often the best way to go.

notpushkin• 4 years ago

According to the article, the project is “led by the creator of Webpack” (but I'm not sure this means they can name it as the “blessed” successor).

ludwigvan• 4 years ago

Yes. Webpack is essentially going to get deprecated/unmaintained over time from what I understand, so I think it is fair the author names this the successor.

victorvosk• 4 years ago

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

Nathanba12• 4 years ago

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 currently working on and you don't care about the 15000 other files because you didn't touch them since checkout and the reasonable assumption is that they will probably still work same as tested by some other team that worked on them and committed them. However there is still one large implication: Your production build on the CI server must then at least be configured to execute both the typechecking process and then the bundling process. I still wonder though: if the typechecking is truly too slow then wouldn't it also be too slow for your iterative development. I guess if those other sections of the code are never referenced then maybe it will do okay and you don't get squiggly lines on all your imports because it won't recheck them? I have some doubts that the typescript type checker actually caches this type of work.

It is also strange because somehow every other language in the world doesn't have to separate type checking from compilation, it's only in the js world that we somehow ended up with such large amounts of code that people felt that they want that speed back from back when js could simply be loaded into the browser instantly with no compilation.

And on top of that: If Turbopack does such supposedly excellent caching now, why would this not help with a 15000 file project and let me also do typechecking in a cached way? Yes I really don't think that omitting typechecking is the way to go for development.

darepublic2• 4 years ago

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

phplovesong3• 4 years ago

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.

Nathanba12• 4 years ago

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.

darepublic2• 4 years ago

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.

tsp• 4 years ago

It’s surprising to me that new bundles mainly advertise their speed. There are other things that are so much more important for a great DX.

throwaway4good2• 4 years ago

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.

joppy2• 4 years ago

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.

throwaway4good2• 4 years ago

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.

alabhyajindal• 4 years ago

LESS GOO

fantasticsoul2• 4 years ago

It is highly recommended to try hel micro(https://github.com/tnfe/hel) in turbo，cause hel-micro is a runtime module federation SDK which is unrelated to tool chain, so any tool system can access module federation technology in seconds .

lord5et• 4 years ago

What differs webpack from other "bundlers" is it's plugins ecosystem. I use couple of them at the moment in my workflow and that's the main reason I won't migrate to turbo for some time. At least not until porting will happen. https://turbo.build/pack/docs/migrating-from-webpack#will-we...

techpression• 4 years ago

If they can come close to the beauty that is esbuild documentation, changelogs and focus on details it'd be interesting, but do we really need another tool that only touts performance and ignores the rest?

Turbopack, the successor to Webpack

Related Stories