[ecmascript]

Can't people figure out some other tooling besides bundlers? I mean, how many do we really need?

It's probably fine, but so are all the others as well. The authors have probably spent a fair amount on time on this project so I don't want to be negative but it's just hard to be excited when it brings nothing new to the table.

Why should I use this over Vite or esbuild? Because it's written in Rust? I don't understand why that even matters. Even if it was 10 times faster I wouldn't use it because Vite is fast enough and have all the plugins I would ever need.

[norman784]

Why matters that is written in Rust? Because there are already a few JS tools written in Rust, so you can now use the crates from projects like Deno[0], OXC[1], BiomeJS[2], etc to write your own tool with minimal effort.

Also note that the Vite team is writing Rolldown[3], and guest what? They are writing it in Rust.

[0] https://crates.io/search?q=deno [1] https://crates.io/search?q=oxc [2] https://crates.io/search?q=biome [3] https://rolldown.rs

[rty32]

None of those tools you quoted are production ready based on my investigation, in the sense that if you manage the JS infrastructure of a company of 2000 developers, you would stick with webpack. Lots of Rust based tooling is still half baked and missing things here and there, so much that you wish these people work together to create one (or at most two) tool that is comparable to webpack.

[dsff3f3f3f]

> None of those tools you quoted are production ready based on my investigation

This is very true and almost all of them are taking far longer to develop than they initially thought. swc/turbopack is being pushed by Vercel and it has been a huge ongoing disaster.

[ecmascript]

Yeah okay, but that's not the reason why people write it in the title. They write it in the title because they know that many engineers like Rust and think people will immedietly be drawn to it.

But the language itself is not a goal or at least shouldn't be IMO. Thus it have the opposite effect on me, who do not care about what language my bundler is written in.

If I did, it still wouldn't have any competitive advantage since as you point out Vite will soon also be based on Rust.

[podgorniy]

I've read some faq and docs.

Their reasons are to have fast builder with flexisbility needed for business cases. If other words they are making internal tooling publically available.

Being faster than es-build is not a goal, get people excited about speed is not a goal. Have control over tooling, flexibility, be fast-enough, be opensources are the goals.

[jack_riminton]

You'll get downvoted but I completely agree, it seems rewriting things in Rust and tinkering with bundlers is the new in-vogue thing to do. Lord knows why

[timrichard]

I didn't enjoy the Rust hype on here in years past, but I'm always glad of any better tooling. Just an example from the other week... I swapped out NVM for FNM (Rust) and now I don't have to put up with performance issues, especially slow shell startup times.

[ecmascript]

Just me being curious since I have used nvm for years without any issues. What do you mean by slow shell startup times? In what way do you use nvm in order to experience any slowness?

[timrichard]

I followed the standard nvm install process, to get it loaded from my .zshrc

I noticed a second or two in lag between launching the terminal and getting a shell prompt. Commenting out the nvm load as a test removed the delay. I installed fnm, aliased it to be nvm, and everything is snappy. Also nicer if you use tooling to 'nvm use' when changing into a project directory.

There are a few issue threads such as this one : https://github.com/nvm-sh/nvm/issues/2724

BTW, this blog post was great for finding the culprit if there is zsh startup latency : https://stevenvanbael.com/profiling-zsh-startup