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!
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
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
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
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
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).
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..
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!
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)
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.
6 месяцев назад+2
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).
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.
@@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.
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.
@@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.
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...
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)
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.
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!!!
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.
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.
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.
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
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.
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.
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...
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 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...
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
Tokio is necessary because that's the design of the language. It's purposeful so you aren't stuck with a bad runtime, Rust doesn't include a runtime for this exact purpose. I'm surprised by how bad your takes can be sometimes. You're literally saying a feature of the language makes the language itself bad.
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.
hands down nothing, and I mean NOTHING, beats rust LSP. Outside of compilation speed, I seriously haven't seen anything better than rust. This is imo sad, and I hope it changes. Just clone the largest rust project you can find and see how rust-analyzer will just work no configurations needed whatsoever.
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.
@@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.
the rust slogan
"Making Javascript better one step at a time".
The web slogan:
"Making javascript better one runtime at a time"
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!
This is very encouraging, I've been stuck migrating a large legacy app to vite for weeks! Hopefully the journey with rsbuild be smoother
What parts were imperfect just curious?
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
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
Zack is a legend! Hopped on an hour long call last week helping me figure out the code-splitting story for TanStack Router.
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.
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
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
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)
teh vite build comparison wasn't quite fair, since it was also doing type checking..
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.
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).
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??
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.
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
Rust mentioned let's go!!!!!
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
JS has no compilers so it's never will be faster than Rust compiler. JS only has transpilers and bundlers.
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 ?
multithreading in Rust is fine. Async is ok, could be better.
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)
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.
5:56 build Docker/OCI containers and just deploy the old container from your registry.
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.
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.
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.
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.
we just moved to rsbuild and we are very very happy developers now 😁😁❤❤
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
Please talk about Module Federation, v2.0 was release not too long ago.
I have worked with Zack a while back. He is the guy that wrote module federation in webpack and got it working in Next
rsbuild is what you want, its a better DX built on top of rspack
What do you mean webpack doesn't do HMR? That's like the OG HMR implementation? :)
First time watching a Theo video?
Let's go 300k subs 📈
Zack is cool. He kick started micro front end via Module Federation in webpack.
are you only making the rspack video now that farm's out of beta?
What about makojs?!
know this guys, he is awesome
Started using rspack when it was just 0.2, it only difficult only when I had to migrate to version 0.4, but everything else is super fast and amazing
why no peace Nerds Today
what is that tmux up time man 😅
I'll read that (docs whatever) myself.
i moved to vite long ago. not moving again. 2024 is the year of build tools it seems.
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
farm has completed the incremental build feature. You can try it. It is faster.
Hey theo, what's that "time" command that you are prefixing with? I wanna know it too.😮
Rspack is sure awesome.
as long as we get one new build tool per week javascript is not dead!
Official TS Server in Rust, when?
Theo seems to conflate async and multithreading frequently
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
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.
When is Cypress's turn to be rewritten in Rust?
what about next js?
Why do you use new born tools in production?
Lmao, Rust is here to fix the web's biggest mistakes. I love it, i want Rust in the Frontend, Backend, everything.
Any research thesis topic idea for web development and cloud?
I thought Vite was a webpack alternative...
The state of js. Another day another tool.
Theo, I've been dying for you to talk about Module Fed.
PLEASE DO.
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.
idk what any of this web stuff is, i just love rust
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...
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.
Given enough time; all code rusts.
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.
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 does theo's terminal looks like a racecar? me want
Thanks! Another great reminder to stay away from the giant complex spaghetti cauldron that is Javascript.
Bytedance has been releasing some good OSS nowadays, loving this direction
"The channel axioms in go are shit" ... uhhh what?
The tsunami of Rust
Have you heard about Vite?
Never. What's Vite?
What happened to Vite!?
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...
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.
Thoughts about backend ?
why doesn't he use BUN? Did I miss something?
9:03 try C# and you'll know how easy should be!
And everyone was wondering why did the State of JS survey came out the way it did...
Tokio is necessary because that's the design of the language. It's purposeful so you aren't stuck with a bad runtime, Rust doesn't include a runtime for this exact purpose. I'm surprised by how bad your takes can be sometimes. You're literally saying a feature of the language makes the language itself bad.
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.
I thought turbo was written in rust?
16:35 deno :(
Oh, this is a Bytedance product? Im out. I'll stick to my other bundler options
Ya, better to stick on Meta stuff😅
I've never understood why JS has invaded development tools instead of being confined to its area of use: browsers.
Turbopack works. 100% works in dev mode with Next 15 rc
Why are you fudding Vercel your sponsor, Theo?
7:56 i know what u are
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.
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.
I think you want to look at FARM
Rust. Blazingly fast.
hands down nothing, and I mean NOTHING, beats rust LSP. Outside of compilation speed, I seriously haven't seen anything better than rust. This is imo sad, and I hope it changes. Just clone the largest rust project you can find and see how rust-analyzer will just work no configurations needed whatsoever.
pnpm mentioned
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.
I mean my PHP/html/css/js takes 0 seconds to compile/package ...
rust mentioned
Rspack with tailwind and autoprefixer is not that good yet.
when you have 300MB of JS it's not a bundler problem though
Unavoidable. Look at slack or Google docs or figma. Big systems come with a lot of source
Uhm, you’re still dressed wrong for the occasion, it is black hoodie dress code
Rsbuild, copyright byte dance