Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications.
Flutter… ugh, Flutter on the web is awful awful awful awful awful AWFUL AWFUL and I will hate you if you decide with open eyes to use it when you’re deliberately targeting the web.⁴ I lack energy to express my vitriolic loathing. Just go through https://hn.algolia.com/?query=chrismorgan%20flutter&type=com..., there’s lots of detailed explanation of specifically what’s bad, if you need it.
Avalonia Visual Basic 6? It’s the kind of thing where the limitations will show least, because of how limited it is. And also because it’s imitating (not quite the right word, but close enough) ancient software which itself wouldn’t work fully properly if run on current machines. Its text handling is dodgy, doesn’t do composition properly, scrolling is non-native, context menus are non-native which stops some things from working properly… but honestly that’s kinda the vibe they’re going for, so it’s not particularly upsetting.
Pure-canvas is irredeemably bad. With difficulty you can make some things decent even with it, but excellence is impossible with pure canvas.
Flutter and Google Docs did not give up on DOM for the reasons you cite. Google Docs, I honestly don’t understand why they gave up on DOM, the reasons they cited publicly genuinely don’t make sense. Flutter, it was because they don’t actually care about the web, it’s a third-class target, and too much of the way they design their API doesn’t port to DOM directly, so that making DOM a first-class citizen would have required compromises in their APIs that they were unwilling to make. But it was emphatically not about cross-browser consistency.
—⁂—
¹ Seriously, Google Docs is slower than it used to be, especially with higher latency and jitter.
² The parts they replaced had no consistency problems in any realistic browsers. Seriously. Their layout requirements are, in practice, really basic. The area where consistency can actually be a problem is text shaping and rendering, but they haven’t replaced that since it would tank performance.
³ My favourite example is keyboard navigation. It doesn’t match platform conventions, and that’s really irritating. Since we’re in this thread, LibreOffice also flouts platform conventions in this area, and it’s really irritating.
⁴ If you’re focusing on mobile and make a mobile app with Flutter and also put it on the web with Flutter because why not, better than nothing, I won’t like you very much, but I’ll at least understand. But if you’re saying “we need a web thing, how about we use Flutter”… no.
> But if you’re saying “we need a web thing, how about we use Flutter”… no.
If you're making an application, there's really nothing special about the DOM.
You might as well control your drawing. That way you don't need to figure out cross browser incompatibilities all day.
And here's what someone who used to work on Google Docs has to say about it:
Please look over my comments on HN about Flutter and pure-canvas and such. There are big problems. There is plenty special about the DOM that you lose and cannot gain back if you go pure-canvas. Links. Scrolling. Text handling. Composition. And various more.
Use DOM. Please use DOM.
Use canvas for an actual drawing canvas, but for the UI and anything else that’s largely text, use DOM.
There aren't "big problems" because it works. When you put yourself in the corner of claiming "pure-canvas is irredeemably bad" when it's plainly not, then there's nothing practical on offer.
“It works” is a terrible defence, because of the different degrees of working.
I’m describing various specific ways in which it doesn’t work properly, in ways that stop users from doing things they may legitimately want to do, or which will frustrate some users, and you’re just disregarding them. I’m not being vague in most of my complaints, I’m being very specific.
It’s like you have a screw, and it’s worn enough that sometimes it makes the screwdriver slip, but you’re saying “just be careful, maybe apply a little more pressure, and it still works”.
> and you’re just disregarding them.
Of course. You're living in a world of your own imagined requirements. The practical reality is that there are plenty of use cases for this stuff, whether you like it or not. This stuff is fit for purpose for many purposes.
How the hell you can claim “it works” if you can’t even select text out of the box, lmao?
Because I can select text out of the box.
Okay, this getting absurd. At this point I’m 90% convinced that you’re just trolling.
https://news.ycombinator.com/item?id=42252999
You can’t select text in neither of your provided samples on both PC and mobile in different browsers.
You can. Text selection works, cut and copy and paste works, zooming works.
I don't know what you're doing.
What about screen readers and mobile users? There's all these useful accessibility tools that would also have to be reinvented for canvas based apps.
Text selection and getting it to bring up a keyboard is iffy on the canvas-based things you linked to (I'm looking at them on Firefox for Android on a Pixel 6). Sure, the VB one is a desktop app. But the original (non canvas) version of that app likely worked with windows screen readers, and that is lost in this reincarnation onto the web. Good old fashioned DOM already has pretty good native accessibility support for mobile phone UI.
There's a lot of things that have been thought about when it comes to usability and accessibility, in both the web, and traditional desktop/mobile UI frameworks.
Reimplementing those UI frameworks in canvas in a browser environment requires mapping the a11y bits too, not just keyboard+mouse input and rendering to screen.
Not to mention Qt and Gtk and the older Android framework apps all use forms of markup and styling which are inspired by XHTML and CSS and document object models......