6 ms·

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 t

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!

azakai 5y ago
> 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).
- the__alchemist 5y ago
  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
  - smt88 5y ago
    It sounds like you made a Rust version of React. I think a Rust version of Svelte makes more sense in the long run.
    - the__alchemist 5y ago
      Accurate, and I agree.
    - worik 5y ago
      Do it
    - khimaros 5y ago
      this may interest you: https://github.com/Pauan/rust-dominator https://github.com/Pauan/rust-dominator
    - johnsoft 5y ago
      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-framework-benchmark/ https://github.com/whatisaphone/cope/blob/master/crates/js-f... [2]: https://cdn.discordapp.com/attachments/751355413701591120/776076384430063616/unknown.png https://cdn.discordapp.com/attachments/751355413701591120/77... [3]: https://cdn.discordapp.com/attachments/751355413701591120/776065938818727936/unknown.png https://cdn.discordapp.com/attachments/751355413701591120/77...
    - bschwindHN 5y ago
      Sycamore looks interesting, though it needs some more ergonomic improvements before it becomes more widely usable. https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore
      - lukechu10 5y ago
        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.
  - azakai 5y ago
    Thanks!
Svenstaro 5y ago
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.
- the__alchemist 5y ago
  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.
  - TheCoelacanth 5y ago
    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.
- jhugo 5y ago
  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.)
- jordwest 5y ago
  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.
jjcm 5y ago
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.
- smohare 5y ago
  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.
- labawi 5y ago
  May I suggest changing: > WebAssembly is newer with less support. Browser compatibility is at 92.9%. To something a little less wasm-optimistic? Maybe something like: Requires WebAssembly. Inherently bloated, slow and only works in some major browsers. Edit for downvoters: Do you think it's factually incorrect, or just an inconvenient truth?
  - AlchemistCamp 5y ago
    One of wasm's key features is the ability to write much more compact, memory-efficient code.
    - labawi 5y ago
      That's very .. relative. Yes, I'm sure it's a better fit for compiled Quake, or a Dos emulator. Are there any examples beating "HTML, CSS, and targeted JS" on typical webpage usecases? 500 kB fits a lot HTML, CSS and JS, uncompressed.
      - brabel 5y ago
        > Are there any examples beating "HTML, CSS, and targeted JS" on typical webpage usecases? No, and you won't find any. That's not the use case for WASM right now. If your JavaScript code's purpose is to manipulate HTML/CSS, then using WASM will likely make it slower and worse. That will change and WASM gains the ability to access the DOM without going through JS, but that requires many other big features like GC and reference types, and given that there's not a lot of people working on these things anymore after the Mozilla implosion, it might take many years still, or even never happen.
journey_16162 5y ago
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.

azakai 5y ago

> 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).

the__alchemist 5y ago
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
- smt88 5y ago
  It sounds like you made a Rust version of React. I think a Rust version of Svelte makes more sense in the long run.
  - the__alchemist 5y ago
    Accurate, and I agree.
  - worik 5y ago
    Do it
  - khimaros 5y ago
    this may interest you: https://github.com/Pauan/rust-dominator https://github.com/Pauan/rust-dominator
  - johnsoft 5y ago
    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-framework-benchmark/ https://github.com/whatisaphone/cope/blob/master/crates/js-f... [2]: https://cdn.discordapp.com/attachments/751355413701591120/776076384430063616/unknown.png https://cdn.discordapp.com/attachments/751355413701591120/77... [3]: https://cdn.discordapp.com/attachments/751355413701591120/776065938818727936/unknown.png https://cdn.discordapp.com/attachments/751355413701591120/77...
  - bschwindHN 5y ago
    Sycamore looks interesting, though it needs some more ergonomic improvements before it becomes more widely usable. https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore
    - lukechu10 5y ago
      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.
- azakai 5y ago
  Thanks!

Svenstaro 5y ago

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.

the__alchemist 5y ago
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.
- TheCoelacanth 5y ago
  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.
jhugo 5y ago
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.)
jordwest 5y ago
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.

jjcm 5y ago

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.

smohare 5y ago
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.
labawi 5y ago
May I suggest changing: > WebAssembly is newer with less support. Browser compatibility is at 92.9%. To something a little less wasm-optimistic? Maybe something like: Requires WebAssembly. Inherently bloated, slow and only works in some major browsers. Edit for downvoters: Do you think it's factually incorrect, or just an inconvenient truth?
- AlchemistCamp 5y ago
  One of wasm's key features is the ability to write much more compact, memory-efficient code.
  - labawi 5y ago
    That's very .. relative. Yes, I'm sure it's a better fit for compiled Quake, or a Dos emulator. Are there any examples beating "HTML, CSS, and targeted JS" on typical webpage usecases? 500 kB fits a lot HTML, CSS and JS, uncompressed.
    - brabel 5y ago
      > Are there any examples beating "HTML, CSS, and targeted JS" on typical webpage usecases? No, and you won't find any. That's not the use case for WASM right now. If your JavaScript code's purpose is to manipulate HTML/CSS, then using WASM will likely make it slower and worse. That will change and WASM gains the ability to access the DOM without going through JS, but that requires many other big features like GC and reference types, and given that there's not a lot of people working on these things anymore after the Mozilla implosion, it might take many years still, or even never happen.

journey_16162 5y ago

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.