4 ms·

They still seem to have something, from this page: https://docs.flutter.dev/ui/accessibility-and-internationalization/accessibility https://docs.flutter.dev/ui/

by brabel 2y ago

They still seem to have something, from this page: https://docs.flutter.dev/ui/accessibility-and-internationalization/accessibility https://docs.flutter.dev/ui/accessibility-and-internationali... * Inspect the HTML tree containing the ARIA attributes generated by Flutter. Wouldn't that help with SEO as well?

chrismorgan 2y ago
That gives you a distinct accessibility tree in the DOM, which is kinda dumb as an approach. One of the reasons for going pure-canvas on the web was supposed to be performance (I don’t think it was ever true, though—only if comparing with a bad DOM implementation), and if you have to enable this accessibility DOM, you’re guaranteeing you’re doing double work. And no, on the web you can’t just do it when you need it: you can’t poll if it’s needed. All you can do in that case is to present screen reader users with a “this page is currently empty, press this button to unbreak it” button. (Aside: I’ve seen that done once. And the button was broken.) 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.
- _bent 2y ago
  No, performance and fidelity are definitely better with the canvas renderers, especially skwasm. Flutter is very inspired by React, but instead of React which does tree diffing to minimize rebuilds, Flutter tries to make rebuilds as cheap as possible instead - for example through its single pass layout algorithm. The issue is that this doesn't map well to the DOM. You can't rebuild cheaply on the DOM because you'd be constantly updating the DOM. And you don't profit from your simpler layout, because you have to implement it in JavaScript and use absolute positioning on all DOM Elements to lay them out. 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.
  - dleeftink 2y ago
    I'm sure this is tried (I've done it myself), but a hybrid approach would take best of both worlds; heavy rendering on a canvas, the rest as SVG/DOM elements. 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.
  - charrondev 2y ago
    I went and loaded up the flutter web demo on my iPhone 15 Pro https://flutter.github.io/samples/web/material_3_demo/ https://flutter.github.io/samples/web/material_3_demo/ In addition to the pitfalls mentioned like being unable to select text, every interaction including scrolling is noticeably laggy and dropping frames.
    - Philpax 2y ago
      Wow, you weren't kidding: same phone and it feels like I'm using a 15-year-old Android. That's rough.
    - johnisgood 2y ago
      > unable to select text Because of this alone I would not use.
      - johnecheck 2y ago
        It's just not the default. As the developer, it's trivial to make text selectable.
        johnisgood 2y ago
        I meant it as an user.
        johnecheck 2y ago
- zfg 2y ago
  > But the problems we’re talking about are far broader 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.

by brabel 2y ago

chrismorgan 2y ago

That gives you a distinct accessibility tree in the DOM, which is kinda dumb as an approach. One of the reasons for going pure-canvas on the web was supposed to be performance (I don’t think it was ever true, though—only if comparing with a bad DOM implementation), and if you have to enable this accessibility DOM, you’re guaranteeing you’re doing double work. And no, on the web you can’t just do it when you need it: you can’t poll if it’s needed. All you can do in that case is to present screen reader users with a “this page is currently empty, press this button to unbreak it” button. (Aside: I’ve seen that done once. And the button was broken.) 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.

_bent 2y ago
No, performance and fidelity are definitely better with the canvas renderers, especially skwasm. Flutter is very inspired by React, but instead of React which does tree diffing to minimize rebuilds, Flutter tries to make rebuilds as cheap as possible instead - for example through its single pass layout algorithm. The issue is that this doesn't map well to the DOM. You can't rebuild cheaply on the DOM because you'd be constantly updating the DOM. And you don't profit from your simpler layout, because you have to implement it in JavaScript and use absolute positioning on all DOM Elements to lay them out. 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.
- dleeftink 2y ago
  I'm sure this is tried (I've done it myself), but a hybrid approach would take best of both worlds; heavy rendering on a canvas, the rest as SVG/DOM elements. 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.
- charrondev 2y ago
  I went and loaded up the flutter web demo on my iPhone 15 Pro https://flutter.github.io/samples/web/material_3_demo/ https://flutter.github.io/samples/web/material_3_demo/ In addition to the pitfalls mentioned like being unable to select text, every interaction including scrolling is noticeably laggy and dropping frames.
  - Philpax 2y ago
    Wow, you weren't kidding: same phone and it feels like I'm using a 15-year-old Android. That's rough.
  - johnisgood 2y ago
    > unable to select text Because of this alone I would not use.
    - johnecheck 2y ago
      It's just not the default. As the developer, it's trivial to make text selectable.
      - johnisgood 2y ago
        I meant it as an user.
        johnecheck 2y ago
zfg 2y ago
> But the problems we’re talking about are far broader 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.