Or you can just draw to canvas to make the UI fast which is what Flutter does now:
Providing access to an already proven DOM would be the better solution.
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.
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)
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.
A 2mb base floor before any code or assets is not acceptable for most use cases.
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.
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...
https://medium.com/flutter/accessibility-in-flutter-on-the-w...
> 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
But good. That's a kind of progress.