The First Real Webpack Alternative (Written in Rust!)
ฝัง
- เผยแพร่เมื่อ 30 มิ.ย. 2024
- Rspack is way way better than I expected. Are the bundler wars coming to an end? I'm hyped to play with it more. Sorry Turbopack!
SOURCES
www.rspack.dev/
www.rspack.dev/blog/announcin...
x.com/ScriptedAlchemy
github.com/farm-fe/performanc...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏 - วิทยาศาสตร์และเทคโนโลยี
the rust slogan
"Making Javascript better one step at a time".
The web slogan:
"Making javascript better one runtime at a time"
Regarding the “rust multi-threading” is bad comment, I would like to address the confusion between async and multi-threading. These are not the same, and you can have async without multi-threading or visa versa. I do agree, async could be better, and there are several efforts to try and improve this for end users in the works. However, the multi-threading support in Rust is extremely good in my experience, and certainly better than JS/TS. Crates like Rayon will take you surprisingly far, and often result in near identical code to the single-threaded version but with X times the performance.
for real, i don't understand why he's saying multiple time multi threading is hard in rust. Fearless concurrency. async yes, multithreading is really good imo
That's interesting. Thanks for sharing. I am new to rust and used only tokio so far for our backend server. This is something good to know.
He keeps making the same mistake again and again…
He definitely didn't know the difference between multi tread and async
I think his comparison of multithreading concepts in different languages is heavily influenced by his experience with elixir (and not js/ts), so i think to criticise him, you should compare it to the model of rust
Maybe in a few years Js devs will rewrite their backend in a actually performant language too.
A man can only dream... still, this is useful either way since we need to bundle our frontend code/assets anyway.
Yeah we should honestly all just write assembly code for everything right?
…….
The most performant solution does not always mean best solution
And i hope it wont be in javascript..
Why are people still coding in javascript.
oh i forgot mean the website makers xoesnt have any altetnative for frontend..
I don't know. Going from JavaScript to C++ is kind of going to be a little bit of Shell shock...
The thing isy they do nowadays. WASM Frontend frameworks are vastly available. @@_vk03
webpack, parcel, rollup, vite, babel, snowpack, turbopack, rspack…
8 tools to do the same job, that’s how you know we’re on JavaScript
Well, babel isn't a bundler, webpack uses it to transform stuff. Vite uses rollup to bundle.
But it's not bad that people want to make tools better.
There is too much stuff. Fortunately, I didn't study front-end.
Rolldown for vite soon too
As if backend doesn't have several different options "for the same thing"? As long as standards are kept, constant improvement of multiple options is better for all of us. So much was made from wandering experimentation
Imagine complaining about innovation
We moved to Rspack in prod about 6 months ago, purely because we needed the performance improvement but didn't have time to migrate to another solution. The 1:1 mapping from webpack make things really easy. It's not all been perfect, but it's been such a big uptick in performance that it's been completely worth the migration. Glad to see it reach 1.0 now too!
re threading in rust; the entire point of rust is to be unopinionated about how threading and event loop works; its not in the standard library *intentionally* in order to enable alternate implementations optimised for eg for embedded systems
That already makes clear that threading probably isn't easy and should just be deferred.
I'm pretty sure the reason there is no async runtime is because there has been no consensus on what the API should look like. Libraries like tokio and async-std were created initially as proof of concepts, and eventually evolved into their own split ecosystems.
As for threading, there _is_ built-in API in the Rust standard library. But it doesn't support everything you may want out of cases threading outside of spawning, joining and passing data between threads (through a separate API, mpsc). This may be fine in some cases, but for larger scale where you also may also need to run async executions, you'd reach for something else that supports that, but it's often a buy-in (like Tokio).
That's async, std does have threading support.
What? Threads are in the std... I even made (yet another) thread loop implementation only using std.
@@autohmae It is not like in elixir and its friends you implement threading yourself, but you also defer it.
teh vite build comparison wasn't quite fair, since it was also doing type checking..
JS has no compilers so it's never will be faster than Rust compiler. JS only has transpilers and bundlers.
Zack is a legend! Hopped on an hour long call last week helping me figure out the code-splitting story for TanStack Router.
I think we aren't have bundlers fatigue. In frontend, people usually use Vite and Webpack for production. Why? Because they're trusted
Webpack (Old but gold)
Parcel (Not so popular. Author spends more time on LightningCSS)
Rollup (More often you can see Rollup as a part of something more complex, like Vite)
Snowpack (Not maintained anymore. Author made Astro)
ESBuild (More often you can see ESBuild as a part of something more complex, like Vite)
Vite (That's the way)
SWC (More often you can see SWC as a part of something more complex, like plugins for Vite or Webpack)
Turbopack (Still waiting for production)
Rolldown (Not ready. WIP)
RSPack (Public alpha)
Bun (Bun no longer has a dev server and its bundler is largely an ESBuild Zig port)
Farm (As Vite but in Rust. Not so popular)
I don't think rust's multithreading is hard at all... compared to like c/c++. You also don't HAVE to use async or tokio for multithreading, unless you do so much io workload that it makes sense.
Agreed. Making all resources have a single owner is a good design in C++ too.
@@krumbergifyRust’s model has been the best practices of C++ for eons now, I don’t get how people are pretending like Rust isn’t easier than Java or even C# it’s not even close.
@@anonymousalexander6005 Good luck trying to make a project with many bidirectional dependencies. Rust is the worst language for that
@@lx2222x What do you mean "bidirectional dependencies"? Rust is like the only language that exists that even fully allows import cycles.
@@lx2222x??
We've switched to Rspack in production for one legacy custom create react app config (with custom aliases, styled components, sass) in my squad. The gains compared to CRA were insane, build times dropped by at least 60%. All of that with a very easy migration (done in a single PR with around 200 lines changed). We've tried to migrate to Vite in the past, but that came with a huge pain due to the needed webpack interop. Rspack is a great alternative to projects where a migration to Vite is hard and Webpack compatibility is needed (e.g.: for module federation usage).
multithreading in Rust is fine. Async is ok, could be better.
The reason why I love Rspack/Rsbuild is its practicality - a mostly easy migration story from Webpack, while offering good performance. I really don't give a crap about other more performant solutions when every company I've worked in has miserably complex Webpack config!
absolute perfect
As a Rust dev (and a begrudging FE dev) this is so exciting. I love oxidizing my stack as much as possible.
You're a front end rust dev? I've heard there's at least 10 of you out there in the wild.
@@gebys4559 probably no, currently it's not worth using rust for frontend.
@@gebys4559 Most rust devs are just frontend devs who think they are real engineers. It's makes me cringe when you see the code they write and how much they typemasturbate with rust.
@@dyto2287 i see the opposite, the worst offenders for type masturbation are actually js devs with no low level background
Don't let tech tubers convince you front-end sucks! Its just as capable as the back, its just people code larger scale stuff in the back
13:40 "it was an attempt..." sounds like Biome isn't being worked on anymore. Biome is active and is the replacement for ESLint and Prettier. It won't be a replacement at the moment if you have lot of custom ESLint rules or rely on some specific typescript-eslint rules for example, but for many projects it is a suitable replacement today and is an awesome tool.
I would highly recommend checking it out for anyone looking for a way faster ESLint and Prettier alternative.
It lacks so many things coming from Eslint and prettier that it's not replacing anything currently, at least for me
If anything I just use if for import sorting at the very least, since if seems to be pretty fast at that (albeit with some weird bugs)
@@zayne-sarutobi what exactly are the things you are lacking from Prettier for example? My experience replacing Prettier with Biome has been awesome and I don't even have to use a plugin for import sorting anymore since Biome has that built in.
But as I've said, it's not a replacement for all projects.
rsbuild is what you want, its a better DX built on top of rspack
Rust is the only major programming language that won't compile code with data races in it. Rust's threading model is great.
This. Async await has a bunch of paper cuts, but plain threaded Rust is amazing.
Also, if you are using tokio, imho the most important pattern to use is to confine async to the parts that do IO only, and then use channels to batch stuff together. Since tokio channels have both a synchronous and an async API the rest of the application can just be a pool of threads running synchronous code that pulls work from the channels.
threading isn't concurrency
Rust has excellent first class threading (albeit limited by the OS threading libs).
Async is the real issue since the semantics are just terrible. The core team doesn't want to push for one established run time so we get a shitshow until they do.
Rust mentioned let's go!!!!!
we just moved to rsbuild and we are very very happy developers now 😁😁❤❤
Jesus, we are only just in the process of migrating to esbuild from WebPack. Are you telling me we are alread betting on the wrong horse AGAIN?
Welcome to the world of Javascript where you can never truly master any tool/library/framework/etc. because things constantly shift and move
Yes
You should be migrating to Vite lol
I'm a big fan of Webpack, but the build process can be quite slow at times. Webpack 5 has improved this a bit, but external plugins and tools can still slow it down. As much as I like Webpack, I absolutely loath configuring it. For that task, I have switched to using the symfony/webpack-encore library provided by the Symfony PHP project. By default it is configured to split scripts based on entrypoints and generate a manifest file that maps assets generated to each individual entrypoint. The manifest file requires special handling on the server side to include the necessary assets for the given entrypoint/page. This of course isn't needed for single page apps as everything is either bundled together or you use Webpack's built-in script loader. Plugins are available for various server-side frameworks that simplify injecting the necessary assets into a page.
aside from node_modules bloat for binaries, it's also potentially insecure. Especially on something like npm that doesn't verify the package in the registry was built from the listed source code...
So, we need to use cargo to build them🔥
We are enabling package provenance on npm which is designed to safeguard this type of thing
@@zackjackson9674 Yeah, @rspack/core has enabled npm provenance and other packages soon
Also means you get architecture specific builds, maybe this is where WASM fits in ?
Let's go 300k subs 📈
Been using RSpack for a month now since 0.7, onboarded quite easy and includes some sane defaults (that you can opt out) for some common builds like react. Pretty much what Vite does.
i mean at this point even my mom is getting a rewrite in Rust by some random dude on github
I'd rebase that
push request? anyone?
@@ark_knight forkakke
She'll be able to give hugs and bake choc-chip cookies 25x as fast.
@@tuna5618 jet set radio future - birthday cake
If you want nice multi-threading: OCaml is shipping an effect runtime in version 5, with plans to introduces typed algebraic effects; which basically give you the power to build async await etc in user space (but also in a way that avoids the colored function problem because you can be generic over the color of the functions you take)
What about makojs?!
Whats hilarious about Farm is that they claim to be compatible with Vite... except for the fact that it has an entirely different configuration schema, and missing a ton of actual useful options-have two different properties to define plugins, one for Farm-specific ones and another for Vite-which doesn't work well, either. Most of what makes Vite great is not just the dev environment, but also the use of Rollup for production builds. It's easier to configure than webpack, and often provides as good if not better results with less configurations and plugins. It just works.
I can see Rspack and Rolldown as actual useful solutions to bundling, if they come to fruition. SWC is a good ESBuild alternative, but honestly I don't see that major benefits other than being a API that provides APIs for dealing with JavaScript source code in Rust. For that you could also just use Biome's crates.
The biggest downside of rust is that it keeps making javascript faster which means javascript devs have less reason to switch away from javascript and to rust. Javascript can't keep getting away with this!!!
Rust becomes the hidden hero one day, making Js shine even more 🤣
You will never see JS die in our lifetime.
I have worked with Zack a while back. He is the guy that wrote module federation in webpack and got it working in Next
know this guys, he is awesome
Zack is cool. He kick started micro front end via Module Federation in webpack.
What do you mean webpack doesn't do HMR? That's like the OG HMR implementation? :)
First time watching a Theo video?
are you only making the rspack video now that farm's out of beta?
i moved to vite long ago. not moving again. 2024 is the year of build tools it seems.
dude this is insane
I am working on a internship at a company
Just for testing i changed the build tool from vite to rsbuild the difference
vite build time :- real 1m24.612s
rsbuild build time :- real 0m12.510s
Laptop specs: Ryzen 3 - 4 cores 25W processor, 16 GB RAM
To mind you this is a huge code base like very very huge.
I thought Vite was a webpack alternative...
why no peace Nerds Today
I did bundle split in webpack but was way cooler, faster to do it with gulp. I miss gulp and don’t miss it at the same time
Rust. Blazingly fast.
"The channel axioms in go are shit" ... uhhh what?
as long as we get one new build tool per week javascript is not dead!
Please talk about Module Federation, v2.0 was release not too long ago.
idk what any of this web stuff is, i just love rust
The state of js. Another day another tool.
5:56 build Docker/OCI containers and just deploy the old container from your registry.
This, if you don't have version tags on your containers what the actual fuck are you doing.
Theo seems to conflate async and multithreading frequently
farm has completed the incremental build feature. You can try it. It is faster.
Given enough time; all code rusts.
Personally, I never found threads to be all that difficult and most of the time I was using pthreads for my threading purposes. Now that C11 added threads to the standard library and the implementation I'm using, gcc on Linux, basically just thinly wraps pthreads anyway and I have to add -lpthreads to the linker options if I use them. So I'm not sure why so many people complain about threading. However, I do wish that we could replace the entirety of the web infrastructure. Just completely wipe out HTML/CSS/JS and start from scratch. It'd be nice if bundlers weren't a thing and instead a webpage could just be simpler than they are now but provide similar functionality. Something akin to a web browser scripting a UI library instead of attempting to implement an entire OS inside of the already running OS.
Hey theo, what's that "time" command that you are prefixing with? I wanna know it too.😮
Rspack is sure awesome.
Official TS Server in Rust, when?
Lmao, Rust is here to fix the web's biggest mistakes. I love it, i want Rust in the Frontend, Backend, everything.
what is that tmux up time man 😅
nixpack by railway is also there
Rust is a bit weird looking, but it's only slower to Fortran, it's got WASM, it's not owned by anyone and is backed by AWS, MS and a few others.
Thoughts about backend ?
When is Cypress's turn to be rewritten in Rust?
i did those perf compare, and idk what is going on but turbopack was WAY slower
Turbo startup time fluctuates we have found. Haven’t kept tabs on hmr times in recent history tho.
rust mentioned
why does theo's terminal looks like a racecar? me want
Why do you use new born tools in production?
16:35 deno :(
7:56 i know what u are
pnpm mentioned
Here’s a question: how many years will it be before tech companies have policies that restrict any open source code that has *any* supply chain dependencies on any code or services written by bytedance (or any other company that would be under the influence of Chinas spy services)
Btw im not making a judgement about whether we should do that, but that would be the natural and logical extension to the latest US policy. Look at the polyfill exploit if you’re thinking this whole idea is crazy.
If political tensions impact user trust for rspack we will donate it to openjs foundation and just help maintain it. Release ownership to a neutral party. Was one of the first plans I discussed when I joined.
@@zackjackson9674 Hey thanks for the quick and open response. I wasn’t expecting that. (For other readers, his YT username appears to align with a GitHub account that is one of the main contributors to rspack. So that’s cool.)
I really hope that we don’t devolve into such a trustless world. But it might end up being the reality. The NSA has been embedding exploits in tech for decades; also influencing US companies to grab data. Why would China do any differently? Let’s say my company has sensitive and regulated data security regulations. How would I be able to defend the decision to my superiors to use a tool that could be under the influence of a foreign adversary? I would need to be able to say that there was at least one person who is not a spy who is reviewing every piece of code that gets included.
9:03 try C# and you'll know how easy should be!
Bytedance has been releasing some good OSS nowadays, loving this direction
I have stuck around with Vite, and since my first framework was actually Svelte, I just sticked with Rollup and so far it's been good enough. I don't see the reason to learn all of these bundler APIs and ecosystems just to bot use them and forget everything in a year...
Oh, this is a Bytedance product? Im out. I'll stick to my other bundler options
Ya, better to stick on Meta stuff😅
@@brenoepic6946vite is not by meta, and plenty fast for most use cases.
I think you want to look at FARM
What happened to Vite!?
I'm a bit salty about Rust only supporting monolithic binaries. But I'm still glad they didn't use C++...
There are some ways to create DLL for rust but it’s not very straightforward. I do want to look at this in future tho.
And everyone was wondering why did the State of JS survey came out the way it did...
Have you heard about Vite?
Never. What's Vite?
I thought turbo was written in rust?
No way. Haven't they abandoned it and started Rolldown which is a re-write of Rollup?
No. Rolldown was started at ByteDance. The devs paused working on it and changed to the rspack team. Then Evan hired some of the original rolldown engineers from our team and the revived the project to position it as the future for vite.
Rolldown, farm, rspack all trace their origins back to our infra team. Rspack served the business needs best, that’s what we ended up using and investing resources into.
Do you really need this unless you’re Nexting? Personally, I like smaller bundlers that are less weird.
There’s few good picks for enterprise users with complex business needs. Smaller api is good for adoption but struggles to scale for the business
why doesn't he use BUN? Did I miss something?
Thanks! Another great reminder to stay away from the giant complex spaghetti cauldron that is Javascript.
The main problem with rust async is that it needs to integrate with many different runtimes. Which gives you access to really cool/cursed stuff like interrupt based async runtimes for embedded systems. This comes with the issue that Rust can't assume anything about the way an async function will be run (and also the type system was not powerful enough to represent async functions in interfaces (traits)), thus, you are missing a lot of common functionality in the standard library (AsyncIO interfaces, AsyncIterator, etc). Languages like Go and Beam-based languages, have an async executor built in, this allows them to make more assumptions about how an async function may be run, and provide better tools as a consequence.
Additionally, an early decision was to make all types memcpyable, this seemed like a good idea (why would a type ever not be memcpyable?), but it turns out that async heavily uses self referential types (which are not memcpyable), and thus we get Pin (go read Pin and suffering from fasterthanlime on why this is an issue).
A lot of people are working on improving this and I'm hopeful the state of things will improve, but it looks to be a 2-5 year endeavor...
Rsbuild, copyright byte dance
Isn't bun enough? Still not clear why re-write it in Rust? This suggests a major flaw in Javascript and admission of defeat.
Can’t back a business on bun as of yet. Too early for big tech company to consider. Bunbundler is also based off esbuild afik, not enough flexibility in the build architecture. Don’t think bun is enterprise ready right now
@@zackjackson9674 Thank you for the clarification.
I just deploy my app with aws s3 cp xD
Uhm, you’re still dressed wrong for the occasion, it is black hoodie dress code
how come you got that tshirt?!?
how much did rspack paid you to do this video Theoo!!?!?!?!
just kidding ofc great vid
Why not create an JS Engine in C/C++ or Zig that support all the features of BunJS, DenoJS, NodeJS and name it as "One for all" (Inspired from "My Hero academia")
We already have our own custom runtime. The idea is composition at scale for shared service platforms. For example we have react native solutions and static doc site solutions. Many different business products. Layered infra and rspack is one of 50 in house modules of infra tools.
@@zackjackson9674 I made this comment as a joke. TBH, it's frustrating to me every day in the JavaScript world that there is something new coming. If it's done for like 6 months or 1 year, I think there are lots of developers who would learn from the new things that came. New tools are good, but when there are overwhelming tools, it is too hard to follow up. You need to be a good developer before you start in the JavaScript world.
Any research thesis topic idea for web development and cloud?
I like rust based tooling. Rust is not nice for web stuff though
Am I the only one pronouncing "Rspack" as "Respect"?
You keep complaining about threading in Rust but I don't think you know what you're talking about. Although *async* has some issues (arguably not that bad), *threading* can be used without async in Rust and is often super easy to get right.
I'm just doubting that everything will be replaced by Rust at this point. Softwares, terminals, tools, languages, websites, IDEs, embedded systems, kernels, operating systems and more are fully being rewrite in Rust. Well that's just me tbf.
One can hope 😂
Just wait for the Oxidization, it will come, and it will embrace the whole world.
Hot take: Rust is as great of a language as it is overhyped.
@@plaintext7288 hell yeah people overhyping rust often forgot that rust has more than just safety and performance to offer
@@plaintext7288 its a new language and I think people are just trying to do everything with it. We don't know whether it will have adverse effects in future like the memory vulnerabilities that are now found in almost every C written stuff, after being used for years. Nothing wrong with trying something new.
14:23 that's an aside... but also a problem ? Also question: are we shipping lots of Rust that needs to be compiled per architecture or are we also getting WASM ?
Compiled per architecture because that’s faster than wasm. But rspack can compile to wasm too. I’m busy setting up a cloudflare worker that will let rspack bundle modules on demand
I prefer Farm.
Also started at ByteDance 😂
I've never understood why JS has invaded development tools instead of being confined to its area of use: browsers.
They just frontloaded the compile time into the Rust code base 😏
vite one love
Very curious how this works in the Angular ecosystem