yjbanov
It's mostly about algorithmic trade-offs. When you know your content layout is static and is highly biased towards vertical scrolling, you take different kinds of performance trade-offs, such as pre-computing and caching layout and painting output. Like when you know your array is sorted, you can use binary search to find an element instead of scanning. When pages do invalidate HTML layout you will actually see very bad jank. This is one of the classic performance pitfalls on the web, even using "classic" frameworks, like React or Angular. Flutter's current widgets and rendering primitives are biased towards dynamic content, where over-computation like this would hurt performance when you layout or paint isn't stable. Instead, we optimize for volatile content, using tricks like lazy rendering and repaint boundaries. We can still add primitives needed to render static content efficiently. We just feel like we're not yet sufficiently done with the non-static case.
Curious what's not working in Flutter's accessibility. We are aware of multiple bugs, some specific to a particular assistive tech not interpreting our ARIA attributes that we need to work around, but our accessibility support is rarely described as not ready.
- Memory management without GC - Unboxed data structures - SIMD - Shared-memory multi-threading - Precompiled snapshots (does not need to be recompiled on page reload)
There's no difference between CanvasKit and HTML as far as interactions are concerned. The differences are in pixels and performance. If there are issues with interactions, we'd like to hear about them. Please file issues on Github.
We certainly don't think Flutter should replace HTML or other frameworks. We hope Flutter will work well for many use-cases, but the web is huge. There's room for multiple approaches. If it's not working for your use-case it's totally fine with us if you use something else. We welcome constructive feedback on what's not working so we know where to focus our efforts.
The "Create account" link isn't popping up the right-click menu because it doesn't use the Link widget. You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer. I think issues like that will inevitably pop-up as we have developers coming to the web from other platforms, where "open in new tab" isn't part of the toolkit. Perhaps it's fixable via education and platform-specific guidelines.
We're aware of the input blur issue. I think the bug is in the TextEditable. You can write your own, of course, but since we offer it as part of the Flutter framework, it's on us to fix.
Vimium is an interesting use-case. I've never heard of this extension. We have in the past enabled accessibility DOM all the time, but due to performance concerns changed it to be opt-in. If you use the standard screen reader (e.g. VoiceOver on iOS/macOS, TalkBack on Android, etc) you will get a way to enable accessibility DOM with ARIA tags, etc. Perhaps we should reconsider it (may need to optimize it a little though). I'd be curious whether Vimium works when accessibility is enabled.
Some features you list we either should support or already do: backswipe (good feature request), text selection (use the SelectableText widget), links (in the works), image URLs (good feature request). Not sure what navigating by landmarks is, but perhaps something we could support too.
Stylesheets are a non-goal. We do allow embedding plain HTML/CSS (called "platform view"), where you can use CSS, but Flutter's own widget system uses its own styling/theming.
Reader mode makes sense for "documents" (think news sites, wiki, documentation, etc), but it's unlikely to work out of the box in dynamic apps (think email, calendar, maps, graphics editor, etc) which is the kind of apps Flutter is going for. There's a similar issue with Ctrl + F (Cmd + F) to find text on page, which is not helpful in dynamic apps. Dynamic apps are better off implementing their own app-specific "reader mode" and "search bar", one that takes the nuances of the app into account. But never say never, maybe that's doable too, perhaps using our accessibility tree, at least for static document use-cases.
I personally expect this trend to continue, as in most desktop native apps text is not selectable either. In fact, in many web apps (those that are really _apps_, not just static web-sites) there's lots on non-selectable text. Case in point, I just checked Gmail's landing screen, and I failed to find a single piece of selectable text.
We actually use plain standard HTML and ARIA attributes for accessibility. If you don't see them, try enabling a screen reader (e.g. TalkBack on Android, VoiceOver on iOS/macOS), then you'll be able to enable accessibility in the app. If you are having problems with a11y, please file a github issue. A11y is very important to us.
It would be more interesting to see results for benchmarks such as DeltaBlue or Richards. These would correlate much better with gmail and hipmunk performance, as opposed to in-browser demos of Unreal Tournament.