5 ms·

No more babel in my compilation pipeline, yay!

by adzm 12d ago

adzm 12d 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 12d 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 12d ago
  Rust is such an awesome language. The execution times are blazing fast.
  - echelon 11d 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 11d 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.
      - echelon 11d 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.
      - umpalumpaaa 11d 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.
  - pjmlp 10d ago
    Quite surprising for an ahead of time compiled language. /s
koito17 12d 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 11d 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.

No more babel in my compilation pipeline, yay!

by adzm 12d ago

No more babel in my compilation pipeline, yay!

adzm 12d 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 12d 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 12d ago
Rust is such an awesome language. The execution times are blazing fast.
- echelon 11d 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 11d 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.
    - echelon 11d 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.
    - umpalumpaaa 11d 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.
- pjmlp 10d ago
  Quite surprising for an ahead of time compiled language. /s

koito17 12d 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 11d 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.