Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.by Onavo
- Because it isn't supported by SWC yet.
- Because next is the worstttttby crypto137
- Webdev is the pinnacle of over engineering. And now with AI, it will get even worse. I think the web truly needs a reset.by shikck200
- 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?
by slopinthebag - There's lots of overengineered bollocks in webdev, but this is not one of those pieces.
- *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.
- 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.by satvikpendem
- 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.
by onion2k - Does this work with reacts fancy new compiler that is meant to optimize away various hooks?by syspec
- 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 )by ownagefool
- 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, JSby dzonga
- Now we rewrite the web in Rust WASM. /s
But seriously, Python and JavaScript have reflection/introspection features. Once the investment was made to transcribe the entire language into a compiled language, the speed gains were obviously going to happen.
by thephyber - They are only surprising for anyone that never used any ahead of time compiled language since FORTRAN was introduced.
The golden age of scripting languages being used for applications have setted us back a few decades.
by pjmlp - What's a react compiler? Not JS or TS?
- 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...
- 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.by vmsp
- 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.by nwienert
- No more babel in my compilation pipeline, yay!by adzm
- 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.
by koito17 - 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.by Waterluvian
- 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.by adzm
- 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.by pjmlp