Why does everything have to be a video? Write an article, wtf. I’m not watching a video with a clickbait title like this
Agreed, but the reason why is this is how you make money. Videos can be monetized more easily.
The problem with desperate monetization stunts like this video is that they rarely have any relevant content to show, and they are a formulaic output of mixing clickbait titles with 15min of inane fluff.
But that’s not true for all channels. I quite like this one, and when I like the content, I’m a little less harsh about the clickbait because I understand that it may be required to make meaningful money on YouTube.
You are right, but: Medium, Substack, Patreon, Kofi. Being a writer/blogger was a death sentence 10 years ago but the avenues for doing it are growing again.
Realistically, it’s a question of reach. Most people do not read articles, and the few that do are not reading very many very often. In contrast, there is a massive audience of YouTube consumers, even for this kind of nice interest. And unfortunately, the YouTube algorithm is better at promoting this content than posting articles on Lemmy and Hacker News will ever be. So, if you’re trying to share your insights with the latest crowd within your interest, YouTube is obviously the superior way to do that. Not to mention most JS developers live on YouTube, even when they’re working.
Also, I don’t think this title is clickbait at all. The thesis of the video is that the ecosystem of JS/Web Dev tooling is all being (or already has been) explosively re-written in rust.
I actually agree, I much prefer articles. However, I found this interesting since it looked at turbopack, parcel, rspack and others and talked about how it comes that the JavaScript ecosystem seems to start to use a lot of rust for their tooling. It was quite long though…
I like the format. Same thing when I see an article posted on medium. Those two save me so much time
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.