>
The document in Google Docs is a Canvas.This is only mostly true, and no justification at that. I’ll just quote myself from a couple of years ago https://news.ycombinator.com/item?id=42253177>:
> 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.
I haven’t ever examined Google Sheets closely, but it looks to use a similar approach, but worse in scrolling (it’s very obnoxious compared with native on my device—lags fiercely, and breaks inertia).
Excel I can’t comment on.
Docs should definitely have stayed HTML.
Sheets and Excel should probably be HTML, or possibly SVG.
For Hivekit’s scheduling interface as shown, I’d say most of the area should be HTML, but that I wouldn’t object to canvas or SVG for the centre area.
Now, for their reasons.
• Speed: at the level of complexity they’re talking about, this is flat nonsense. Yes, the browser does more than necessary, but a lot of effort has gone into making it perform far better than it has any right to, and DOM performance is not your bottleneck. (I mean by this that, if it looks like it is, it would be if you did the same thing with canvas too.) And as soon as it comes to things like scrolling, you cannot perform or behave as well as the browser, because the browser is a compositor and you can’t work at that level. Even in the rest, unless the entire thing is owned by a single small team skilled at saying “no” and at implementing everything from scratch rather than leaning on others’ libraries, your code is very unlikely to do better than the browser.
• Control: it undermines its own point completely by talking of scrolling. You must use real DOM for the scrolling, or else it will be horrible to use on a reasonably large fraction of devices. Note how the likes of Google Docs and Sheets use real DOM and render slices with the adding and removing and such that it criticises.
• Consistency: you only get this if you do all the text rendering yourself from first principles, which Google Docs and Sheets don’t do because it performs terribly. So no, this one falls flat too.
(I’ll continue more later, got to go again.)