This is often said, and almost as often misunderstood as referring to what I call the “pure canvas” approach where you throw away almost everything the browser gives you and start from scratch. Some key points about Google Docs, just to clarify (I’m not disagreeing):
① Only its document area is rendered with canvas; its chrome is all still regular HTML.
② It still uses the browser for text shaping and painting, just not for macro-layout (breaking paragraph into lines, &c.). (I expect that’s what this article’s subject would be doing too, but it’s part of common misunderstandings.)
③ Even things like scrolling are completely left to the browser: it’s not a single <canvas>, but a regular DOM scrolling area contains a bunch of <canvas> tiles.
④ The shunning of using HTML-with-contenteditable for the entire thing makes editing perform very badly (throughput, latency and jitter), and things like keyboard caret navigation behave non-natively in ways that will be very frustrating for people that actually use and care about this stuff (you get to relying on things behaving the same, like with touch typing, so things that get it wrong like Google Docs and LibreOffice (which gets it all wildly wrong) constantly grate).
⑤ They could just as easily use HTML or SVG rendering as <canvas> (while keeping their input and layout the same, so I mean still with all manual line breaks and that kind of thing). You’d get quite similar performance (though probably overall a little worse), and the same problems (since it’s the input layer that makes it slow and jittery—it just fundamentally can’t be as good in those ways as boring old contenteditable, given the current primitives). In fact, it’d mildly surprise me if they didn’t have an SVG or HTML renderer handy, or did in the past and could revive it to complete indistinguishable functionality within a day or two (even if hacky).
This is often said, and almost as often misunderstood as referring to what I call the “pure canvas” approach where you throw away almost everything the browser gives you and start from scratch. Some key points about Google Docs, just to clarify (I’m not disagreeing):
① Only its document area is rendered with canvas; its chrome is all still regular HTML.
② It still uses the browser for text shaping and painting, just not for macro-layout (breaking paragraph into lines, &c.). (I expect that’s what this article’s subject would be doing too, but it’s part of common misunderstandings.)
③ Even things like scrolling are completely left to the browser: it’s not a single <canvas>, but a regular DOM scrolling area contains a bunch of <canvas> tiles.
④ The shunning of using HTML-with-contenteditable for the entire thing makes editing perform very badly (throughput, latency and jitter), and things like keyboard caret navigation behave non-natively in ways that will be very frustrating for people that actually use and care about this stuff (you get to relying on things behaving the same, like with touch typing, so things that get it wrong like Google Docs and LibreOffice (which gets it all wildly wrong) constantly grate).
⑤ They could just as easily use HTML or SVG rendering as <canvas> (while keeping their input and layout the same, so I mean still with all manual line breaks and that kind of thing). You’d get quite similar performance (though probably overall a little worse), and the same problems (since it’s the input layer that makes it slow and jittery—it just fundamentally can’t be as good in those ways as boring old contenteditable, given the current primitives). In fact, it’d mildly surprise me if they didn’t have an SVG or HTML renderer handy, or did in the past and could revive it to complete indistinguishable functionality within a day or two (even if hacky).
(I wrote a little more at https://news.ycombinator.com/item?id=33863185.)