[HN Gopher] Turbopack, the successor to Webpack
___________________________________________________________________
Turbopack, the successor to Webpack
Author : nutlope
Score : 426 points
Date : 2022-10-25 17:35 UTC (5 hours ago)
(HTM) web link (vercel.com)
(TXT) w3m dump (vercel.com)
| orra wrote:
| 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.
| pelagicAustral wrote:
| This now has really started to feel like the last days of Rome.
| michael_michael wrote:
| Bread and Javascript bundlers.
| fny wrote:
| For context: https://rome.tools/
| [deleted]
| ntonozzi wrote:
| Some extra context: https://en.wikipedia.org/wiki/Fall_of_the
| _Western_Roman_Empi....
| alalani1 wrote:
| Thought I was on Reddit and not HN for a second
| Rapzid wrote:
| Nah, for extra context you are here:
| https://news.ycombinator.com/item?id=33334857
| mosdl wrote:
| 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 wrote:
| Feels like the rails community is going to be confused by the
| naming.
| Toutouxc wrote:
| 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 wrote:
| The webpacker rails 6 approach was a mistake that has been
| fixed with rails 7. Rails 7 offers a very good solution.
| rattray wrote:
| 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 wrote:
| 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 wrote:
| 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
| pitaj wrote:
| The content of that "Core Concepts" page sounds a lot like
| https://github.com/salsa-rs/salsa
| jridgewell wrote:
| 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#t
| u...
| rattray wrote:
| gotcha, cool - thank you!
| jridgewell wrote:
| 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.
| rattray wrote:
| Ah, very helpful/interesting - thank you! Seems neat.
| no_wizard wrote:
| 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 wrote:
| 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 wrote:
| 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.
| riquito wrote:
| 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 wrote:
| 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 wrote:
| 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.
| agumonkey wrote:
| 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.
| bdcravens wrote:
| 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 wrote:
| Naming is hard, it's hard to expect everyone to be aware of all
| ecosystems' names and trends to choose something non-
| conflicting
| bdcravens wrote:
| 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 wrote:
| The "original" Turbo is from Turbo Pascal. There still is the
| ancient Delphi library/component collection of Turbo Pack
| around: https://github.com/turbopack
| EGreg wrote:
| 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!
| [deleted]
| Escapado wrote:
| 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.
| tylermcginnis wrote:
| Excited to play around with this. Congrats Tobias, Jared, and
| team!
| thatswrong0 wrote:
| 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 -\\_(tsu)_/-
| josefdlange wrote:
| Not to mention explicit language about _not planning to support
| the Webpack API 1:1_...
| [deleted]
| ohbtvz wrote:
| 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 wrote:
| Indeed. Calling it a "spiritual" successor would have been more
| honest.
| adammarples wrote:
| Heir apparent maybe?
| arthurcolle wrote:
| Was Vercel the original creator of webpack?
| cramforce wrote:
| The Turbopack project is led by Tobias Koppers, creator of
| Webpack
| ksec wrote:
| I am wondering if Rails moved to esbuild a little too early.
| omnimus wrote:
| esbuild is just fine. It's so much easier to use than webpack.
| Speed is not only reason why people like esbuild over webpack.
| johnnypangs wrote:
| 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 wrote:
| Automatic JSX runtime was added to esbuild in 0.14.51:
| https://github.com/evanw/esbuild/pull/2349
| rsanheim wrote:
| 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.
| petepete wrote:
| 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.
| jbverschoor wrote:
| 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 wrote:
| you weren't kidding; that autograph is pretty tacky. the ego
| and marketing that goes into JS tooling is nauseating.
| qbasic_forever wrote:
| 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 wrote:
| speaking of which, is it reasonable to use Bazel instead of
| webpack?
| bombela wrote:
| 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.
| qbasic_forever wrote:
| 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.
| hamandcheese wrote:
| 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.
| draw_down wrote:
| gmaster1440 wrote:
| 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...
| fabiospampinato wrote:
| Is there any actual proof that Turbopack is 10x faster than Vite
| at anything? I can't find any benchmark showing it.
| tln wrote:
| 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 wrote:
| Just note it's not Vite but esbuild that's doing the dev
| bundling.
| 323 wrote:
| 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.
| [deleted]
| ohmahjong wrote:
| 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
| dinvlad wrote:
| Curious if this will be supported by react-scripts. Or is it
| Next.js-specific?
| jridgewell wrote:
| It's _currently_ Next specific, but we plan on making it
| generic and usable in any setup.
| bluelightning2k wrote:
| Stuff like this is why I obsessively read HN. Love it. More nice
| work from Vercel!
| samuelstros wrote:
| Vercel is on a streak. I am curious whether Turbopack elapses
| Vite like Vite elapsed Webpack over the past 12 months.
| vidyesh wrote:
| 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?
| hmillison wrote:
| according to the article, Turbopack is 10-20x faster than Vite.
| I wonder how they were able to edge it out so significantly!
| hardwaregeek wrote:
| Incremental compilation plus not having each dependency be
| its own network request (I work on Turbo, but not Turbopack).
| atfzl wrote:
| 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.
| FractalHQ wrote:
| Coincidentally, the primary maintainer of Rollup mentioned
| plans for a rust rewrite in his recent talk at Vite Conf.
| minimaxir wrote:
| Rust is a hell of a drug.
| maxfurman wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| It's not very hard to stick to a pure-ish style even in
| languages that don't statically enforce it; JavaScript's
| MobX framework has the same constraint, as do React
| functions, and computed properties in Vue, etc. You don't
| really get any static help with functional purity in
| those cases, but thousands of programmers do it
| successfully every day
|
| And while Rust doesn't _strictly_ enforce purity, it does
| make it a lot easier to stick to in practice with its
| explicit `mut` keyword for local variables, references,
| and function arguments (including for the `self` argument
| on methods). There are various ways like RefCell to get
| around this if you 're really trying to, but you have to
| go out of your way.
| fabian2k wrote:
| 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.
| lelandfe wrote:
| Which makes me wonder if the speed comparison graphics are
| solely about repeat builds.
| JoshGlazebrook wrote:
| If the configuration is a nightmare like webpack then not
| likely.
| onion2k wrote:
| 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.
| jscheel wrote:
| Currently looking at a 1000 line webpack config..........
| onion2k wrote:
| You're either doing something complicated or you're not
| using Webpack very well. Most Webpack config I've worked
| with isn't like that.
| jscheel wrote:
| It's justifiable for the level of complexity it is
| handling, but it does mean that trying to switch to a
| different build process is gonna be _painful_.
| meowtimemania wrote:
| What does your 1000 line webpack config do?? I think part
| of the problem with webpack is it gives users the freedom
| to create 1000 line configs even though they'd be fine
| with a smaller more simple config
| eins1234 wrote:
| 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?
| fragile_frogs wrote:
| 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 wrote:
| 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_frogs wrote:
| And when you try to upgrade just one plugin everything breaks
| and you have to upgrade everything.
| bovermyer wrote:
| I wonder if I can use this to replace Rollup for my Svelte SPA...
| esskay wrote:
| oh yay more fragmentation
| wilg wrote:
| My prayers for another JavaScript bundler have finally been
| answered!
| aobdev wrote:
| 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.
| renewiltord wrote:
| 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 wrote:
| 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 wrote:
| 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.
| renewiltord wrote:
| Okay, great, I'll just use Next.js with PostgreSQL.
| avarun wrote:
| Supabase
| jaxn wrote:
| 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.
| desireco42 wrote:
| 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 :).
| EastSmith wrote:
| 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]
| awestroke wrote:
| Very nice
| ilrwbwrkhv wrote:
| How does it compare to bun. That is what got me excited after a
| very long time.
| cercatrova wrote:
| 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 wrote:
| 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
| cercatrova wrote:
| 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.
| arafat_stan wrote:
| Is Rome being used anywhere? I haven't heard about it for a
| while. Kinda figured it was dead tbh
| akira2501 wrote:
| 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?
| cercatrova wrote:
| 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 wrote:
| > 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 ...
| cercatrova wrote:
| 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.
| rsanheim wrote:
| 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.
| cldellow wrote:
| > 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/
| nobleach wrote:
| 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.
| WorldMaker wrote:
| 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.
| tshaddox wrote:
| 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.
| WorldMaker wrote:
| 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".
| andsoitis wrote:
| 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 wrote:
| 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.
| josephg wrote:
| Yeah. I'm consistently surprised and disappointed by how
| much resistance people have to getting their hands dirty
| digging through other people's codebases. It's
| fantastically useful, and a remarkable way to learn new
| approaches and techniques.
|
| The world doesn't need yet another JS bundler. It needs
| the one js bundler that works well with the wide variety
| of niche use cases.
| jscheel wrote:
| 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(tm)
| noahtallen wrote:
| I mean, there's really only so much you can do. If major
| changes are required, you can either make a significant
| new version with massive compatibility issues, splitting
| the community (ala Python 2 & 3). And even then, you're
| still building off of the old code.
|
| Or start from scratch and make something better.
|
| Either way, you split the community, but at least with
| the new tool you can (hopefully) manage to make it a lot
| better than a refactor would have been. (In some areas,
| anyways.)
|
| Plus, this allows the old project to continue on without
| massive breaking changes, something its users probably
| appreciate. And this old project can still create new
| major versions if needed, which is something you don't
| get if you have a major refactor because everything
| meaningful gets shipped to the refactored version.
|
| So I think spinning off a new project is a net good here.
| It doesn't impact webpack very much unless people ditch
| it and stop maintaining it (unlikely). It lets them
| iterate on new ideas without maintaining compatibility.
| (Good, when the big issue with webpack is its
| complexity.)
|
| So if the idea turns out to be bad, we haven't really
| lost anything.
| derekdahmer wrote:
| Webpack 5 was that push to fix the monolith. I would
| guess that after that herculean upgrade effort that the
| creator of Webpack has a pretty good idea of what's
| fixable and what's an inherent limitation of the existing
| tool.
| andsoitis wrote:
| Microsoft has been able to evolve Windows and Office and
| SQL Server for decades, with huge customer bases...
| derekdahmer wrote:
| That's really not what's going on here.
|
| All the previous gen bundlers are written in JS and
| support a giant ecosystem of JS plugins. There's no
| incremental way to migrate those projects to Rust. The
| benefit of these new bundlers is that they are literally
| full rewrites in a faster language without the cruft of a
| now mostly unnecessary plugin API.
|
| And the "cost" of this? Some of these new bundlers are
| written by just 1 or 2 core contributors. Turns out with
| the benefit of hindsight you can make a much better
| implementation from scratch with far less resources than
| before.
| [deleted]
| derekdahmer wrote:
| Webpack was flexible and "good enough." But it turns out
| rust-based bundlers are 10-100x faster and so the
| definition of "good enough" has changed, for good reason.
|
| It's hard to overstate how game changing this new wave of
| zero-config, ultrafast rust bundlers are for the day-to-day
| dev experience.
| tshaddox wrote:
| For me the age of JavaScript isn't particularly important.
| I just don't think any one of the well-known options are
| good enough that I would want the community to throw a big
| portion of support behind it.
| danenania wrote:
| 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.
| shrimpx wrote:
| Is rollup still a thing?
| netghost wrote:
| Rollup is used by some of these tools. For instance vite uses
| rollup for production builds.
| TN1ck wrote:
| Yes, e.g. Vite uses Rollup for production builds. Vite uses
| esbuild for development with plans to make it usable for
| production builds.
| mklepaczewski wrote:
| 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.
| shrimpx wrote:
| Yeah I just learned about Vite a few days ago, and
| Turbopack today.
|
| Apparently rollup is used under the hood by Vite, and the
| plugins and config syntax are compatible, but I couldn't
| get my rollup config to work with Vite.
| chrisoakman wrote:
| 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 wrote:
| 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.
| [deleted]
| lewantmontreal wrote:
| 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.
| encryptluks2 wrote:
| 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.
| williamdclt wrote:
| very much doubt that it's the bootcamp-devs-without-real-
| experience developping new-gen bundlers and transpilers
| pjmlp wrote:
| Indeed they do left pad instead.
| jacquesc wrote:
| 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
| pjmlp wrote:
| Yeah, it really pains me that Sitecore is doubling down on
| them as the main FE framework.
| truthwhisperer wrote:
| Rapzid wrote:
| 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.
| jacquesc wrote:
| The new version (written in Dart of all things) seems
| pretty fast. The old ruby implementation was insanely slow,
| and the nodesass rewrite was insanely broken.
|
| Whatever they got now though is just about perfect for me
| michaelmior wrote:
| > 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 wrote:
| // @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?
| TAForObvReasons wrote:
| 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.
| verisimilidude wrote:
| 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.
| sbf501 wrote:
| How does it handle native libraries in non-main entry points?
| javiercr wrote:
| JavaScript is basically a Game of Thrones spin off by now.
| [deleted]
| Scarbutt wrote:
| Is nextjs the modern rails?
| o_m wrote:
| 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 wrote:
| 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?
| no1youknowz wrote:
| > 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.
| flybayer wrote:
| Blitz actually came first, so trpc is an alternative
| implementation of RPC.
|
| Blitz auth was developed at the same time as next auth,
| and takes a more imperative approach which allows you to
| build more custom auth flows.
| wtf242 wrote:
| 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
| IceHegel wrote:
| 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 wrote:
| We plan on supporting both. We're still in the alpha phase, and
| have not designed the plugin API yet.
| Emigre_ wrote:
| If it combines the flexibility of Webpack with the performance of
| esbuild this is going to be great.
| stillbourne wrote:
| Does it have module federation?
| TomatoTomato wrote:
| > Well thats going to cause some problems
|
| https://twitter.com/ScriptedAlchemy/status/15850274824321802...
| ssalka wrote:
| Literally 1 day after my team migrates our build to Vite :')
| rk06 wrote:
| While turbo pack may be faster, you should take such benchmarks
| with a huge grain of salt. At least, they are peer verified
| PaulBGD_ wrote:
| Vite isn't tied to its internal tools that heavily, in theory
| they could switch to using turbopack internally if they wished.
| ramesh31 wrote:
| esbuild is good. you made the right choice.
| szundi wrote:
| At least that is stable now, be happy
| squidsoup wrote:
| Stable API perhaps, but vite has issues with memory leaks,
| which can break builds in CI.
|
| https://github.com/vitejs/vite/issues/2433
| somishere wrote:
| Lucky, that could have been an uphill battle
| samhuk wrote:
| 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.
| adamparsons wrote:
| 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.
| lelandfe wrote:
| 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...?
| moron4hire wrote:
| During hour to hour development, I just let Visual Studio
| tell me about the errors as they come up. On the rare
| occasions I don't already have the editor open before
| deploying, I have a shell script to kick off the right tsc
| invocation. Otherwise, bundling plus uploading to the
| server is just another shell script. Yes, a full type check
| from scratch is slow, but it doesn't come up that often.
| simlevesque wrote:
| To anyone who wants to do this:
|
| Let's say you have a tsconfig.json. Create a tsconfig-
| test.json like this: {
| "compilerOptions": { "noEmit": true,
| "skipLibCheck": true },
| "extends": "./tsconfig.json", "include":
| ["./\*/*.ts", "./\*/*.d.ts"] }
|
| Add a script to your package.json (I use "test-types")
| ... "scripts": { "test-
| types": "tsc --project ./tsconfig-test.json", ...
|
| Then you can "yarn test-types" quickly. I use husky[1] to
| run that command as a git pre-commit hook. My team cannot
| commit Typescript errors. Additionally I have a strict
| tsconfig and a strict eslint config (with these
| plugins:sonarjs, @typescript-eslint, simple-import-sort)
| which prevents "any" types and bad typescript hygiene.
| Results in faster code reviews.
|
| [1] https://www.npmjs.com/package/husky
| lelandfe wrote:
| > I use husky[1] to run that command as a git pre-commit
| hook. My team cannot commit Typescript errors.
|
| Sadly would not do much for me - I do fast and quick
| commits, and autosquash later, so Husky and co. quickly
| get turned off out of necessity.
|
| But, of course, `test-types` being ran in a CI
| environment will prevent _merging_ those errors, which is
| the real goal :)
| rtpg wrote:
| You don't need webpack to run tsc. You can treat typescript
| as a linter and run it seperately (it also has a fast watch
| mode)
| frizkie wrote:
| 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.
| Stamp01 wrote:
| Well, crap. I literally just moved to Vite.
| jdelman wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| rattray wrote:
| 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?
| thedanbob wrote:
| 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 wrote:
| 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.
| esamatti wrote:
| 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...
___________________________________________________________________
(page generated 2022-10-25 23:00 UTC)