> Google Docs switched to canvas three years ago:

And broke CJK and emoji input. They only fixed emoji input recently. CJK is still broken.

> Sure you can. Google Docs switched to canvas three years ago: https://workspaceupdates.g

You just need to be one of the critical projects for BigTech. Easy peasy, compared to <editor_command> index.html.

> This wasm application renders to canvas and works fine for me: https://bandysc.github.io/AvaloniaVisualBasic6/

Trying to select text on mobile Safari just selects whole canvas. Same for your Flutter example.

What a regression for web. Just so that a couple of snowflakes can use their fad of the day or can stay in their comfort zone.

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.

When you delve into badly-performing web apps, DOM is almost never the actual performance bottleneck. It’s other things they’re doing. And in the rare cases where DOM is the bottleneck, it’s always that they were abusing it.

As for this case, I have never encountered a web app with performance (throughput and latency) problems like this. Not anywhere near it.

Firefox is indeed a bit of a hit-and-miss these days (though we absolutely want to support it). Best experience currently is on Chrome(ium).

I use it at home just fine. Granted, I only use it for files and I’m not using the office apps from it.

What does "Nextcloud will eat your data" mean, specifically?

Do you mean the applications of the suit are buggy, or are they somehow hackable / leaking private information?

It wasn't frozen, Collabora were the ones doing the work and so they have largely hosted and developed LibreOffice Online.

It sounds like you might know the answer to this. Would it be straightforward to use this for sandboxed headless file conversion? You can do that already with LibreOffice, but it's a monster amount of unsafe code that's difficult to containerize securely

From the description here[1], it sounds like they're using WASM builds of LO.

I'm not quite interested enough to spend the CPU cycles it'd take to build and see whether that is really the whole story.

[1](https://github.com/allotropia/zetajs?tab=readme-ov-file)

Side question: did GTK3's HTML renderer get anywhere? I remember a calculator application running in a browser as a demo from a long time back.