Hacker News Reader

Comment by the__alchemist | Hacker News Reader

Seed creator here. For some context, I now code all my websites in HTML, CSS, and targeted JS (ie no frameworks or dependencies). Writing this was a great way to learn the ins and outs of DOM manipulation!

Overall, I'm happy with the way the Seed API turned out, but could never get the performance or package size to a good place.

That said, I love coding in Rust, and use it all the time for embedded!

View on HN

I'll just say I really enjoy the "Why not Seed?" section of your readme. The honesty is refreshing and it really let me know the plusses/minuses of this.

I agree. The modern hip thing to do that many consider as “having character” is to wax hyperbolically about one’s most likely pretty janky code. I see this a lot with neovim packages and it’s rather annoying, though I can appreciate the enthusiasm.

That's an interesting perspective! As someone considering seed, do you consider it a useful thing to pursue Rust as a frontend language in its current form and given the state of the ecosystem? Obviously you decided to go pretty deep exploring this topic and eventually went a different route but I'd be grateful if you could share some insight here.

At work we built a customer dashboard using Yew (another Rust frontend framework) and absolutely love it. We share API models as a crate between frontend and backend (also Rust) and the same developers work on both. Definitely would never look back, unless larger browser support was a concern. (In our B2B SaaS it hasn't been an issue at all.)

Subjectively, no. Rust is a pleasure to work with for business logic, and some things like dates and times are much easier (via Chrono) than JS, but overall, modern JS is the way to go for DOM manipulation.

For anything low level like embedded, I highly recommend Rust.

For backend/servers, the language is fine, but it has no mature frameworks like Rails or Django. More like Flask analogues.

WASM in general is not suitable for DOM manipulation because it can't manipulate the DOM without calling into JS, which comes with a performance penalty. Hopefully that will change with future versions of WASM.

Not GP but as someone who loves Rust and spent a lot of time trying to use it as a FE language, I settled on F# for my own frontend projects. It has many of the nice things Rust has (discriminated unions, pattern matching, ML inspired syntax) but is much more aimed at typical business logic apps.

With Fable compiler in the frontend and .NET core on backend, you can write the same language on both and even share interfaces, types etc. and it’s just a pleasure to use. If you haven’t tried the .NET ecosystem in the past few years, it’s come a looong way from the old windows only days.

> I [..] could never get the performance or package size to a good place.

Do you have any more details on that? I'm curious how close this got, and what were the main issues (on both size and speed).

I don't have specific info, but generally:

- VDOMs in general have poor performance; they perform unnecessary computations in the diffing algorithm, and even well-designed ones perform extra DOM manipulations, compared to deliberately-written code.

- The Rust WASM files would come out pretty large; a few hundred KB for a minimal app. This is better than some packages using React + common JS dependencies like Lodash and Moment, but with much room for improvement

- DOM manipulation calls made in Rust via WASM(currently!) don't have any performance benefit over the native JS API

It sounds like you made a Rust version of React. I think a Rust version of Svelte makes more sense in the long run.

Sycamore looks interesting, though it needs some more ergonomic improvements before it becomes more widely usable.

https://github.com/sycamore-rs/sycamore

Hi, author of Sycamore here. What kind of ergonomic improvements are you thinking about? If this is something actionable, it would be great if you could open a new issue on our repo.

At one point I prototyped a wasm framework inspired by Solid[1]. The results were very promising—an implementation of js-framework-benchmark was 41KB (18KB gzipped), and perforrmance was close to vanillajs. The developer ergonomics were definitely lacking, though.

Benchmark results (look for "cope")[2][3]

I definitely think whatever happens over the next few years, VDOMs are on their way out.

[1]: https://github.com/whatisaphone/cope/blob/master/crates/js-f...

[2]: https://cdn.discordapp.com/attachments/751355413701591120/77...

[3]: https://cdn.discordapp.com/attachments/751355413701591120/77...

Do it

this may interest you: https://github.com/Pauan/rust-dominator

Accurate, and I agree.

Thanks!

So your framework works on DOM? I thought that WASM - DOM interop is not so great and generally WASM apps would work by doing their own rendering on canvas, skipping DOM.

Reply on news.ycombinator.com