Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most.

Providing access to an already proven DOM would be the better solution.

> And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application.

The download isn't much different to a typical website. That Flutter demo in wasm is 2 megabytes.

Avalonia UI's WebAssembly uses canvas in C#: https://avaloniaui.net/

Uno Platform's WebAssembly implementation uses the DOM rather than drawing to canvas: https://platform.uno/

Uno's philosophy is to use platform native controls. The benefit is that you get platform native characteristics, the cost is it will never be exactly the same in each browser and platform.

You're joking, right? A 2mb bundle is *absolutely unacceptable*. People complain about React which is less than 100kb minified and gzipped. This website doesn't even include any images or anything...

It's clearly not. Real world applications exist today. Here's one:

https://earth.google.com/

2mb for Google Earth might be fine, but Google Earth is not your typical web app.

A 2mb base floor before any code or assets is not acceptable for most use cases.

What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?

What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?

I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options:

A) Get your hands dirty and write what you want. Once.

B) Chant along with the mob who doesn't even understand what they're asking for.

C) Wait several years for some super complicated solution to be designed by committee.

I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious.

Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on...

I choose option A.

there is also option D.

wait for a framework that implements option A.

if option A works, why aren't there any frameworks yet that implement it?

maybe all the framework devs are waiting for C?

but why?

you could be right about A but at present the majority view seems to be that C is the right option. which is what pushes me into going with B because i have no interest in developing my own framework.

if a framework appears that implements option A i'll gladly consider it. (just as long as it isn't tightly coupled with a backend)

So throwing out literally 99% of what makes the web actually portable and useful?

A random drawn rectangle is not a UI, it’s not accessible, not inspectable, not part of the de facto OS native toolkit.

If all we wanted is a random cross-platform canvas element to draw onto from a vm, it could be solved in a weekend. There are million examples of that.

> A random drawn rectangle is not a UI

Of course it is. All screen based user interfaces are blinking lights.

> it’s not accessible

It's best to read the documentation first. It's a low effort thing to do:

https://docs.flutter.dev/ui/accessibility-and-internationali...

Its web targeted version is still not accessible, even though they promised that they will actually render to HTML elements as much as possible. A single canvas element is not that.

If you're not going to read the documentation, read a blog post:

https://medium.com/flutter/accessibility-in-flutter-on-the-w...

From your own article:

> The Flutter team would like to eventually turn the semantics on by default in Flutter Web. However, at the moment, this would lead to noticeable performance costs in a significant number of cases, and requires some optimization before the default can be changed

Ah, so you admit it does indeed include accessibility but now what you're complaining about is performance. Not that you've actually tried it of course.

But good. That's a kind of progress.