Rendered at 13:49:57 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pjmlp 4 hours ago [-]
Eventually we will be back to pre-node days, when compiled languages were the majority for JS tooling (C, C++, Java, C#,...), the yin yang of cool technology cycles.
adzm 19 hours ago [-]
No more babel in my compilation pipeline, yay!
Waterluvian 16 hours ago [-]
It’s just the best thing ever. Compiling at work took a minute for full builds with babel, and with rsbuild it now takes about 0.9 seconds.
fishfasell 9 hours ago [-]
Rust is such an awesome language. The execution times are blazing fast.
echelon 3 hours ago [-]
I just wish Rust itself compiled faster. Serde, proc macros, it's all so slow.
I'm going to start prototyping systems in Go, then porting them to Rust when they're more concrete.
I feel as though the Rust code LLMs emit is generally higher quality than most other languages, perhaps due to the error handling being a chief concern of the language, but the iteration on making changes and running tests is so slow.
Rust could grow into "the final language" if it wasn't so slow to compile. Assuming the WASM bridge also continues to improve.
adzm 17 hours ago [-]
Update: changed a pet project to use this instead of the babel approach. Literally just did the config changes in the article, no issues. Time from `npm run dev` to ready went from 6 to 2 seconds.
koito17 11 hours ago [-]
Finally got rid of Webpack in 2022, and now I'll be able to get rid of Babel, too.
It's a bit mesmerizing to think that Vite at the time was still "that newish tool the Vue folk use", and now it's pretty much the standard bundler for web frontend. Also the easiest one to configure and use (in my experience).
Similarly, I'm glad I don't have to deal with karma, jest, etc. anymore.
torginus 2 hours ago [-]
I really haven't invested heavily in understanding new tooling, but I did try to move to TS 7.0 and found that a lot of the tooling actually relies on parsing TS not just stripping the types. And the only tool that can do that reliably is `tsc`.
I even had to revert from TS 7.0 (the go rewrite) to 6, because 7 doesn't support plugins and code analysis stuff (which I guess are js) in the way the tooling requires.
vmsp 16 hours ago [-]
OXC Transformers are amazingly faster than Babel. I'm building a framework (https://github.com/vmsp/flypath) for web, iOS and Android native development that's fully backed by OXC and Vite. Instead of transforming styles using Babel like StyleX, I just use OXC. Instead of Metro (React Native's bundler), which also uses Babel, it's just Vite. It's still very early but it's plenty, plenty fast.
nwienert 13 hours ago [-]
Cool stuff. I'm moving One[stack.dev] onto pure rust now, and Tamagui v3 compiler will also is moving from Babel to Yuku which is quite interesting - from my testing it's more flexible and quite a bit faster than OXC.
Does this work with reacts fancy new compiler that is meant to optimize away various hooks?
ownagefool 19 hours ago [-]
If it wasn't obvious from the article, this is an implementation in the same thing in rust, ergo significantly faster. This was enabled, I presume, by the upstream react introducing code a rust version in source ( but they don't produce a standard binary last I checked )
9 hours ago [-]
Onavo 16 hours ago [-]
Why does the Nextjs version of React compiler require a babel plugin when the vite version doesn't need it? Next.js is on SWC, not sure why they need a babel plugin.
crypto137 15 hours ago [-]
Because next is the worsttttt
mexicocitinluez 15 hours ago [-]
Because it isn't supported by SWC yet.
Buoylog 12 hours ago [-]
[flagged]
prettycool 19 hours ago [-]
[dead]
glouwbug 19 hours ago [-]
[flagged]
VertanaNinjai 18 hours ago [-]
As funny as this is I sometimes wonder about that crowd. Assuming the ecosystem at large flips and most software is now written in Rust what will the “rewrite it in Rust” crowd move to? Will they be satisfied for the most part or does it morph into “now rewrite in $latest_rust”?
ablob 18 hours ago [-]
I think the crowd will split into those who just cared about it being rust and those who wanted some kind of leverage to tempt others into doing something.
The former crowd will cease being, while the latter looks for something new to push.
I believe that one does not need to be overly concerned here. As with most things you will never satisfy zealots so it is sufficient to reconsider every once in a while when the status quo changed enough to warrant the effort (i.e. the actual arguments change).
It is always a choice to participate in these "culture wars" or whatever you want to call this. If you can stick to a decision you can limit the impact quite a bit, I've come to realize.
anp 17 hours ago [-]
I've never been someone to tell others to rewrite in Rust but I am a huge fan of the language and have in fact rewritten a lot of things in Rust. I'd be happy for another programming language to excite me as much as Rust has for the last 10 years, and then maybe I'd join that evangelism club instead :). Not sure how PL evolution is going to go in an era of coding agents though, very curious how that'll play out.
chmod775 18 hours ago [-]
You will always have someone say "you should rewrite it in x", but it's rare that something carves out so much ground on the Pareto front you'll get a crowd.
MBCook 18 hours ago [-]
Maybe they’ll go back to “year of the Linux desktop”
steveklabnik 17 hours ago [-]
Because it became a meme virtually everyone who says this are actually joking and not serious.
They'll move on to whatever the next meme is.
wldcordeiro 18 hours ago [-]
I think once you have it in Rust the next ask is using no "unsafe" code from that crowd.
dhbradshaw 18 hours ago [-]
I'd argue for moonbit -- faster compile times, almost as fast, smaller wasm artifacts and like lean can have proof of correctness built in.
Svoka 16 hours ago [-]
what the point? Rewriting in Rust is not just a language change. Rust enforces designing systems in secure way to start with, not just memory safety.
For me last nail into becoming part of the crowd was Embassy. Whole my life I wrote some ad-hoc C microcontroller stuff. But just learning Embassy I realized that it could've been done much more elegantly and securely. If you have a spare moment, I would watch videos in this channel, old to new:
I've been using rust since 2017 and still code in it professionally and am a fan.
Moonbit is pretty cool too so I thought I'd mention it for other people who like cool things.
twistedpalm 10 hours ago [-]
As funny as it is, it was removed by this miserable community :/
shikck200 8 hours ago [-]
Webdev is the pinnacle of over engineering. And now with AI, it will get even worse. I think the web truly needs a reset.
onion2k 7 hours ago [-]
Webdev is the pinnacle of over engineering.
Imagine you wanted to make a native desktop app that runs on Windows (going back to Windows 95), and OSX, and Linux, and have it use the end users choice of native components, QT, or GTK. It also has to load fast, be accessible, and work on desktop, laptop, and phones. Also, you're only allowed to ship a single binary but you can load in assets based on the device when it runs.
The app could be anything from a single page that renders one image up to a complete 3D game. Users want 60FPS regardless of what it is.
I reckon you'd end up with a relatively complicated build pipeline.
That's what webdev is today.
_bent 41 minutes ago [-]
not only does it have to load fast, it has to _stream_ the content from the server to the client
shakna 3 hours ago [-]
I think you'd just end up with WxWidgets. Because it can do all of that.
Most of the jank of the modern platform doesn't come from JavaScript - it comes frame dependency hell, framework layered over framework, and over abstraction. It is a _cultural_ problem, rather than a technical one.
46 minutes ago [-]
shikck200 6 hours ago [-]
Thats not a true comparison, MAYBE that was sort of a thing back in the IE6 era. Today the web is capable of "a good enough" UX for most things. But how we do interactive apps on the web today is just madness. Most sites dont need anything close to React, and those who do could have just used something more simple without the madness what is the react ecosystem / bundlers / packages etc.
onion2k 5 hours ago [-]
The best non-web analogy I can think of is when someone builds a 2D platformer in Unreal Engine. The complexity of the tooling is necessary because someone else is making Witcher 4 in it. The fact the 2D platformer is using a vastly more complicated tool than necessary is on the dev, not the tool.
It's not React's fault that some devs don't know how to make a form in HTML. There is an argument that React doesn't spend much time telling people they might not need it, but that's not really their responsibility, plus there are some things (reactivity to other things on the page) that are common enough that seeing the boundary where you do or don't need it is actually quite hard.
slopinthebag 3 hours ago [-]
in defence of using ue5 for a 2d platformer, you still get a ton of features to help you build out the platformer, cross platform support, and you can reuse your knowledge across projects.
it's kind of the same for react. yes you could build one thing in vanilla js, another thing with htmx, and then a third in react. or just build all three in react and be done with it.
modern web dev is actually pretty simple now, there is still a stigma around webdev from the olden days but spinning up vite + react is trivial, doesn't pull a ton of dependencies, and makes it easy to build anything you want. yes you can still overcomplicate it massively but that's on the dev at that point.
mexicocitinluez 3 hours ago [-]
Its 2026. You thinking you know more about other people's requirements in an absolutely enormous field is just plain naive and its embarrassing reading this stuff on HN.
satvikpendem 8 hours ago [-]
Improving speed is now overengineering apparently, but the same people would complain about how horrible web dev is if it weren't improved. Damned if you do, damned if you don't.
yugoslavia4ever 7 hours ago [-]
There's lots of overengineered bollocks in webdev, but this is not one of those pieces.
slopinthebag 3 hours ago [-]
it's not really. you have javascript, you have a library like react which has a code transformer written in rust, you have vite which orchestrates the build process, and...?
if anything the migration of all these tools to rust makes things way less complicated. you have a binary for compiling your react code (totally optional btw, it's a performance optimisation), a cli for building your app (vite, built on a rust binary basically), and react itself which is virtually dependency free. where is the over engineering here?
I'm going to start prototyping systems in Go, then porting them to Rust when they're more concrete.
I feel as though the Rust code LLMs emit is generally higher quality than most other languages, perhaps due to the error handling being a chief concern of the language, but the iteration on making changes and running tests is so slow.
Rust could grow into "the final language" if it wasn't so slow to compile. Assuming the WASM bridge also continues to improve.
It's a bit mesmerizing to think that Vite at the time was still "that newish tool the Vue folk use", and now it's pretty much the standard bundler for web frontend. Also the easiest one to configure and use (in my experience).
Similarly, I'm glad I don't have to deal with karma, jest, etc. anymore.
I even had to revert from TS 7.0 (the go rewrite) to 6, because 7 doesn't support plugins and code analysis stuff (which I guess are js) in the way the tooling requires.
I believe that one does not need to be overly concerned here. As with most things you will never satisfy zealots so it is sufficient to reconsider every once in a while when the status quo changed enough to warrant the effort (i.e. the actual arguments change).
It is always a choice to participate in these "culture wars" or whatever you want to call this. If you can stick to a decision you can limit the impact quite a bit, I've come to realize.
They'll move on to whatever the next meme is.
For me last nail into becoming part of the crowd was Embassy. Whole my life I wrote some ad-hoc C microcontroller stuff. But just learning Embassy I realized that it could've been done much more elegantly and securely. If you have a spare moment, I would watch videos in this channel, old to new:
https://www.youtube.com/@therustybits/videos
Moonbit is pretty cool too so I thought I'd mention it for other people who like cool things.
Imagine you wanted to make a native desktop app that runs on Windows (going back to Windows 95), and OSX, and Linux, and have it use the end users choice of native components, QT, or GTK. It also has to load fast, be accessible, and work on desktop, laptop, and phones. Also, you're only allowed to ship a single binary but you can load in assets based on the device when it runs.
The app could be anything from a single page that renders one image up to a complete 3D game. Users want 60FPS regardless of what it is.
I reckon you'd end up with a relatively complicated build pipeline.
That's what webdev is today.
Most of the jank of the modern platform doesn't come from JavaScript - it comes frame dependency hell, framework layered over framework, and over abstraction. It is a _cultural_ problem, rather than a technical one.
It's not React's fault that some devs don't know how to make a form in HTML. There is an argument that React doesn't spend much time telling people they might not need it, but that's not really their responsibility, plus there are some things (reactivity to other things on the page) that are common enough that seeing the boundary where you do or don't need it is actually quite hard.
it's kind of the same for react. yes you could build one thing in vanilla js, another thing with htmx, and then a third in react. or just build all three in react and be done with it.
modern web dev is actually pretty simple now, there is still a stigma around webdev from the olden days but spinning up vite + react is trivial, doesn't pull a ton of dependencies, and makes it easy to build anything you want. yes you can still overcomplicate it massively but that's on the dev at that point.
if anything the migration of all these tools to rust makes things way less complicated. you have a binary for compiling your react code (totally optional btw, it's a performance optimisation), a cli for building your app (vite, built on a rust binary basically), and react itself which is virtually dependency free. where is the over engineering here?