Iced: (V)DOM renderer

Created on 7 Sep 2019  路  4Comments  路  Source: hecrj/iced

Iced working on the web would be awesome, the plan of creating a low level renderer with wgpu-rs is great but could take some time on your side and theirs(last time I checked web support was not there?) so DOM rendering in the mean time?(side question, would it be easy to mix renderers? like a map component rendered with a wgpu renderer and the rest of the UI with the DOM one?).

The flexbox model of iced should make it easy to create a DOM renderer. For example with Dodrio, the experimental virtual DOM library showcased by Mozilla, should facilitate things and help with performance at the same time instead of using web-sys APIs directly. Structs implement the render trait of dodrio and build the DOM elements, so would it be just implementing the dodrio trait for each widget and put some DOM there?

feature

Most helpful comment

Iced working on the web would be awesome, the plan of creating a low level renderer with wgpu-rs is great but could take some time on your side and theirs(last time I checked web support was not there?)

Indeed, as far as I know WebGPU will still take some time. I have been able to run Iced on web with wgpu on top of WebGL (https://github.com/hecrj/coffee/pull/63). For instance, here is the UI tour (may take some time to load, text does not display on some environments and gamma correction does not work yet, so it is quite dark): http://ui-coffee-rs.surge.sh/

However, using WebGL has been quite clunky. I would say it is not worth investing a lot of effort into it.

(side question, would it be easy to mix renderers? like a map component rendered with a wgpu renderer and the rest of the UI with the DOM one?)

Hard to say this early, but I think the DOM renderer could contain a wgpu renderer, and use a special widget to embed native UIs in a DOM UI. It would basically create a canvas and draw to it using WebGPU while emulating a runtime. This would be amazing. A single codebase in Rust could be used to build a website and a webgame all at once! I want this.

[...] with Dodrio,

I did not know about Dodrio! It looks like it is exactly what we need. :tada:

so DOM rendering in the mean time?

I have been thinking about it, and I already have some ideas to improve iced and make the abstraction better. I think we need an additional Runtime (name subject to change) generic type, which should tie layouting and event processing together.

In iced_web we will not need a Runtime (no layouting and event processing), as it will be a part of the Renderer (the browser). This means we will be able to drop the stretch and twox_hash dependencies, and move them to a different crate.

You know what? I am very excited about this now. I will try to play with web support really soon.

All 4 comments

Iced working on the web would be awesome, the plan of creating a low level renderer with wgpu-rs is great but could take some time on your side and theirs(last time I checked web support was not there?)

Indeed, as far as I know WebGPU will still take some time. I have been able to run Iced on web with wgpu on top of WebGL (https://github.com/hecrj/coffee/pull/63). For instance, here is the UI tour (may take some time to load, text does not display on some environments and gamma correction does not work yet, so it is quite dark): http://ui-coffee-rs.surge.sh/

However, using WebGL has been quite clunky. I would say it is not worth investing a lot of effort into it.

(side question, would it be easy to mix renderers? like a map component rendered with a wgpu renderer and the rest of the UI with the DOM one?)

Hard to say this early, but I think the DOM renderer could contain a wgpu renderer, and use a special widget to embed native UIs in a DOM UI. It would basically create a canvas and draw to it using WebGPU while emulating a runtime. This would be amazing. A single codebase in Rust could be used to build a website and a webgame all at once! I want this.

[...] with Dodrio,

I did not know about Dodrio! It looks like it is exactly what we need. :tada:

so DOM rendering in the mean time?

I have been thinking about it, and I already have some ideas to improve iced and make the abstraction better. I think we need an additional Runtime (name subject to change) generic type, which should tie layouting and event processing together.

In iced_web we will not need a Runtime (no layouting and event processing), as it will be a part of the Renderer (the browser). This means we will be able to drop the stretch and twox_hash dependencies, and move them to a different crate.

You know what? I am very excited about this now. I will try to play with web support really soon.

A quick progress report! I have been able to run the tour example on WebAssembly using dodrio.

I have implemented the tricky part first: the runtime. In other words, rendering using dodrio, correctly producing __messages__ inside listeners, and then feeding these back to the app while scheduling a new render. I have also set up the basics for async operations using futures, similar to the way Cmd works in Elm.

Proper styling of the elements is still work in progress, but should not be a blocker. I am using simple inline styles for now, and many are still not implemented (color, spacing, etc).

Additionally, the example is using almost the same exact UI code in [tour.rs]. The only difference is the Image intialization (on web we use a simple URI) and the Color type. These differences should be easy to unify.

This sets up the foundations of a cross-platform GUI API that can be used to target both native platforms and the web, all while using pure Rust!

You can try it here: https://iced-web.hecrj.now.sh/

I still have to restructure some code, but once the code is ready for review, I will open a PR with the changes!

Just a heads up.

I have opened a PR implementing a basic web runtime: #17. Any feedback is appreciated!

Hi there, Is there a way to run the widgets example with just using webgl renderer? I mean not using a vdom just plain webgl

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rowungiles picture rowungiles  路  4Comments

jiminycrick picture jiminycrick  路  3Comments

twitchyliquid64 picture twitchyliquid64  路  4Comments

hecrj picture hecrj  路  3Comments

michael-hart picture michael-hart  路  4Comments