Hacker News Reader

Comment by TikolaNesla | Hacker News Reader

I have mixed feelings about this project. It appears the author primarily aimed to rewrite Vite in Rust and then found justifications for doing so. From my experience, Vite is already sufficiently fast for most needs. Adopting a new and potentially unstable project for marginal performance improvements doesn't seem justifiable.

View on HN

Another way to view it: slow builds is a poor man’s feature, that punishes you for bringing in too many deps.

The JS ecosystem (speaking as an omnivore using many languages) suffers two big problems:

1. Tooling is too fragmented and complex and poorly designed. This includes even the standard tools and formats like npm and package.json.

2. There’s a weak culture of API stability. Leave a project for 3 months and there are new config files, plugin formats, etc.

It’s improving slowly through standardization with things like ES modules. But it’s still a Wild West.

That's my main gripe about JS ecosystem. Most of the times, I only need to compile a project (either live or as a static asset). You run "npm install" and the build tool (without any project dependencies) already come with 200 folders inside node_modules. And those byte-sized libraries! It always feels like an hackathon scene.

it is. just because you pushed a hack to prodb doesn't mean it stops being a hack.

but that's all that younger devs know. specially people from boot camps or the CS to startup pipeline.

I tried building a Rust project and it failed because it consumed my entire remaining 8 GB of disk space... Good old NPM.

I tried running a Python project and the necessary apt-get pulled 2 GB of dependencies and conflicted with some of software I use, that's before running the pip install... Good old NPM.

There are two issues: dep bloat and “hermeticity” if you will. Cargo is quite nice and projects build in a straight forward way. However, the Rust ecosystem sucks in terms of dep bloat, imo. And the compiler artifacts are large. Python not sure, but I thought you had a way to get hermetic environments?

Go stands out as being fast, small and very limited dep bloat, thanks to a comprehensive standard library. And very minimal config files. By that standard npm is a shit show.

Python is a mess with dependencies.

The small core approach is way too unwieldy and the cruft only seems to be piling on further. There are constant efforts to fragment the ecosystem (like for example currently Deno and Bun, exciting as those projects may be on their own merit), while there is seemingly no interest anywhere in creating a standard library to solve the issue of those frightening dependency trees.

Because apparently the right size of a package is one function. /s

I miss slow builds. Take a walk. Grab a coffee. See how your colleagues are getting on.

We could have locked down all the libraries, APIs, and tools to what they were in 1999, but then people would complain about that.

But really, you can just use skip it all and write your own code. People would scoff now, but that’s what we did. Well, maybe with prototype and/or jQuery.

Rollup is slow as hell. I’m working with a project where the builds take minutes on an M3 Pro.

I’d like to switch to something like esbuild but it uses a lot of features like aliases so would take some work to translate and the lib is being moved away from anyway. If I can drop something in that speeds it up I’m all for it

The vite authors are working on a roll up rewrite in rust to solve this. So instead of using farm, I'd just wait.

Is this rolldown or something else?

https://github.com/rolldown/rolldown

Why not try farm though if it means faster builds now?

I compile a few hundred thousand lines of c++ in “minutes”… it’s sad to see the state of the ecosystem be actually slower than languages that have a reputation for being slow.

Indeed.

Ok, but C++ is a compiled language. Even though compilation speed doesn’t need to be that slow, at least you’re getting something out of it.

JS is interpreted and JITed. The whole point of using it is having a very fast feedback loop.

The tradeoff should be: faster at dev, slower at runtime. There’s something fundamentally wrong if that premise is broken.

Actually it’s insane that we need build steps with any noticeable delay during dev time at all.

you can try use farm，If you are using a relatively simple rollup plugin, there should be no problem. The farm is compatible with rollup plugins.

If you find that your Vite build is too slow, you should reduce the size of your codebase.

I’ll get right on that. Let me call up my product manager and CEO and tell them to cancel our upcoming enterprise contracts. The codebase is too big, we can’t add any more features.

After that we can start laying off the devs and firing our biggest customers. The features they use are taking up too much code!

No, no, no, just implement microfrontends obviously, with 2-pizza-slice sized teams. This way you can improve all the KPIs that matter: builds become MUCH FASTER, and direct reports become MANY MORE. No manager can say no to this amazing architecture!

Reply on news.ycombinator.com