How exciting. One of the great things about React is that it's just as much a pattern as a library, and with Rust macros and v-dom it should be rather easy to build something similar to JSX in Rust (with the proper Rust-isms of course). Can't wait for Rust to rule the web.
Fast, Bump-Allocated Virtual Doms with Rust and Wasm
11–20 of 62 posts
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#12How exciting. One of the great things about React is that it's just as much a pattern as a library, and with Rust macros and v-dom it should be rather easy to build something similar to JSX in Rust (with the proper Rust-isms of course). Can't wait for Rust to rule the web.
I'm watching https://github.com/bodil/typed-html personally; not just JSX, but statically typed!
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#13Yes, 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.
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-togeth... ). But almost all of the previous work has bee…
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.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#14Yes, 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.
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.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#15Earlier quoted context omitted.
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-togeth... ). But almost all of the previous work has bee…
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.
Could you elaborate on what Piet and Druid are, perhaps with a few links? I assume you don't mean the esolang[0].
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#16>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM.
I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative.
Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#17Firstly, congrats on shipping a virtual DOM lib in WASM. Hopefully, frameworks intent on using a V-DOM will greatly benefit from this. Having said that, is a V-DOM required in 2019, if DOM updates are optimally batched, like in FastDom ( https://github.com/wilsonpage/fastdom ). Decades of optimizing browser internals would surely account for not trashing the DOM, if updated optimally. So, is it required?
It’s never been required — and is usually substantially slower – but a virtualdom may be worth the overhead because it avoids the need to organize those updates. Most cases aren’t performance sensitive to the point where that’s the deciding factor in a decision.
It appears lit-html is using a method that keeps updates declarative. https://lit-html.polymer-project.org/
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#18Yes, 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.
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…
See also (for one example) Notion (https://www.notionjs.com): Node version management, in Rust, for fully-reproducible environments. (I contribute a bit!)
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#19Earlier quoted context omitted.
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.
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
Sure, sorry about the initial omissions.
Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm
#20>Virtual DOM libraries provide a declarative interface to the Web’s imperative DOM. I'm not sure what this means. DOM is an object model for HTML. It is mutable, but HTML itself is definitely declarative. Which brings up an interesting question. Why are DOM-diffs something that is done by userland libraries when it can and probably should be done by the browser itself?
My guess is that the desired DOM is entirely re-created from some state, instead mutating it in place. The declarataivity then is that "given this state the DOM should be this".