Rendered at 20:16:27 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
pjmlp 10 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 1 days ago [-]
No more babel in my compilation pipeline, yay!
adzm 23 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.
Waterluvian 23 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 15 hours ago [-]
Rust is such an awesome language. The execution times are blazing fast.
echelon 10 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.
throw-the-towel 6 hours ago [-]
LLMs being good with Rust makes sense, because the language itself gives you more safeguards than many others. What's good for the (human) gander is good for the (agent) goose.
umpalumpaaa 50 minutes ago [-]
But once you start to close the loop (as in allowing the LLM to build and run its changes) what’s good turns suddenly bad again. Long build times also increase LLM turnaround times. Especially bad when you have a fast model.
echelon 5 hours ago [-]
LLMs are ungodly good at Rust, and I say this as a 10-year veteran of the language.
My problem is that now iteration with LLMs is so quick when prototyping new things that I now spend an inordinate amount of time waiting on agents to compile Rust and run tests. It's a huge slow down.
I still want to serialize production logic to Rust (and TypeScript for the frontend as the WASM for frontend ecosystem isn't there yet), but it's really slow to iterate. I'm starting to build prototypes in Golang now and then convert them to Rust when I'm done.
Hopefully the Rust team makes strides over the coming years to address this. I know they have a lot of irons in the fire for many speedups.
koito17 17 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 9 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.
dzonga 6 hours ago [-]
rewrite it in rust might be a joke -- but damn most the massive improvements in dynamic language toolchains have come from the toolchains being rewritten in rust - Python, JS
vmsp 22 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 20 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.
Hand written React code is relatively slow when running so the React team made a React compiler to make it run faster. You might not see the difference with a toy app, but with a fairly large app, with a lot of IO it's a catastrophe if not compiled and optimized.
It's the definition of overengineering IMHO. The problem is React at first place. Some other frameworks have in theory no compilation or optimization step while delivering constant performance as the app grows, like SolidJS. Since writing a compiler in JS also make compilation itself slow, then the React compiler was re-written in Rust...
At the end of the day, React has a larger community and ecosystem so it's the industry "standard" for JS applications...
pzmarzly 5 hours ago [-]
Why do people say SolidJS has no compilation? SolidJS 1.0 was already doing much more at transpilation time than just changing <h1> to h("h1"), and SolidJS 2.0 has a package called @solidjs/compiler: https://npmx.dev/package/@solidjs/compiler
4 hours ago [-]
syspec 1 days ago [-]
Does this work with reacts fancy new compiler that is meant to optimize away various hooks?
ownagefool 1 days 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 )
15 hours ago [-]
Onavo 23 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 21 hours ago [-]
Because next is the worsttttt
mexicocitinluez 22 hours ago [-]
Because it isn't supported by SWC yet.
Buoylog 19 hours ago [-]
[flagged]
prettycool 1 days ago [-]
[dead]
glouwbug 1 days ago [-]
[flagged]
VertanaNinjai 1 days 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”?
chmod775 1 days 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.
ablob 24 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 24 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.
MBCook 24 hours ago [-]
Maybe they’ll go back to “year of the Linux desktop”
steveklabnik 24 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 1 days ago [-]
I think once you have it in Rust the next ask is using no "unsafe" code from that crowd.
twistedpalm 16 hours ago [-]
As funny as it is, it was removed by this miserable community :/
dhbradshaw 1 days 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 22 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.
shikck200 14 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 14 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.
shakna 10 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.
7 hours ago [-]
_bent 7 hours ago [-]
not only does it have to load fast, it has to _stream_ the content from the server to the client
shikck200 13 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 12 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 9 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 9 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 14 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.
throw_m239339 6 hours ago [-]
But bad performances stems from non compiler optimized React to begin with, its execution model when handwritten. Other frameworks don't necessarily take more effort to use and have better performances from the get go.
satvikpendem 4 hours ago [-]
A lot of them do have compilers too, like a couple of the most commonly cited React alternatives, Svelte and Solid, so I'm not sure why React specifically is singled out.
yugoslavia4ever 13 hours ago [-]
There's lots of overengineered bollocks in webdev, but this is not one of those pieces.
throw_m239339 6 hours ago [-]
*React. Nobody is forced to use React to write web UI though. Actually, in theory, AI helps getting rid of all these web frameworks, they are tools for made developers, LLM don't need React to code a web UI, they can use Vanilla DOM or faster frameworks, like SolidJS.
slopinthebag 9 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.
My problem is that now iteration with LLMs is so quick when prototyping new things that I now spend an inordinate amount of time waiting on agents to compile Rust and run tests. It's a huge slow down.
I still want to serialize production logic to Rust (and TypeScript for the frontend as the WASM for frontend ecosystem isn't there yet), but it's really slow to iterate. I'm starting to build prototypes in Golang now and then convert them to Rust when I'm done.
Hopefully the Rust team makes strides over the coming years to address this. I know they have a lot of irons in the fire for many speedups.
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.
It's the definition of overengineering IMHO. The problem is React at first place. Some other frameworks have in theory no compilation or optimization step while delivering constant performance as the app grows, like SolidJS. Since writing a compiler in JS also make compilation itself slow, then the React compiler was re-written in Rust...
At the end of the day, React has a larger community and ecosystem so it's the industry "standard" for JS applications...
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?