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.
> 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
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.
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.
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.
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.
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
Problem with webpack is that freeform JS code is not "configuaration". Configuration presumes set amount of features driven by declarative statement.
Most of what I've seen done "in Webpack" in fact is shitty scripting in an awful language. I'm very happy to see movement away from this criminal waste of everyone's time.
Not gonna get into the details, as it's company proprietary code, but we aren't talking about a weekend project. This is a large, complex product that has a significant user-base, and it also has to handle a bunch of legacy stuff.
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.
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.
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.
IMO, The whole thing behind Rome is that it will have one tool to do everything (lint, prettify, minify, build etc), so every part in pipeline remains in sync. Using other tools for parts of it(build etc) would be against the philosophy
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?
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.
> 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 ...
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.
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!
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.
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.
> 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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Getting Next.js up to Rails feature-wise is using something that already wires up the niceties like Auth, ORM, Tailwind styles, and Typescript. Create-t3-app is a huge contender here: https://init.tips/ and https://github.com/t3-oss/create-t3-app
A DB is as simple as pressing a button on Planetscale or Railway, copying the secret strings to your .env file, and 'npx prisma db push'.
If you know and like Rails and ActiveRecord especially, then one possibility, which I intend to try on my next thing, is to build an API-only Rails app (JSON only; no HTML views) and a separate Next.js app that uses the Rails app as its backend. Although it’s two apps, it seems like it would be a really nice, clean setup to work with. You can easily deploy the Next app on something cheap and serverless like Vercel, and deploy the Rails app separately on something like EC2 or Fly.io.
I have written Next apps that just connect directly to PostgreSQL, but I always end up adding other tools in an attempt to recreate something like ActiveModel and other aspects of Rails in Next.js, and it ends up turning into a mess. I think Rails+Next would avoid this problem. It would be two apps, but each would very clearly focused and would be built following the golden path of their respective frameworks. (One thing I’m not sure about yet is how I would DRYly share endpoint schemas from Rails in order to have strong typings in the Next app based on the API endpoints. But I don’t think it should be too hard to find a nice way to do this.)
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.
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 ¯\_(ツ)_/¯
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...
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
Have you ever tried to load a development build of a project with 3000 modules in Vite? It’s like a webpack build all over again every time you load the page.
I didn't have much of any trouble in Snowpack with even the largest projects I worked on but at least with Snowpack it was easy enough to target "freeze" a sub-tree of modules into Snowpack's "web_modules" with esbuild. I don't know about Vite in that case as I haven't been convinced to actually try Vite despite Snowpack's shutdown endorsement. Recent stuff for me has either been projects still using webpack for platform reasons or ESM with hand-targeted esbuild bundles for specific module trees (libraries) without using Vite or Snowpack above that. About the only thing I feel I'm missing in those esbuild workflows is a good HMR dev server but the simplicity of using fewer, more targeted tools feels handy to me.
Even compression is maybe somewhat a non-issue with Brotli compression options (now supported by every major browser and often "required" for strong HTTP2+ support) and its hand-tuned dictionary for things like common JS delimiters/sequences. With Gzip you do sometimes need large bundles before its automatic dictionary management algorithms pick up things like that. In theory, Brotli always starts from a place of more "domain knowledge" and needs less "bulk" for good compression.
I think a lot of people assume this is the case for every website/web application without actually watching their network requests and having hard data on it. Like I said, small to medium sites and applications in some cases start to be more efficient with ESM modules than ever before (because it is the ultimate code-splitting) even before you get into new tools like HTTP2 and HTTP3 which significantly reduce connection overhead for network requests entirely and make a lot of old bundling advice outdated at best.
Plus, ESM modules always load asynchronously without DOM blocking so in any and all "progressive enhanced" sites and apps, it may feel slow to hydrate parts of it, but you generally aren't going to find a better performing experience while it hydrates. The page itself won't feel "slow" to the user because they can start reading/scrolling faster.
Some of it comes down to your framework, of course, and if you can afford SSR or are using a "progressive enhanced" style of site/application. For one specific counter-instance I'm aware of, Angular's NgModules dependency injection configuration mess routes around ESM's module loaders and creates giant spaghetti balls the browser thinks it needs to load all at once. I can't see recommending unbundling Angular apps any time soon as long as they continue to break the useful parts of ESM style loading with such spaghetti balls. Other frameworks, especially ones with good SSR support/progressive enhancement approaches are increasingly fine to start using unbundled ESM on the modern web.
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.
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.
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.
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.
I dig through other people’s codebases all day long. I really don’t want to do that in my free time as well. Especially to fix the garbage that they built in the first place.
It’s just not fun. And that’s one of the most important reasons I do this job.
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™
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.
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.
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.
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.
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.
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".
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.
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.
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).
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.
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.
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.
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.
As a performance nightmare you can't wake up from, SCSS can't die soon enough. As someone who depends on it currently though I def understand the frustration with losing support.
The new version (written in Dart of all things) seems pretty fast. The old ruby implementation was insanely slow, and the nodesass rewrite was insanely broken.
Whatever they got now though is just about perfect for me
Embedded SASS promises to be faster anyway, though still slow IMO..
There are some issues with realizing the potential though. Namely, a standard-ish CRA React app will have thousands of SCSS compilation entrypoints due to importing SCSS in individual component modules.
Lack of process reuse is causing many to see slightly SLOWER compile times. Next you have:
* Lack of tooling support: Vite?
* Need to migrate SCSS syntax
* ??
As soon as it's a free-ish upgrade with high ROI on swapping it in, I'll take it! I think SCSS is a dead-end though. Modern CSS + postcss for some CSS-Next polyfills is the way forward IMO.
> 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.
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.
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..
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.
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)
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.
330 comments
[ 3.2 ms ] story [ 395 ms ] thread> 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
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.
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?
Regardless, I like that this is fast and it is probably going to get a lot of adoption since it will be included with Next.js.
I 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
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?
> 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.
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 ...
https://github.com/vitejs/vite/issues/2433
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!
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.
> 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
> 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
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.
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.
Not mentioning speed at all here, it was never my biggest concern.
Comparing an alpha just open-sourced today to an established tool like esbuild isn't even a fair comparison, for either tool.
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.
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.
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.
[0]: https://blog.aspect.dev/rules-ts-benchmarks
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.
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.
A DB is as simple as pressing a button on Planetscale or Railway, copying the secret strings to your .env file, and 'npx prisma db push'.
I have written Next apps that just connect directly to PostgreSQL, but I always end up adding other tools in an attempt to recreate something like ActiveModel and other aspects of Rails in Next.js, and it ends up turning into a mess. I think Rails+Next would avoid this problem. It would be two apps, but each would very clearly focused and would be built following the golden path of their respective frameworks. (One thing I’m not sure about yet is how I would DRYly share endpoint schemas from Rails in order to have strong typings in the Next app based on the API endpoints. But I don’t think it should be too hard to find a nice way to do this.)
https://turbo.build/pack/docs/features/frameworks#vue-and-sv...
At least the marketing website is snazzy ¯\_(ツ)_/¯
Combine next.js with https://blitzjs.com/ and you'll have something that looks like rails.
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.
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.
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.
Currently. I’m skeptical.
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.
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.
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/
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.
If they do not bundle for prod, then initial load will cause a flood of network request and cause slowness due to a lot of network requests
Plus, ESM modules always load asynchronously without DOM blocking so in any and all "progressive enhanced" sites and apps, it may feel slow to hydrate parts of it, but you generally aren't going to find a better performing experience while it hydrates. The page itself won't feel "slow" to the user because they can start reading/scrolling faster.
Some of it comes down to your framework, of course, and if you can afford SSR or are using a "progressive enhanced" style of site/application. For one specific counter-instance I'm aware of, Angular's NgModules dependency injection configuration mess routes around ESM's module loaders and creates giant spaghetti balls the browser thinks it needs to load all at once. I can't see recommending unbundling Angular apps any time soon as long as they continue to break the useful parts of ESM style loading with such spaghetti balls. Other frameworks, especially ones with good SSR support/progressive enhancement approaches are increasingly fine to start using unbundled ESM on the modern web.
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.
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.
It’s just not fun. And that’s one of the most important reasons I do this job.
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.
Megalith? Isn't it super modular and configurable?
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.
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.
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.
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.
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.
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).
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
Whatever they got now though is just about perfect for me
There are some issues with realizing the potential though. Namely, a standard-ish CRA React app will have thousands of SCSS compilation entrypoints due to importing SCSS in individual component modules.
Lack of process reuse is causing many to see slightly SLOWER compile times. Next you have:
* Lack of tooling support: Vite?
* Need to migrate SCSS syntax
* ??
As soon as it's a free-ish upgrade with high ROI on swapping it in, I'll take it! I think SCSS is a dead-end though. Modern CSS + postcss for some CSS-Next polyfills is the way forward IMO.
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.
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.
Parcel might be a good fit for you: https://parceljs.org/
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.
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.