[simulate-me]

What’s wrong with using a single canvas? It can be faster. Google Docs and Figma, for example, use canvas rendering

[gitgud]

Although it may render faster, it comes at a cost, as it completely circumvents what browsers are good at.

Flutter is basically just painting pixels on a canvas manually, meaning no CSS, no text selection, no text wrapping, no responsive elements, no elements without JS enabled. Many accessibility tools rely on CSS and text in HTML in order to work too.

It's a huge trade-off to make, and something to be aware of.

[LocalPCGuy]

Heavy emphasis on HUGE tradeoff. Too much for most web apps, IMO.

[slibhb]

I just checked and Google Docs is not a single canvas. It uses a canvas for the text but all the tools and so on are good old html.

[mhoad]

Believe it’s a work in progress https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

[dmitriid]

> What’s wrong with using a single canvas

You can't even select and copy text. And canvas is inaccessible to screen readers

[wildrhythms]

FYI there is a SelectableText widget included in Flutter[1] but the developer has to explicitly make text selectable just like iOS and just like Android apps. Desktop is a different story... many text selection paradigms that I'm familiar with on desktop (like double-click and hold and drag to select whole words) simply don't work right. It's not a great experience, but neither is the vast majority of non-Flutter mobile apps when it comes to selecting text too.

wrt accessibility, Flutter does actually generate elements with aria attributes for screenreaders to consume[2]. You're right that the canvas is inaccessible, which is why the aria labels have to be generated adjacent to that.

We're using Flutter for mobile development at my workplace.

[1] https://api.flutter.dev/flutter/material/SelectableText-clas... [2] https://docs.flutter.dev/development/accessibility-and-local...

[the_duke]

For accessibility they create a separate DOM tree just for screen readers.

[kevincox]

Because it destorys native browser features. For example find-in-page, hove to see where a link goes. Right click a link to bookmark, open in private window or copy the URL. If the page has anchors I can get a link to them. If I save or print the page it is an image rather than text (with all of the above features).

Some of these can be reimplemented easily, some of them with effort, but some just aren't possible. Plus the exact behaviours depend on what browser you are using, so you can't reimplement them because you don't know how the user's browser behaves.

For games or image editors this is probably fine. But for most apps this is a huge depredation in usability.

[strix_varius]

Both Google docs and figma use canvases, but neither of them renders the whole app through a canvas.

This is easy to verify - just open up dev tools and look at the DOM structure.

[kolanos]

Both are pretty disastrous accessibility-wise.

[SemanticStrengh]

no canvas are slower for UIs. The difference is between immediate vs retained mode rendering, and the later is order of magnitude more energy efficiency and is more performant, for well behaving not chaotically changing content.

[busymom0]

Canvas has accessibility issues for screen readers as well as for SEO purposes.