yjbanov

(disclaimer: I work on Flutter Web)

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.

(disclaimer: I work on Flutter Web)

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.

Flutter has accessibility. We create a html tree with ARIA attributes. It's not there if you don't have assistive technology enabled, however.

Depends on what the extension is trying to do with your app. If it's scanning your html then no, it won't work.

There are a few things that WASM can do that JS can't (at least not now):

- Memory management without GC - Unboxed data structures - SIMD - Shared-memory multi-threading - Precompiled snapshots (does not need to be recompiled on page reload)

(disclaimer: I work on the Flutter team)

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.

(disclaimer: I work on the Flutter team)

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.

Have you tried --web-renderer=auto?

(disclaimer: I work on the Flutter team)

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.

Do give `--dart-define=FLUTTER_WEB_USE_SKIA=true` a try (`flutter run` and `flutter build` take this option, which we hopefully will rename to something more reasonable soon). If that doesn't perform well, please file an issue: https://github.com/flutter/flutter/issues/new/choose

(disclaimer: I work on Flutter Web)

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.

While Flutter makes text selection an explicit choice for developers, Text vs SelectableText, for some reason Text ended up being most used. This is likely because SelectableText came after Text and because of Flutter's mobile background. Most mobile apps use non-selectable text, and so this ended up on Flutter developers' default path.

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.

I hear you. There's a link widget coming, multiple browser history models (we've only supported URL fragments, but are adding pushState, and custom URL strategies, as well as navigation API improvements). Keyboard navigation is being actively improved. Bug reports are always welcome: https://github.com/flutter/flutter/issues/new/choose

(disclaimer: I work on Flutter Web)

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.

WebAssembly compilation is a little orthogonal to getting the framework and rendering system up and running. We do not have to wait for WebAssembly to make progress on the UI side of things. Having said that, when WebAssembly is available for us to try, we certainly will.

All these benchmarks have "asmjs" in their names, which tells me they are not benchmarking idiomatic JavaScript, but JS generated by emscripten. If that's the case, they do not represent the performance of hand-written applications, which is the majority of all apps on the web.

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.