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.
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.
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.
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.
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.
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.
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 )
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.
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”?
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.
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.
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.
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:
reply