Updated Over the next few months, Google plans to change the way its online word processor Docs renders its pages in web browsers, and collateral damage is expected.
In a blog post on Tuesday, the Chocolate Factory said it plans to move Docs from HTML-based rendering to Canvas-based rendering "to improve performance and improve consistency in how content appears across different platforms."
In so doing, there may be casualties. Chrome extensions that interact with Google Docs, for example, may break.
"Some Chrome extensions rely on the way the backend of a Google Doc is structured or specific bits of HTML to function properly," the ad giant explains. "By moving away from HTML-based rendering to a Canvas-based rendering, some Chrome extensions may not function as intended on docs.google.com and may need to be updated."
Maximiliano Firtman, a mobile and web developer and author, told The Register he expects problems with extensions and accessibility as a result of the rendering transition.
"For example, I use Grammarly and I understand it won't work as easily now, unless they provide an API for extensions," he said. "I haven't tried the new version, so I don't know how accessibility works on the new system. I expect Google to cover that at least. It's true that HTML is limited for doing some things and other Google products such as Flutter already use Canvas as the rendering engine when HTML can't solve a problem easily."
The Canvas element provides a way to create bitmapped images in the browser; it offers better performance than HTML-based (DOM-based) rendering in part because it supports hardware acceleration. Google's cross-platform development framework Flutter takes a similar approach, rendering applications using its CanvasKit API to take advantage of speedy graphics technologies like WebGL and recent innovations like WebAssembly.
Microsoft's Visual Studio Code, which is based on the Electron web framework, shifted its integrated terminal from HTML-based rendering to Canvas-based rendering in 2017.
"In some cases, composing elements and doing a layout could take longer than a frame (16.6ms) all by itself, which is unacceptable if we want to maintain a smooth 60 frames per second (FPS) in the terminal," explained Microsoft software engineer Daniel Imms at the time. "The solution for this was a new Canvas-based rendering engine."
The transition worked out well for Microsoft: Imms reported that rendering benchmarks for VS Code's integrated terminal showed improvement ranging from 5x to 45x faster.
In an email to The Register, Steve Newman, founder of Scalyer (recently acquired by SentinelOne), said while he couldn't say for certain whether Canvas-based rendering will really improve performance, he finds the claim quite plausible. "Also, conceivably, I could imagine it might be more robust (eg, across browsers) or more flexible in terms of being able to accommodate new rendering effects," he said.
Newman was a Google Docs tech lead more than a decade ago and left the company around the time Google was rolling out a major DOM-based rewrite of the app.
- Google's multi-platform app framework Flutter reaches version 2, expands to the web
- 'It's where the industry is heading': LibreOffice team working on WebAssembly port
- HTML5 may as well stand for Hey, Track Me Longtime 5. Ads can use it to fingerprint netizens
- WebAssembly: Key to a high-performance web, or ideal for malware? Reg speaks to co-designer Andreas Rossberg
Newman, however, doesn't see Canvas-based rendering having much to do with source readability. The trend toward less easily viewed source code is real, he said, "but it seems orthogonal to Canvas versus DOM."
"If there are third-party tools that are hacking their way into DOM elements to interact with Docs page elements, then yes, this probably makes their life harder," he said. "But my perspective would be that in the context of a rich application, that sort of integration is always going to be a rickety thing at best unless it's explicitly designed for, via either an application-specific API or something like COM. It's just not feasible to get that kind of integration 'for free' using a base platform (HTML + JS + DOM) that wasn't designed for it."
Feross Aboukhadijeh, an open-source developer and co-creator of Wormhole, told The Register that word processors have very specific requirements that don't exactly align with the capabilities of the DOM. "It seems the Google Docs team realized this and was able to eke out better performance by dropping to a lower level by using Canvas and perhaps WASM as well," he said.
A website like Google Docs was probably never going to be a simple HTML website that a beginner could 'View Source' on to learn about how it was built
"I'm an advocate for simple websites built with plain HTML, CSS, and JS. There's definitely a trend of new websites being built with complicated technology where simple technology would have sufficed, but a website like Google Docs was probably never going to be a simple HTML website that a beginner could 'View Source' on to learn about how it was built."
Aboukhadijeh described the web as simultaneously a simple document viewer and a powerful application runtime.
These capabilities, he said, entail trade-offs that have implications for performance, accessibility internationalization, right-to-left language support, and browser extension support. "It seems Google weighed the trade-offs and decided that performance was the most important concern," he said. ®
Updated to add
After this story was published, a spokesperson for Grammarly wrote to say that Firtman’s concerns about the extension are misplaced. “Google’s canvas-based rendering on Google Docs will not affect the Grammarly browser extension experience,” the company said.