Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

81–90 of 953 posts

Re: Google Docs will now use canvas based rendering

#81
post #59
post #53

How would they implement things like copy-to-clipboard then?

I don't know but Figma do it without issues, maybe there are some hidden inputs behind the canvas that are selected

Wouldn't that cause security issues which should be blocked by browsers?

I.e. on some malicious website you could select some innocent looking text, but under the covers it selects some evil bash command.

Re: Google Docs will now use canvas based rendering

#82

The dom is really, really fast, we have spent decades refining the process and there is deep tooling to support it built right into the browser. What a bunch of nonsense.

The DOM is abysmally slow for everything except one use case: displaying a simple text page with a couple of images.

The core of the web is designed to display that on a 1990s computer in a single rendering pass. Everything bolted on top adds layers of complexity and indirection resulting in a laughably slow and inefficient system.

The web can't even reliably animate an item in a list for laughing out loud.

Re: Google Docs will now use canvas based rendering

#83

RIP web accessibility when everyone starts doing this to make ad blocking more difficult

Absolutely. All it's going to take is somebody porting a browser to WASM. They just need to "tunnel" accessibility concerns to the "outer browser" until all of that can be completely implemented within the "inner browser".

Re: Google Docs will now use canvas based rendering

#86
(googler, opinions are my own. I know nothing about this project).

I really hope this fixes the large-document problem. As someone that has to deal with large specs (1000+ page MS Word documents), Google Docs does a not-so-great job of handling them. I also understand this is why many writers don't like Google Docs to write the entire book in, as things start slowing down when you get into the hundreds-of-pages. I don't know if this is a javascript limit issue or a rendering issue, but if it's rendering, Canvas should hopefully help.

Re: Google Docs will now use canvas based rendering

#87

Earlier quoted context omitted.

Their own renderer has to support all of HTML and CSS. Slapping some rectangles on a raster surface has a lot less to worry about.

"Slapping some rectangles on a raster surface" can also be done in HTML/CSS, with the right options (set 'overflow' content to be clipped with no reflow).

No, it can't be done in HTML+CSS in a performant way.

Re: Google Docs will now use canvas based rendering

#88

I don't build extensions or work on much front end web lately but this reads like Google wants more control over their stuff. The web is becoming less open. > 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. > If you are building your own integrations with Google Docs, we recommend using Google Work…

Performance of DOM based rendering is very problematic and not unified across browser implementations. Canvas rendering will likely increase the performance of Google Docs, and make the UX more unified across platforms. Google Docs is really an application built on the web platform. HTML DOM rendering was never intended to give developers the control they need to build fully featured high performant applications, we…

I think this is the real reason for the change as well. A few years ago Visual Studio Code underwent a similar change where rendering the terminal moved from using DOM to canvas. I never noticed a huge difference between the two methods but I imagine using canvas gave them a lot more flexibility in addition to being more performant.

Re: Google Docs will now use canvas based rendering

#89

Earlier quoted context omitted.

React (not just React, but they "meme"'d it) sold everyone on the DOM being slow. What they actually meant was that if you add & remove 5,000 elements one at a time in a loop, it's slow. If you don't do that it's plenty fast and all of React's tricks to "make it fast" are just overhead that are bloating and slowing down your "app". (FWIW, I actually kind of like writing React, if I must do front-end JS, so I'm not ha…

> What they actually meant was that if you add & remove 5,000 elements one at a time in a loop, it's slow. Ok, but it's not trivial to build complex web-based applications that don't do exactly that. This is why there are so many frameworks out there that take care of that problem for you. React isn't the only one. Angular, Vue, and Svelte also handle this for the developer, using various different approaches. It's n…

I would agree that companies have mostly settled on paying 20% as much for development, at the cost of 5-10x the memory footprint and 5-10x the input latency in the finished program. I think the web tends to get hit the hardest by that because if a company is targeting the web for an "app" in the first place, they've already chosen cost savings over performance and UX, so they'll be prone to make even more trade-offs for the same reason within the web platform.
Post reply on HN