44 ms·

Turbopack, the successor to Webpack

• darepublic 4y 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 4y 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.
• throwaway4good 4y 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.
  • joppy 4y 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.
    • throwaway4good 4y 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.
      • joppy 4y ago
        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.
• alabhyajindal 4y ago
  LESS GOO
• fantasticsoul 4y ago
  It is highly recommended to try hel micro(https://github.com/tnfe/hel 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 4y 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-be-able-to-use-webpack-plugins https://turbo.build/pack/docs/migrating-from-webpack#will-we...
• techpression 4y 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?
• tylermcginnis 4y ago
  Excited to play around with this. Congrats Tobias, Jared, and team!
• samuelstros 4y ago
  Vercel is on a streak. I am curious whether Turbopack elapses Vite like Vite elapsed Webpack over the past 12 months.
  • hmillison 4y 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 4y ago
      Rust is a hell of a drug.
    • maxfurman 4y 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.
    • brundolf 4y 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
      • IshKebab 4y ago
        I wonder how they make that robust, given that Rust isn't pure and there's no way to force a function to be pure either.
        • brundolf 4y ago
• wilg 4y ago
  My prayers for another JavaScript bundler have finally been answered!
  • aobdev 4y 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.
    • wilg 4y ago
      I'm sure it will be good, it's just so JavaScript for there to be another one of these.
• awestroke 4y ago
  Very nice
• cercatrova 4y 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&query=author%3Acercatrova%20Rust%20future&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... [1] https://rome.tools https://rome.tools
  • arvigeus 4y 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 4y ago
      Is Rome being used anywhere? I haven't heard about it for a while. Kinda figured it was dead tbh
    • cercatrova 4y 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.
      • fragile_frogs 4y ago
        I think this could benefit Rome. Both projects are written in Rust and so far they have a linter and a formatter and now they can integrate Turbopack, package it behind "rome build" and don't have to build their own bundler and transpiler.
• Emigre_ 4y ago
  If it combines the flexibility of Webpack with the performance of esbuild this is going to be great.
• ssalka 4y ago
  Literally 1 day after my team migrates our build to Vite :')
  • tr1ll10nb1ll 4y 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 4y 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!
  • rk06 4y 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 4y ago
    At least that is stable now, be happy
    • squidsoup 4y ago
      Stable API perhaps, but vite has issues with memory leaks, which can break builds in CI. https://github.com/vitejs/vite/issues/2433 https://github.com/vitejs/vite/issues/2433
  • paulbgd 4y ago
    Vite isn’t tied to its internal tools that heavily, in theory they could switch to using turbopack internally if they wished.
  • ramesh31 4y ago
• pelagicAustral 4y ago
  This now has really started to feel like the last days of Rome.
  • michael_michael 4y ago
    Bread and Javascript bundlers.
    • rizky05 4y ago
  • fny 4y ago
    For context: https://rome.tools/ https://rome.tools/
    • deleted 4y ago
      [deleted]
    • ntonozzi 4y ago
      Some extra context: https://en.wikipedia.org/wiki/Fall_of_the_Western_Roman_Empire https://en.wikipedia.org/wiki/Fall_of_the_Western_Roman_Empi....
      • alalani1 4y ago
        Thought I was on Reddit and not HN for a second
        • Rapzid 4y ago
          Nah, for extra context you are here: https://news.ycombinator.com/item?id=33334857 https://news.ycombinator.com/item?id=33334857
  • fragile_frogs 4y 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 https://rome.tools/#supported-features
• jdelman 4y 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 4y 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 4y 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.
  • fabian2k 4y 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 https://turbo.build/pack/docs/migrating-from-webpack
• ksec 4y ago
  I am wondering if Rails moved to esbuild a little too early.
  • jbverschoor 4y 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 4y ago
      you weren't kidding; that autograph is pretty tacky. the ego and marketing that goes into JS tooling is nauseating.
  • johnnypangs 4y 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 4y ago
      Automatic JSX runtime was added to esbuild in 0.14.51: https://github.com/evanw/esbuild/pull/2349 https://github.com/evanw/esbuild/pull/2349
      • johnnypangs 4y ago
        Cool, thanks for saying!
• qbasic_forever 4y 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 4y ago
    speaking of which, is it reasonable to use Bazel instead of webpack?
    • qbasic_forever 4y 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 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 4y 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.
    • draw_down 4y ago
    • hamandcheese 4y 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.
• renewiltord 4y 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.
  • Vinnl 4y 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.
    • cal85 4y 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.
      • deleted 4y ago
        [deleted]
      • Vinnl 4y ago
        Oh sorry yes, must have skipped over Rails in the long list of tools. Yeah, you'd commonly pair Next.js with a more "traditional" back-end I think, with the frontend calling out to the Next.js back-end, the Next.js back-end calling out to your regular back-end, and your regular back-end calling out to your database.
      • avarun 4y ago
        Supabase
      • 4y ago
• gmaster1440 4y 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-svelte https://turbo.build/pack/docs/features/frameworks#vue-and-sv...
  • andrew_ 4y ago
    Vite's momentum is too much to stop right now imho
• bovermyer 4y ago
  I wonder if I can use this to replace Rollup for my Svelte SPA...
  • rk06 4y ago
    Not yet. They don't have plugin support yet. And they are prioritizing Nextjs for obvious reasons
• thatswrong0 4y 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 ¯\_(ツ)_/¯
  • RussianCow 4y ago
    Indeed. Calling it a "spiritual" successor would have been more honest.
    • adammarples 4y ago
      Heir apparent maybe?
  • josefdlange 4y ago
    Not to mention explicit language about _not planning to support the Webpack API 1:1_...
  • ohbtvz 4y 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...
  • deleted 4y ago
    [deleted]
• dinvlad 4y ago
  Curious if this will be supported by react-scripts. Or is it Next.js-specific?
  • jridgewell 4y ago
    It's _currently_ Next specific, but we plan on making it generic and usable in any setup.
    • rpwverheij 4y 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 4y ago
  Is nextjs the modern rails?
  • reducesuffering 4y 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.
  • o_m 4y 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/ https://blitzjs.com/ and you'll have something that looks like rails.
    • nullandvoid 4y ago
      To throw another in the ring, I recently stumbled on https://github.com/t3-oss/create-t3-app 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?
      • no1youknowz 4y ago
        > Looks like blitz is tRPC + next auth? From what I understand Blitz is their own implementation of tRPC, their own Auth system, Prisma and Typescript support. Blitz is also more of a toolkit that wraps around NextJS currently, but later on Remix, Svelte and Vue. In future (probably in '23 and post 1.0) some things that may be coming are: - backend functionality ala NestJS - form component library - permissions (rbac) library - file upload library - and a bunch of other stuff I'm forgetting right now.
        • 4y ago
• bluelightning2k 4y ago
  Stuff like this is why I obsessively read HN. Love it. More nice work from Vercel!
• jaxn 4y 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.
• rsanheim 4y 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.
  • tshaddox 4y 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.
    • andsoitis 4y 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.
      • djbusby 4y ago
        By my count its 23 years. The biggest issue in FOSS is folk don't wanna join a "good enough" project and move it. Sometimes the project is contributor hostile (rare?) And we end up with basically: "I'll build my own moonbase with blackjack and hookers!" All that starting from scratch costs loads of impossible-to- recover-time.
        • jscheel 4y ago
          Well, that's what is really frustrating here. Turbopack is built by the creator of Webpack. So, instead of fixing the bloated megalith that webpack has become, they are just moving on to greener pastures. But this time it'll be different™
• orra 4y 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 4y 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 4y ago
  Feels like the rails community is going to be confused by the naming.
  • Toutouxc 4y 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 4y ago
      The webpacker rails 6 approach was a mistake that has been fixed with rails 7. Rails 7 offers a very good solution.
• riquito 4y 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)
  • jridgewell 4y 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.
  • encryptluks2 4y 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 4y 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.
  • jridgewell 4y ago
    We plan on supporting both. We're still in the alpha phase, and have not designed the plugin API yet.
• stillbourne 4y ago
  Does it have module federation?
  • fantasticsoul 4y ago
    You can try hel-micro(https://github.com/tnfe/hel 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。
  • TomatoTomato 4y ago
    > Well thats going to cause some problems https://twitter.com/ScriptedAlchemy/status/1585027482432180224 https://twitter.com/ScriptedAlchemy/status/15850274824321802...
• samhuk 4y 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.
  • gingerlime 4y 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 https://github.com/evanw/esbuild/issues/2317
  • phplovesong 4y 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 4y ago
    Have you tried vite? Its been a similiar experience for me
  • frizkie 4y 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.
    • verisimilidude 4y 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.
  • 4y ago
• no_wizard 4y 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 4y 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 4y 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_ 4y ago
      Vite uses it under the hood and has it running crazy fast.
      • Vinnl 4y ago
        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.
        • silverwind 4y ago
          Vite uses both esbuild and rollup for the prod build. When doing React, it also adds Babel. This chaining of tools is the reason why it's so slow.
• fabiospampinato 4y ago
  Is there any actual proof that Turbopack is 10x faster than Vite at anything? I can't find any benchmark showing it.
  • tln 4y 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.
    • omnimus 4y ago
      Just note it's not Vite but esbuild that's doing the dev bundling.
    • 323 4y 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.
      • tln 4y ago
        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.
        • 323 4y ago
          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.
  • deleted 4y ago
    [deleted]
• EastSmith 4y 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.
  • deleted 4y ago
    [deleted]
• arthurcolle 4y ago
  Was Vercel the original creator of webpack?
  • cramforce 4y ago
    The Turbopack project is led by Tobias Koppers, creator of Webpack
• Stamp01 4y ago
  Well, crap. I literally just moved to Vite.
  • ec965 4y ago
    At this point, Vite is mature and production ready. Turbopack is still just in alpha. Doesn't even have plugins yet.
    • Stamp01 4y ago
      Thank you!
  • deleted 4y ago
    [deleted]
• eins1234 4y ago
  Are the benchmarks used for generating the results on the website available for us to poke around in? https://turbo.build/pack 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?
• rattray 4y 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 4y 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-svelte https://turbo.build/pack/docs/features/frameworks#vue-and-sv...
  • thedanbob 4y ago
    https://turbo.build/pack/docs/migrating-from-webpack 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.
    • rattray 4y 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.
• rattray 4y 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 4y 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?
    • rattray 4y ago
      Right, they link to this docs page when referring to the memoization library: https://turbo.build/pack/docs/core-concepts https://turbo.build/pack/docs/core-concepts And the github link at the top of the page links here: https://github.com/vercel/turbo 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 https://github.com/vercel/turbo/tree/main/crates
      • pitaj 4y ago
        The content of that "Core Concepts" page sounds a lot like https://github.com/salsa-rs/salsa https://github.com/salsa-rs/salsa
      • jridgewell 4y ago
        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#turbo-tasks https://github.com/vercel/turbo/blob/main/architecture.md#tu...
        • rattray 4y ago
• javiercr 4y ago
  JavaScript is basically a Game of Thrones spin off by now.
  • deleted 4y ago
    [deleted]
• Escapado 4y 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 4y 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 4y ago
  How does it compare to bun. That is what got me excited after a very long time.
• sbf501 4y ago
  How does it handle native libraries in non-main entry points?
• bdcravens 4y 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 4y ago
    Naming is hard, it's hard to expect everyone to be aware of all ecosystems' names and trends to choose something non-conflicting
    • bdcravens 4y 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 4y 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 https://github.com/turbopack
  • EGreg 4y 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!
    • EGreg 4y ago
      Here is the thread! See for yourself what happened https://news.ycombinator.com/item?id=6053227 https://news.ycombinator.com/item?id=6053227 https://news.ycombinator.com/item?id=6053211 https://news.ycombinator.com/item?id=6053211
• fragile_frogs 4y 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/ https://parceljs.org/ [2] https://parceljs.org/getting-started/library/ https://parceljs.org/getting-started/library/ [3] https://parceljs.org/getting-started/webapp/ https://parceljs.org/getting-started/webapp/
  • chillfox 4y 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_frogs 4y 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.
  • phplovesong 4y 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!
  • VoidWhisperer 4y 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
• agumonkey 4y 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 4y ago
  oh yay more fragmentation
• DrFell 4y ago
  You either die a JavaScript fanboy, or you webdev long enough to see yourself walk away from the unending parade of needlessness.
• cantSpellSober 4y 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!
  • jacquesc 4y ago
    What's wrong with SCSS modules? It has a lot of really useful functionality that frontend developers like me love.
    • cantSpellSober 4y ago
      They still require a preprocessor. Let's push to get that stuff into CSS! Worst case run `npm install sass`.
    • munbun 4y 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/ https://www.w3.org/TR/css-nesting-1/
• andrew_ 4y 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 4y 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.
• bensherman228 4y ago
  [dead]
• Nathanba 4y 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.
  • victorvosk 4y ago
    Why would you want your tooling to be coupled when it doesn't have to be with zero downside?
    • Nathanba 4y 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.