|
|
|
|
|
|
by themacguffinman
1940 days ago
|
|
|
It's true of course that as a cross-platform toolkit independently built on top of another platform, Flutter will have to consider new controls, gestures, and changes in many platforms. You could say the exact same things comparing Android/iOS/Windows to the cross-platform web: it's very hard to do and there are plenty of compromises, but it's still very valuable. There's been far more handwringing over the web's deficiencies as compared to native OS platforms; why reinvent the wheel with some crappy dynamic language called JS, why rebuild everything with a custom style language and layout engine? Yet Electron and web apps continue to dominate because the trade-offs can still be worth it. The web is not really adopting hordes of new input modes like WebXR every year, there'll be plenty of time for Flutter to consider new stuff like that before it approaches relevancy in mainstream product development. Accessibility features like voice assistant support don't necessarily come free either. Rich web applications usually don't produce simple/accessible DOM structures even if you're developing with web-native tooling. Flutter or not, accessibility practically always requires some level of manual annotation in web apps, which is Flutter's primary use case. > Not on the web though. I mean, for obvious reasons on the web we can't just expose native OS methods for websites to call. I meant native-to-the-web. Flutter's MethodChannels & plugin system works on the web too. If there are browser APIs that you need to use, you can setup hooks to call them from within Flutter. |
|
|
The difference is that the web efforts aren't being headed by one team in one company, they're a giant effort with a huge amount of funding, shared resources, and attention from multiple companies and communities.
Flutter doesn't have that benefit. It's not that nobody could build a cross-platform replacement for the web, it's that the web was hard to build, and it's very unlikely the Flutter devs are going to be able to repeat that effort on their own.
> Yet Electron and web apps continue to dominate
Largely because Electron piggybacks on existing work by embedding the entire Chromium engine, they're not building an entirely new render engine from scratch. And Electron still struggles trying to keep pace with native systems, even though it's largely just hooking into them instead of rewriting them.
> Accessibility features like voice assistant support don't necessarily come free either. Rich web applications usually don't produce simple/accessible DOM structures even if you're developing with web-native tooling.
The web gives you a lot for free though. It's sort of like comparing OpenGL and Qt. Sure, both require me to be thoughtful as a developer, but one requires me to be a lot more thoughtful.
----
The bigger problem here isn't whether application devs need to think about accessibility, it's for the Flutter dev team. It's that the web doesn't expose the kind of accessibility APIs that a pure Canvas UI needs to recreate all of the accessibility and screenreader support that's built into browsers. Qt on the web has run into the same problem. What you end up doing (because it's the only interface you have to work with) is either trying to on-the-fly maintain part of the DOM and working really hard to figure out which parts need to be maintained, or just flat-out adding a second, hidden DOM tree that screenreaders can interact with. The only way that Flutter can tell a screenreader that a piece of text exists is by making a node and putting it into the DOM.
This is, from what I can see, what Flutter does in its forms. It has a DOM representation of all of the input elements (but interestingly enough not the links or other text, so they're not screenreader accessible at all), and then completely separately, it re-implements the entire browser rendering stack. And the performance is... well, you can see the performance.
Flutter's strategy for handling events to those elements appears to be (for lack of a better term) inverted. It's "Render first, worry about the DOM second", which is not the way that I would try to build something like this. I don't want to read too much into it, maybe I'm misunderstanding their architecture, but the tab errors that people are seeing look to me like they exist because Flutter is trying to poorly reimplement how browsers tab, rather than using an underlying DOM model that could for free signal to them what the currently selected element is. Similarly a lot of the input selection and mouse lag is because it looks like they're doing collision detection in WASM and performing a DOM mutation every time they need to change the mouse cursor into a different shape. Which, yeah, of course that's not performant.
Ideally, a framework like this would target the DOM directly in the first place and use that to drive input, accessibility, and styling wherever possible, adding canvases back in only when necessary to override specific parts of rendering. That's the path that frameworks like Blazer and OpenSilver are trying to go down, which is just a lot more realistic of a goal for an individual team to accomplish.
I'm trying to thread a fine line here, because I haven't read Flutter's source code, so I don't know for certain how they're doing everything or why. I don't want to confidently say they're doing something wrong if I don't have the full picture. But I can see the outcome, which is currently pretty bad, and I can see little bits and pieces of the architecture they're using to get that outcome, which all seem very counterintuitive, overly-complicated, and buggy. I'm happy to be proven wrong in the future, but in the present there's a nearly half-second delay to change my mouse cursor when I hover over an input and none of the links in-app are screenreader accessible, so that's not exactly inspiring optimism. Sure, Flutter could theoretically overcome everything and keep pace with the web, but is that what's currently happening? They're announcing v2 and the web version is basically unusable.