Hacker News Reader

Why would you think rust will make the web sing? Their HTML documentation generator uses 571+ dependencies. So, hello more bloat! If the core rust team can't avoid it why would you think any other rust project would?

Why would an HTML generator need to slim down on dependencies? It's designed to run in CI, not respond in real time to user requests. It very infrequently runs and generates production artifacts with humans out of the loop.

This is a bad argument against Rust in the frontend.

Web frontend development is very nascent in Rust, but there's already cool stuff taking shape:

- https://www.egui.rs/

- https://leptos.dev/

You’re both right. It’s not as important that a documentation generator be blazing fast, but it’s a bad sign. If the core team finds themselves using 571 dependencies for something as simple as a documentation generator, how many thousands of dependencies will the average small business, trying to deliver value to customers quickly, end up using to create a line-of-business web app?

> This is fine for solving random business integration concerns, but for application software we have to use on a daily basis, it really sucks.

And more than it just sucking, it is unnecessary. We have mature, well documented, cost effective solutions for developing software that have been around from years to decades. We know how to develop software. The problem is people trying to develop software with web tools.

> Heavy software users spend hours within are where those hundreds of milliseconds per action really add up. We should be angry about anything worse than single digit milliseconds with these tools.

I think in the article writers mind here we are talking hundreds of milliseconds on first load and the majority of actions are instantaneous after that.

This can be achieved, but it takes some diligence and product mind focus to optimize what you can how you can and even big companies like Google don’t always prioritize this the way they should

> Rust becomes popular for specifically web application development. It'll need to overcome the awkward WASM/DOM bridge, but then it'll sing.

Colour me doubtful. As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM. And no one is going to transfer the DOM into WASM and break every JavaScript app out there.

> As long as the DOM is accessible in JavaScript, it can't be a first-class object in WASM.

I'm curious, why?

For the same reason that it's not now. It needs to be native on one side and bridged on the other.