4 ms·

Yes, I was thinking web developers, rather than using rust and wasm directly, would first get the benefits when the libraries they use start moving the heavy du

Yes, I was thinking web developers, rather than using rust and wasm directly, would first get the benefits when the libraries they use start moving the heavy duty parts to it. Can't wait to see if someone uses this for building a react-like framework.

k__ 8y ago
Would be interesting to see if React could simply integrate it.
steveklabnik 8y ago
The Rust Wasm working group agrees, and that's why they've been pursuing a strategy of building libraries, rather than full front-end frameworks. There are some people who are doing that, and now that the "build a library in wasm" story is going pretty well, there are some plans to move into that space too (https://rustwasm.github.io/2019/03/12/lets-build-gloo-together.html https://rustwasm.github.io/2019/03/12/lets-build-gloo-togeth...). But almost all of the previous work has been for libraries.
- dman 8y ago
  I am hopeful for the other half to land as well - heres to hoping that something like piet and druid results in a completely rust based Application delivery platform that ships in the browser.
  - vanderZwan 8y ago
    Could you elaborate on what Piet and Druid are, perhaps with a few links? I assume you don't mean the esolang[0]. [0] https://esolangs.org/wiki/Piet https://esolangs.org/wiki/Piet
    - dman 8y ago
      Sure, sorry about the initial omissions. https://github.com/xi-editor/druid https://github.com/xi-editor/druid https://github.com/linebender/piet https://github.com/linebender/piet
      - vanderZwan 8y ago
        Thanks! Looks very interesting, going to watch the video about Druid linked in the README.MD later[0]. And no worries, it's very easy to forget not everyone is introduced! Anyway, to actually engage with your point: I can see the appeal of an all-Rust framework: good typing system + high performance (both in speed and low memory use, ideally) sounds fantastic! So out of curiosity: how do you think hot swapping would be handled? I'm asking this who has not dived into Rust at all and only observed it with interest from a distance. For starters, I understand Rust has fairly slow compilation times, no? Or is that only true for optimized code and do we have fast debug options? Similarly, hot swapping requires maintaining state. With JS that's not too difficult because you don't worry about memory layout: as long as the high-level structure and names are the same the code works fine (it just kills the JIT optimizations). With WASM, that goes out the window: add or remove a field to your struct and all offsets change. Rust may guarantee no memory leaks, but that is not the same as guaranteeing that a snapshot of the memory state of one Rust program works on a different one. I guess some kind of "export to/import from JavaScript based representation" glue code that runs every hot reload could work, but that sounds like it could really freeze the browser when hot-reloading the big frameworks. [0] https://www.youtube.com/watch?v=4YTfxresvS8 https://www.youtube.com/watch?v=4YTfxresvS8 would be funny if I forgot to include links myself at this point :p
        dman 8y ago
        Had to look up hot swapping, to be honest I dont think the experience will be as good as it would be for dynamic languages like Dart / Javascript.
bfrydl 8y ago
I believe this is also true for development tooling, not just actual code executing in the user's browser. There's no real reason why tools like webpack, eslint, and so on need to be written in JS for most use cases. Members of the Rust community in particular are actively working in this space, building ES parsers, transpilers, and module bundlers. There's no all-in-one solution but even now with a little effort you could replace webpack with Rust-made tools, so long as you don't mind losing hot reloading or code splitting.
- chriskrycho 8y ago
  See also (for one example) Notion (https://www.notionjs.com https://www.notionjs.com): Node version management, in Rust, for fully-reproducible environments. (I contribute a bit!)

k__ 8y ago

Would be interesting to see if React could simply integrate it.

steveklabnik 8y ago

The Rust Wasm working group agrees, and that's why they've been pursuing a strategy of building libraries, rather than full front-end frameworks. There are some people who are doing that, and now that the "build a library in wasm" story is going pretty well, there are some plans to move into that space too (https://rustwasm.github.io/2019/03/12/lets-build-gloo-together.html https://rustwasm.github.io/2019/03/12/lets-build-gloo-togeth...). But almost all of the previous work has been for libraries.

dman 8y ago
I am hopeful for the other half to land as well - heres to hoping that something like piet and druid results in a completely rust based Application delivery platform that ships in the browser.
- vanderZwan 8y ago
  Could you elaborate on what Piet and Druid are, perhaps with a few links? I assume you don't mean the esolang[0]. [0] https://esolangs.org/wiki/Piet https://esolangs.org/wiki/Piet
  - dman 8y ago
    Sure, sorry about the initial omissions. https://github.com/xi-editor/druid https://github.com/xi-editor/druid https://github.com/linebender/piet https://github.com/linebender/piet
    - vanderZwan 8y ago
      Thanks! Looks very interesting, going to watch the video about Druid linked in the README.MD later[0]. And no worries, it's very easy to forget not everyone is introduced! Anyway, to actually engage with your point: I can see the appeal of an all-Rust framework: good typing system + high performance (both in speed and low memory use, ideally) sounds fantastic! So out of curiosity: how do you think hot swapping would be handled? I'm asking this who has not dived into Rust at all and only observed it with interest from a distance. For starters, I understand Rust has fairly slow compilation times, no? Or is that only true for optimized code and do we have fast debug options? Similarly, hot swapping requires maintaining state. With JS that's not too difficult because you don't worry about memory layout: as long as the high-level structure and names are the same the code works fine (it just kills the JIT optimizations). With WASM, that goes out the window: add or remove a field to your struct and all offsets change. Rust may guarantee no memory leaks, but that is not the same as guaranteeing that a snapshot of the memory state of one Rust program works on a different one. I guess some kind of "export to/import from JavaScript based representation" glue code that runs every hot reload could work, but that sounds like it could really freeze the browser when hot-reloading the big frameworks. [0] https://www.youtube.com/watch?v=4YTfxresvS8 https://www.youtube.com/watch?v=4YTfxresvS8 would be funny if I forgot to include links myself at this point :p
      - dman 8y ago
        Had to look up hot swapping, to be honest I dont think the experience will be as good as it would be for dynamic languages like Dart / Javascript.

bfrydl 8y ago

I believe this is also true for development tooling, not just actual code executing in the user's browser. There's no real reason why tools like webpack, eslint, and so on need to be written in JS for most use cases. Members of the Rust community in particular are actively working in this space, building ES parsers, transpilers, and module bundlers. There's no all-in-one solution but even now with a little effort you could replace webpack with Rust-made tools, so long as you don't mind losing hot reloading or code splitting.

chriskrycho 8y ago
See also (for one example) Notion (https://www.notionjs.com https://www.notionjs.com): Node version management, in Rust, for fully-reproducible environments. (I contribute a bit!)