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.
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.
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
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.
// @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;
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.
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.
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.
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.
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).
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.
Parcel might be a good fit for you: https://parceljs.org/
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.
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.
Thankfully, Node and browsers slowly converge, so isomorphic code is less and less of an issue.
Btw, how does HN develop solo-dev apps? Do you switch between two projects? Run two separate webpack configs simultaneously? How do you share code/typedefs/dtos between them? Do you use or want to use backend HMR? Backend webpack-like import extensions?
got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works
When I finally built my perfect set of webpack configs, I deleted them after a couple of months. This complexity is “fun” to set up, but maintaining it is not something I want not working as a “devops” full time. Achievement unlocked, so to the trash it goes.
I did create a proof of concept how this could be done in parcel https://github.com/mochicode/parcel-fullstack-poc.
The /src folder contains:
1. /api => backend
2. /app => react frontend
3. /shared => shared code
Once everything is installed, just run "npm start" and it will:
1. build and watch your src folder
2. react hmr/fast-refresh works
3. nodemon will reload your node server when things change
4. serve your react app on localhost:8000/frontend, currently hard coded, but I could also load this from the package.json file.
Not zero-config, but it almost gets you there.
I also recommend installing ts-node and writing your configs in Typescript to avoid typos
Here's an old side project of mine that has 3 targets [1]. I personally don't think it's that complex but it does have hundreds of lines altogether.
[1] https://github.com/Trinovantes/MAL-Cover-CSS/tree/master/bui...
https://m.youtube.com/watch?v=oCiGjrpGk4A
but more importantly, I recommend embracing the frontend-backend separation. it's important in desktop contexts too. after all, you don't want to block the UI thread with waiting for I/O, right?
of course the last ~2 decades were about coming up with various hacks, workarounds, solutions to make the whole threshold easier to pass (from Java applets to Ajax/XHR, comet/long-poll, websockets, server sent events, localstorage, WebSQL, WASM, service workers, and so on), but the basic architectural separation of concerns remains.
...
regarding sharing things between frontend and backend: OpenAPI + openapi-generator; monorepo works okay in VSCode, etc.
many people opt for RoR-like frameworks where they don't have to write frontend JS if they can avoid it (see also htmx)
The project is just a small server rendered web app (using Crystal) that I wanted to add papercss, trix, hotwire/stimulus and hotwire/turbo to (using yarn). Anyway, I never got it to output the css for papercss or the js for trix.
Webpack on the other hand, I had working in about 20min. Yeah, the config is verbose and tedious, but at least there are a lot of great docs/tutorials for just about everything for it.
I could see that it won't be the right tool for a multi page server rendered app.
EDIT: The responses pointed out that the author is the maintainer of webpack, I removed that part of the comment calling it deceptive. Maybe the entire intent is to deprecate webpack. I still think that it should be renamed to "Turbopack: our webpack successor" because calling it 'the' successor is a bit presumptuous and the article doesn't even directly say that.
All that aside, it seems like Turbopack was literally developed with Webpack's maintainer, who claims it to be a "rust-powered successor to webpack" (his signature is quite literally on the homepage[0]).
This is the point folks really must understand when setting up a new tooling pipeline to deal with TypeScript. Certainly all of the module bundlers I'm aware of operate in this way.
To explain further for anyone curious; for TSC to work effectively it must construct and understand the entire "compilation". To do this it starts by performing a glob match (according to your include/exlude rules) to find every TypeScript file within the project. Resolving and type checking the entire compilation every time the bundler calls for a transform on a file is very slow due to lots of repeated and unnecesssary work so most TS bundler plugins have to work around this. Unfortunately, they're still relatively slow so type checking and bundling code separately is often the best way to go.
maybe it is common, I can't speak to that but in my opinion a large part of the success of webpack was probably because they bundled the typechecking. Because that's the only workflow that makes sense, imagine a c# compiler that quickly outputs executable IL code but half the time it's broken because it didn't do any type checking and you have to wait for the IDE based type checker anyway. On every build. It just doesn't make sense to work this way, you never want a fast, silently broken build which is what you get with non-typechecked fast builds.
Im a user of esbuild, and its so fast it can recompile on each save (see esbuild `serve` option) and i wont notice anything locally. Theres also a watch mode, and production build with minify.
So i work locally without a typecheck for my builds, and let my LSP client do the type checking. When i bundle for prod i run an additional tsc for type checks before the bundle is produced. Takes a few secs more (as tsc is slow) but this is a nonissue.
I thought about it even more and I think I can finally see the possibly true reason why people are developing these type of bundlers: The typescript projects that they have to work on are so huge that the typechecking is always going to be too slow so you don't want to deal with it, you rather typecheck only the file that you're currently working on and you don't care about the 15000 other files because you didn't touch them since checkout and the reasonable assumption is that they will probably still work same as tested by some other team that worked on them and committed them. However there is still one large implication: Your production build on the CI server must then at least be configured to execute both the typechecking process and then the bundling process. I still wonder though: if the typechecking is truly too slow then wouldn't it also be too slow for your iterative development. I guess if those other sections of the code are never referenced then maybe it will do okay and you don't get squiggly lines on all your imports because it won't recheck them? I have some doubts that the typescript type checker actually caches this type of work.
It is also strange because somehow every other language in the world doesn't have to separate type checking from compilation, it's only in the js world that we somehow ended up with such large amounts of code that people felt that they want that speed back from back when js could simply be loaded into the browser instantly with no compilation.
And on top of that: If Turbopack does such supposedly excellent caching now, why would this not help with a 15000 file project and let me also do typechecking in a cached way? Yes I really don't think that omitting typechecking is the way to go for development.
https://iamturns.com/typescript-babel/
and someone else pointed out that esbuild drops typechecking.
This is my point, that's what I'm doing. Webpack does the typechecking and the bundling together, you don't get broken bundles when the typecheck didn't succeed (unless you really want to, you can configure that too).
>and someone else pointed out that esbuild drops typechecking.
yes I know, these "faster" bundlers all drop typechecking which results in these unfair comparisons. Then I always end up spending a somewhat large amount of time checking these tools out only to realize that they are not doing a fair comparison.
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?
> 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
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!
You'll still need to keep tsc around for that, though perhaps you're doing that with another step in Webpack...?
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.
Not mentioning speed at all here, it was never my biggest concern.
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.
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.
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.
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.
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.
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
I just checked a code base that's at ~900 modules, and vite is ready to serve dev requests in well under a second.
If you reload the second time will be much faster since it will serve from it's memory cache.
Combine next.js with https://blitzjs.com/ and you'll have something that looks like rails.
Looks like blitz is tRPC + next auth?
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.
> 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
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.
I noted that esbuild doesn't fully support es5 transpilation and this will hold it back from some usage.
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?
It sounds like plugins will be a thing but existing webpack plugins will need to be ported.
> 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.
"In future versions, we'll be supporting Vue and Svelte via plugins."
https://turbo.build/pack/docs/features/frameworks#vue-and-sv...
Bummer! Do I need a turbopack.config.js?
I've still got my package.json, tsconfig.json, .env, and postcss.config.js apparently.
> [Turbopack cannot currently be configured with plugins. We plan to make Turbopack extensible, likely with an altered API]
Will I be able to use my current plugins? Where does config for these plugins live?
> [SCSS and LESS] don't currently work out-of-the-box with Turbopack
Keep it this way! LESS has been dead and SCSS dying. Focus on CSS Modules please!
`sass` (dart-sass) is the current iteration but it’s an order of magnitude slower for larger projects with many small scss module files. I’ve seen it add +10 to 30 seconds.
`sass-embedded` will be the next iteration for dart-sass but in its current form still suffers from similar issues.
I believe using postcss for nesting support + css variables is a better alternative, considering that css will likely get native nesting support in a few years.
> 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.
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.
At least the marketing website is snazzy ¯\_(ツ)_/¯
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...
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?
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 ...
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!
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.
I think writing build tools for JavaScript in anything other than JavaScript (or language that compiles to js) is a dead end.
How would you write a plug-in to this? Or a programmatic configuration. So much gained from staying on js.
The advantage of having an incredibly fast build tool can already be seen with Vite and esbuild, which hot-reload modules at speed. Fast tools can change the way work is done.
https://twitter.com/ScriptedAlchemy/status/15850274824321802...
https://turbo.build/pack/docs/features/frameworks#vue-and-sv...
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 assume the mainstream is ready to swallow the idea.
This is one of the Rust things, we just have to build everything from scratch :).
Currently. I’m skeptical.
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?
> 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.