Rolldown is here, can it save Vite?
Вставка
- Опубліковано 1 січ 2025
- 2024 has been a wild year for bundlers. RsPack, Farm, Bun, and now Rolldown is here. Oh boy...
Thank you SingleStore for sponsoring! Check them out at: soydev.link/si...
SOURCES
rolldown.rs/
github.com/rol...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4seon3 for the awesome edit 🙏
Save Vite from what? Vite is perfect
that means you never use vite in a huge project
From Rollup
@@vanness1868 nope, no problems here, better than anything else out there by far
It’s good for like a single goal. Try to have web component and WASM libraries in there and other things and the caching becomes hell on earth and css bundling sucks
From ecmascript
Sadly a lot of things aren’t correct in the benchmark (no native vite plugins enabled, vite plugin react isn’t necessary etc etc) :/
Could’ve been easily prevented by reaching out to the rolldown team or Evan directly. I see parallels to the SSR benchmark a few months ago here where the same issues happened - and you’ve also discussed these on the channel here.
please create a video with this content
wait, vite needed saving?
From Rollup
Yeah, Vite technically uses two different bundling process for dev and prod.
I had the same reaction 😂
Vite is a toy, most of the time to us
@@ryanmartin90webpack is a meme and so is turbopack
Working at Atlassian as a bundler engineer. We are currently rewriting Parcel in Rust under the creatively named Atlaspack bundler. In our experimental pre-pre-releases we've seen build times go from 1 hour to 45 seconds 🔥
Super fun project to work on. Very cool the approach Rolldown is taking on their Nodejs worker model!
I love that you call it „experimental pre-pre-release“. 🤣
Doesn’t the Parcel already includes a lot of Rust in performance sensitive pieces?
@@pawelblaszczyk__ mostly just the expensive plugins like import resolution and typescript type stripping.
Our work is to replace the core with an API compatible Rust based core. Many of the plugins can remain in JavaScript.
The core is where the sausage is made. It manages a worker pool, handles scheduling calling out to plugins, and builds the data structures that eventually end up the bundles spit out on the other side.
The Nodejs core uses Nodejs Worker threads and shared array buffers. It's actually really fast and a good case study for how far you can actually push node - but no match for Rust's multi threading model
@@DavidAlsh cool to know, thanks a lot!
As an old C++ developer, I'm amazed at build times for JS tools.
When I was your age, I worked on projects that took HOURS to build. 👴
The kids these days complain about builds taking 30 seconds!
P.S. Get off my lawn! 😁
Also we complain when our internet is slower than 100mbps
Did you also walk 10 miles to school in the snow, uphill, both ways? 😜
To be fair, a C++ build is turning code into an extremely efficient binary.
A JavaScript build turns JavaScript into more JavaScript
@@tonyb3123yeah compiling to binary is wayyy harder than transpiling to js
@ I hate when people say “compile ts to js”
Dude it’s literally find and replace.
Calling that “compiling” when gcc and optimizations exist is really…
Also in the Gen 0 category: Grunt and Gulp.
Gulp was actually nice.
@@miran248 and grunt was horrible
Its a task runner!
phew i skip that era. i am still use PHP at that time haha
@@lutfiikbalmajid lucky you. the configuration was quite often a nightmare
Esbuild is actually way more powerful than people relise. That is my only “bundler” for years now. It handles bundling into single js file with “-bundle” and it has a dev server. Plugin api is quite good. It even handles new css nesting syntax and can downscale it. It works with css modules out of the box.
This! I guess esbuild limitations then are more it's lack of more advanced code splitting? Wonder why it's not good enough for vite
@@MrAzulay maybe TS people just don't like go as much, or the esbuild people are not that open to implementing these things. if the reason is legit just "because of go" then that's really disappointing, wasting so much time rewriting something instead of just retooling what was already good enough. I do get it a bit though, for the purposes of writing a bundler, rust has better language tools than go.
@@MrAzulay vite actually needs advanced plugin system, that esbuild does not provide. Vite relies on rollup plugins. Most of them are not compatible with esbuild.
Go sucks for WASM
@@MrAzulay In production you **need** to be able to more precisely control the chunks. esbuild has a very strict chunking default and no configurability, so it's not uncommon for a real app to end up with dozens or even hundreds of small chunks that the devs have no way to optimize for.
Informative, but there was no 'peace nerds' and thus I am doomed to war. :(
how the f can you use [insert random js framework] instead of nextjs? **signals army to march**
Agreed, I didn't notice that the video ended.
My theory on the slower build time is the memory ceiling. This is *the* wall Astro runs into building MDX at scale today. Once you cross a threshold by even a few files, a 10 second build could easily become 30 seconds+. Fingers crossed the memory ceiling is harder to hit in rolldown! But building a React file that big... yeah, not surprised 😅
These compiler and bundler devs are crazy impressive to me
Based on this video I just replaced rollup with rolldown on a project and indeed, don't need a typescript plugin anymore. Transition was graceful. Rolldown also pointed out that I had forgotten to put type="module" in my package.json, which rollup hadn't informed me about.
The one thing I fear about rolldown is that rollup got reeeeeally good at tree shaking...a rewrite could have subtle differences that include much more of the code in the bundle which is a shame
Sadly this is actually a valid concern 😢
Who cares, it's only 7kb gzipped /s
@@paoloricciuti my concern was more on tree shaking server side code in the client bundle, and OPs is possibly talking about the same or the whole code base.
Not sure what 7kb you're referring to?
@ sounds promising and fantastic definitely looking forward to it 🥰
They'll eventually get to rollup's level using all their tests and get more of them to pass over time.
I've built my own bespoke framework with ESBuild as the bundler and it outputs either to one big file or splits out files when dynamically imported or set as entry points. It has minification, tree-shaking as well as splitting all as configuration options so the comment by Theo about it outputting too many files is nonsense or at the very least extremely outdated information. ESBuild might have some gaps but not what was mentioned in the video.
Not mentioning rspack/rsbuild is CRAZY btw. Easily the smoothest migration from Webpack, and it is production-ready now.
Also migrating from Webpack to Vite isn't really possible once your codebase is large enough, due to unbundled development making things very tricky.
Agreed. RSPack completely beat Vercel to market.
RsPack is the GOAT. Theo knows about RsPack and will probably release some vids soon Im hoping
Also good to mention in the gen2 list is: Rspack, basically a webpack rewrite to Rust. However they did not rework the API to be more user friendly, like what Parcel did
that hot reloading reminded me of the first time I was doing HTML + CSS in Atom and found a HTML Preview extension. Seeing your changes in real time made it so much more comfortable while also improving my productivity because I immediately saw errors and could correct them
i felt the "i learned a lot"
5:03, ESBuild is actually pretty nice for packages which do not need to put everything in a single file
10k files compiled in 10 seconds sounds great to me
Is Turbopack expected to be an API-compatible Webpack? I thought that was why Rspack is a thing? I've had the impression that Turbopack was a re-imagining of Webpack but perhaps my perception is off?
Turbopack is a balloon
It isn't going to be API-compatible, no. Supposedly, they redesigned it in order to make configuration simpler though I have yet to try their API, bundler output should be an exact match to webpack though considering the amount of tests they got going for that; unsure if rspack tries to keep the same consistency level as turbopack on that end
After doin a lot of projects in Next JS, i just did a test with Vite + Express, made a full fledged e commerce application, idk what's wrong woth vite, it is just perfect to me
I love all your videos, but these excalidraw breakdown videos are next level awesome in their educational breakdown of things. I want a playlist of these types of videos. I watch all your videos but I want to revisit specific ones like this but since you release so many videos (thank you), it’s hard to know which videos are like this
Yeah I need to make a playlist of these for sure
Browserify got written out of history
3:40 Gentoo mentioned!!!!1!!1!
Gentoo, by the way 😂
I've had to refactor a number of clients out of the delusion of "no build" guys, and no build almost never scales. And it's almost vanilla JS guys and it's like... just becuase you CAN doesn't mean you SHOULD. Talking messy code bases where no one can find their way around it becuase someone was too opinionated and not flexible enough to just ask, whats the best tool for the job and scope.
I use esbuild also for mengling and minifying. Works great. What do I miss here?
It’s missing configurable code splitting
@@azizsafudin good point. But wouldn't it be easier to add this to esbuild than to create yet another bundler.
@@StephanHoyer I believe the point of rewriting Rollup was to maintain backwards compat with the Rollup ecosystem. ESBuild is great, but I don't think you could reasonably call it "highly customizable". If you tried to make it as flexible as Rollup, you'd just end up with ESBuild turning into Rollup, but with a smaller ecosystem.
@@eldarshamukhamedov4521 sounds reasonable. Thanks for the explanation
2:25 - Devin already taking our jobs
Theo: eabuild is good for dev but not recommended for production
Every Remix dev who is not using Remix Vite yet: what do you mean?
Now imagine, if in addition to bundling, we could actually compile the code to some intermediary output, such as wasm and then load that in the browser w/o js - that would be huge! Endgame even.
Endgame in what way? Are you being dramatic?
@@roberthernandez5802 Haha, a little bit. Just thinking quietly on what could be the next big thing, once the dust (around bundlers) settles. Hoping to see more on the compilers front (code analysis, optimizations, ..), even if it compiles back to js (and not wasm). Some people are already working on ts + llvm.
I'm curious, why would you ever want to compile js to wasm??
@@roberthernandez5802he is talking about ready parsed ASTs. There is a current TC39 proposal for this to be implemented in JS.
Browsers spend an ungodly amount of time simply parsing your JS and turning it into AST for the engines to run. Sometimes several seconds.
If we could take for example, the entire implementation of React + React-DOM and ship it as pure AST, 100ms - 2seconds (depending on device) will be shaved off TTI score.
Even more powerful for evil frameworks like next that use JS injection of several kilobytes of JSON data for hydration. This completely KILLS performance.
this is an explored concept. however, due to how good javascript engines are nowadays at running javascript, you’d actually lose in both performance & file size. the dynamic nature of js means you’ll need to reimplement a mini js runtime (that’s probably a scrappier version of whatever js engine on the browser), be unable to support many of js’s features, lose any resemblance of interop with idiomatic js code, or any combination of the above. you can see prior work in assemblyscript (js to wasm), closure compiler (js to compiled js), v8 snapshots (js to v8 ir, commonly used for electron/node/react native)
whats your thought on rspack?
Can't wait for rust bundlers to be prod ready
by then we will have Assembly bundlers
Thanks for trying this out!
If I’m
Starting NOW, which is the best to get set up with
ofc vite
@ cheers. I’ve been so ad hoc in the past. But I need to get a good environment set up for this years projects.
people remembering what running native code feels like!
0:00 Introduction to Roll Down and Bundler Evolution
1:25 Single Store Database Performance
1:50 Generational Overview of JavaScript Bundlers
3:15 ES Build and Turbo Pack: New Approaches to Bundling
4:57 Roll Down Performance Comparison and Benefits
9:20 Real-World Performance Testing with Roll Down
11:00 Roll Down's Impact on Dev and Production Builds
16:00 Why Bundlers are Still Necessary
18:00 Future of Bundlers and Web Development
Generated by Snorvia AI chapter generator
You forgot about Grunt and Gulp
You can use Esbuild to combine multiple files into one. You just have to tell it to
What specs of your laptop? Thank you.
You forgot Gulp which was all the rage at some point, before Webpack.
I'm still facing an issue with the React env variable while deploying in Kubernetes.
No mention of Gulp or Grunt?
I don't think Theo's old enough...
I'm wondering if a 'non-bundling but still use a minifier' would work
How can I try rolldown with vite myself?
Rolldown is gonna be HUGE I can't wait for the Vite update :D
What about OXC?
SingleStore at $0.9/hour seems a bit spicy. That’s $600+ per month
Forgot Grunt
Vite is superb though. It's worlds better than all the other bundlers that have come before it.
You could say, vite is an "development environment".
JS dev is perpetual pain.
Man Frontend is so wild..
Esbuild is still going to be the only bundler I need. It does everything I need. I don't understand why you think it has some limitations. It is production ready.
< 10 likes? let me fix that
If it’s just roll down all the way down (excuse the pun), then why even ship it under Vite at all? Just ship the product as rolldown. I’m so confused 😅 what even is Vite now? Is it just a wrapper over rolldown?
And Turbopack still doesn't work for prod builds ...
There are too many flippin' tools out there.
We don't need more than Esbuild
Vite should use it fully
Next.js is getting left behind, it seriously needs to adopt Vite
Try vue or even nuxt, it's great
Either that or they need to ditch Turbopack and change to Rspack/Rsbuild.
It’s out there, it’s stable, it works and they can contribute to that codebase instead.
Turbopack lost, Vercel, it’s time to move on.
@@rampwuff I mean, even if rspack works, turbopack is meant to do a Parcel and reimagine some parts of the webpack API to be more pain-free, while maintaining a consistent bundler output with webpack so in the long run, turbopack would ultimately be the better option for something like next though I doubt it'll catch on for anything else
Problem is, Webpack is still the best for non-SPA's because of its configurability, I was able to shoehorn Vite but it still isn't 100% as good as Webpack, I had to make some plugins to get it to work.
that’s kind of the magic of vite though. need more functionality? just roll your own!
Welcome to software. Everything is a trade-off.
You all acting like we weren't building web apps using Ant back in the day :)
Rolldown for crabs 🦀
Winning !! 🦀🦀🦀
this is so cool
Is there a Patreon number where you would feel you didn't have to bother your viewers with the sponsor ads ? Or don't you see it as bothering your viewers ?
Maybe make svelte build faster? Can't complain about that.
Theo affiliates with nextjs, and that tool using swc. Rolldown use oxc which is 3x faster than swc. That main reason why he looking for problems as jealous hater) because soon all world will use rolldown with vite while their swc / nextjs / turbopack stack will be alone)
Can Rolldown save Vite? Hi, I am a developer who has been using stock terminal. Here are my thoughts.
I'd love to go through this video but, oh, that vocal fry... Theo, please! 🙏🏻
webpack is suuuuuuuuper slow on big projects, would never use it again in my life
why does vite already need saving lol
If Rich Harris is behind Rollup, you just KNOW it's going to be fantastic.
Roll down i mean
Save vite?????
Clickbait used to be at least a LITTLE BIT believable.
Fix? Save? those are words you use for a dying/struggling technology not for an improvement...
you forgot to mention why Evan was doing it I think, but I didn't watch all the video, he said on the last conference is he needs rolldown to eliminate differences between production builds and dev builds
Good
good point though he mentioned it in the video
Rust isn't the catch-all solution to everything
This is a dumb trend
The contributions will decline because it's such a high barrier of entry, and it saves what? .5s for a regular build?
Didnt even look at the benchmarks lmao. Cry more pls 😂
Switched from webpack to esbuild in our production code, build time went down from 2 minutes to 4 seconds.
save from what? the clickbait and drama every. single. video. ffs. so obnoxious.
it’s a shame because i got a lot of valuable info from you, but it’s not worth it
Benchmarks are false, roll down is in beta, just take down the video
Click baiting 😂😢 vite doesn't need to be saved😅
you must good useful sponsored things
clickbait title
Boopgloop is here, can it save Shloopwoop? Web devs are a disgrace
Theo releasing videos hyping another dead-on-arrival javascript tool will never not be funny
Of the "new JS tools" I've covered recently, Rolldown objectively has the highest chance of success simply by being tied to Vite
Dude this is pretty much the worst thing for making that comment. Rolldown will be a total game changer
Vue/vite/rolldown will be the next big thing imo, it already is amazing
@@DerLuukee It already is. Next is the only thing that's going in the opposite direction. Everyone else is behind Vite.
I'm not even on the Vite train, and I know, this is long anticipated with a proper business backing. Many people left their jobs to work on this full time. Its not going anywhere