Rendering Flutter to DOM sounds like a huge effort bound to fail on some level - just use React and React native if you are leaning in that direction. Im sure Flutter can add some shims to get basic stuff like navigation working to be more web like.
* Inspect the HTML tree containing the ARIA attributes generated by Flutter.
Wouldn't that help with SEO as well?
But the problems we’re talking about are far broader than “does my screen reader work”. Do my links work properly—Ctrl+Click, middle-click, long press, hover? (This one is fixable with only mild compromise. Those that follow are not.) Does my text render correctly? Can I select it and use my browser’s context menu or other similar tools? Does content scroll properly, at correct rates, with correct inertia, without jank or at least a frame’s latency? It’s these sorts of things that Flutter’s pure-canvas approach cannot fix, and they affect, in smaller ways, a lot more people.
I’ve written more specifically about the problems here on HN quite a few times. Search and you’ll find ’em. I really should get down to writing a detailed article about it all at some point… it’s been quite a few years.
I do agree that this all absolutely sucks for websites, but if you're building an App that is supposed to run in the browser like Rive or Figma, where you're going to override all click handlers anyways, or where where what you're rendering would be too much for the DOM, Flutter Web is pretty ok.
In addition to the pitfalls mentioned like being unable to select text, every interaction including scrolling is noticeably laggy and dropping frames.
Because of this alone I would not use.
The only way you can get the proper behaviour for these things on the web is to use actual DOM text. Some parts of it could in theory be made possible, but I doubt that anything meaningful will ever change—it’s too antithetical to the nature of the web.
Indeed, Flutter will never do everything "properly". But that's not its selling point. It doesn't need to, as long as the number of users reached from a multi-platform release outweighs the users lost because they were offended by a missing native feature. (Assuming you're not some massive company developing a parallel app for each platform)
Additionally, see: https://news.ycombinator.com/item?id=43215065
Even this relation can be inverted: to speed up SVG interactions, I pre-render complex path and text elements at a sufficient resolution, which are shown during transitions/user interactions, but replaced with the SVG original elements once the render loop settles down again.
No. You're fundamentally misunderstanding the broadness of the web platform.
On a broad platform even niche use cases are common. If I'm developing an application that will be used by 50 users then none of your concerns are relevant. I know my user base and I know what I need to achieve.
If compiling to WebAssembly and using canvas makes the most sense then that's what I'm going to do, especially if it means I can make use of existing business logic.
It is precisely the broadness of the web platform that makes this possible.