(V)DOM renderer about iced HOT 4 CLOSED

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 (hecrj/coffee#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. 🎉

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.

from iced.

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!

from iced.

Just a heads up.

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

from iced.

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

from iced.