To be honest, if this was an article it would either be way too long or missing a lot of the commentary... I actually don't mind this format because I can just listen to it while doing other stuff or commuting, as if it were a podcast.

Below is a transcript of the first ~3-4 minutes (out of the 48min of the video).. I could have posted more but it hits the limit of comment length for lemmy... it also might have mistakes, since it was mainly machine generated.

So today we're going to talk about JavaScript and we're not just going to talk about JavaScript. We're going to talk about Rust powering JavaScript libraries and build tools, we're going to talk about the Why is in the house, we're going to talk about what tools are actually being built with rust to target JavaScript engineers, and then we're going to cover how that's actually being done and how you can do it.

But before we get started I want to be very clear about something. This is about Rust AND JavaScript. I'm not telling you to go rewrite everything you have in Rust, I'm telling you that in the right places there are people making the decision to write rust today to power tools that you already use, that you can make the same decision in some cases, and that rust works well to power JavaScript experience. So don't go rewrite everything, but also don't be scared of it of course.

The first thing we have to cover is why this is happening at all, and to do that we kind of have to talk about webpack. Webpack is pretty much the standard for build tooling these days. It's been a couple years, I'll say, of people trying to actively build projects to move away from webpack, there have been Alternatives like rollup that target slightly different use cases in the past, but weback itself, while it was great when it came out in, you know, 2014, it has gone through a number of major versions and it would seem if you pay attention to what's happening in the ecosystem that webpack is kind of at the end of its life cycle. It's still an okay tool but there are creeks and strains and people want better tooling. One of those people is the web pack maintainer so versell has this thing called turbo pack, and turbo pack they advertise very prominently as being a rust powered successor to webpack, that the creator of webpack is actually working on. It's framed as an incremental bundler optimized for JavaScript and typescript written in Rust, which is, you know, without the Rust part vaguely what webpack was. And why did they choose rust? well they claim to be very fast as a result, and this is a claim that's going to get repeated over a number of different projects. I don't want you to take the speed claims too seriously. The things that I want to show and mention are for example nextjs 13 with turbo pack is being compared to Vite with SWC, which is also a rust project, so we end up having the comparisons of: hey we're improving our speed using rust against other projects that are also using rust.

But versel isn't the only people trying to build a web pack replacement, bite dance has Rspack. Rspack is a fast rust based web bundler basically the same thing webpack was but written in Rust. So why does Rspack work with rust? well as you might have guessed they also claim blazing fast. I don't know about you but uh if I see blazing fast on another product page I basically just ignore it. It's an extremely overused term in the JavaScript ecosystem. Here the comparison is Rspack and then webpack again with Vite SWC, another rust project um with the standin default. So webpack and babel are kind of what's been the standard since 2014 2015, it's been a number of years and just like webpack had tools built on top of it, like Gatsby and nextjs and so on, Rspack is also getting tools built on top of it. So there's RS press now which is a static site generator built on top of Rspack, and here I want to point out that they explicitly call out that it's simple, efficient and easy to extend. So again even though this project is very largely Rust forward they are still claiming it's easy to extend.