Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

Post reply on HN
Print view View original

741–750 of 953 posts

Re: Google Docs will now use canvas based rendering

#741

Post by throw_m239339 »

So I'm using Office/OneDrive online and the web versions of Word/Excel. The reason I don't use Google Docs is that I think the UI is inferior to Microsoft solutions. And I'm pretty sure they are DOM based (for the most), In fact some Excel operations even execute a server round trip. Google Docs is nice because of the addon ecosystem that AFAIK doesn't exist with Office 365. But I don't like the editors as they are inferior versions of Word/Excel...

Also why is it so hard to produce or edit PDF files online still today, or fill PDF forms online? Neither Google or Microsoft provide that fuction. And no, I don't want the PDF file to be converted into some Word like file, I want the PDF to keep its layout/fonts...

Re: Google Docs will now use canvas based rendering

#742

Post by jtsiskin »

quickthrower2 wrote: post #561
artificial wrote: post #295

Earlier quoted context omitted.

You’re going to own nothing and be happy.

What do I “own” when I open a site that is a tiny HTML doc and 300kB of minified JS, plus 100 fetch calls for JSON data to render? At that point, use the DOM, use a canvas or a literal paint brush, I don’t care.

Can at least block ads still (mostly…)

Re: Google Docs will now use canvas based rendering

#743

Post by throw_m239339 »

nine_k wrote: post #241

The Web started as a document display and delivery framework. Now it has turned into an application delivery framework, which uses the old document-rendering abilities to display the UI, with many quirks and workarounds, because DOM was never intended as a performant dynamic medium. With canvas and WebGL taking more and more, it will turn back into an X terminal, with more advanced network capabilities. If most impor…

> With canvas and WebGL taking more and more, it will turn back into an X terminal, with more advanced network capabilities.

Not really, Canvas is just that, a blank canvas. The issue is that it's up to the developer to implement everything on top. It's very hard for me to believe that Canvas would be more efficient than DOM for creating text documents. Obviously there are limitations to CSS or the DOM. But then wouldn't SVG be a better alternative than straight out drawing pixels on screen?

Re: Google Docs will now use canvas based rendering

#744

Post by jd3 »

pcwalton wrote: post #719
jd3 wrote: post #669

Earlier quoted context omitted.

It's funny — Google's approach here reminds me of the Netscape/Mozilla XUL tree[0] element. For those unfamiliar, the XUL tree is a performant 1990s-era virtualized list that is able to render millions to tens of millions of rows of content without slowdown since it gives you the option of rendering internally in Firefox rather than through the DOM. I still don't completely understand why Mozilla is/was planning to a…

> I still don't completely understand why Mozilla is/was planning to axe[1][2] it since there's no web-based HTML5/JS replacement (the virtualized "tree" is implemented in C++, iirc) and it's still being actively used in places.{xul/xhtml}[3] and the Thunderbird/SeaMonkey[4][5] products. XUL is a maintenance burden and exacts a development tax on new features (having to make the Servo CSS engine support XUL so that i…

Thanks for the reply! I'm a big fan of your work. I can only imagine the nightmare of trying to implement two separate XUL HTML/CSS flex/box models in Servo/Rust.

For readers that are unaware, there is also a great blog post breaking down some of these points in finer detail [0][1].

I guess my question is — are there replacements planned for any of the legacy yet performant XPCOM interfaces / XUL elements like nsITreeView/tree? My tl;dr understanding of XUL trees is that the DOM is and always has been too slow to render millions of scrollable rows in a performant manner (bookmarks, thunderbird, etc.). Would it not be possible to re-implement the XUL tree logic in Rust, for example? Is the goal to completely get rid of all non-standards compliant elements in the long-run?

It seems like there will always be some custom elements necessary for a native desktop interface which can never be integrated into HTML...

"I’ve talked about this before, but things like panel, browser, the menu elements (menu, menupopup, menucaption, menuitem, menulist) don’t have HTML equivalents and are important for our desktop browser experience. While we could invent a way to do this in chrome HTML, I don’t think the cost/benefit justifies doing that ahead of the rest of the things in our list." [2]

..., yet I don't see much discussion about this anywhere.

I'm particularly interested because I'm currently working on a XULRunner project where a is central to the user interface (millions of rows, image column, embedded data, must run on macOS/Windows/Linux/*BSD, etc.), and it's a little alarming that there is an open bugzilla ticket that did not initially mention either the performance nor ecosystem implications (essentially kill Thunderbird, kill SeaMonkey more than it already has been) of its removal.

I think the one part I have trouble with is that implementing a native looking/performant cross-platform desktop UI is still a nightmare and XUL could have potentially been a fantastic desktop-focused superset/companion of/to HTML.

[0]: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...

[1]: https://news.ycombinator.com/item?id=24231017

[2]: https://briangrinstead.com/blog/xbl-replacement-newsletter-2...

Re: Google Docs will now use canvas based rendering

#745

Post by tshaddox »

DaiPlusPlus wrote: post #151
disease wrote: post #88

Earlier quoted context omitted.

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.

> I imagine using canvas gave them a lot more flexibility in addition to being more performant. I'm perplexed because I don't expect canvas rendering to be faster - or necessarily more flexible - because the web is document-first: HTML and CSS were/are all built-around describing and styling textual content , and computer program source code files are invariably all textual content files. So while browsers all have h…

The web is (or at least was) document-first, yes, but Google Docs is an extremely heavily-featured WYSIWYG word processing and desktop publishing application that happens to be distributed on the web (in addition to other platforms). The fact that you're (sometimes) using Google Docs to generate a simple document that could easily be represented with simple HTML does not imply that Google Docs itself is a natural candidate for being implemented with simple web APIs like DOM.

Now, I think if the contentEditable API were significantly more robust and consistent across browsers, it could have been viable to build extremely complex WYSIWYG editors using the DOM. Most of the popular rich text editor libraries for the web are essentially compatibility layers around the contentEditable API that attempt to normalize its behavior across browsers and present a more robust API to the developer. These libraries are popular and do work pretty well, but based on my experience with them it's no surprise that an app as popular and extensive as Google Docs would constantly bump into the limitation of this approach. (My impression is that Google Docs never used contentEditable and instead wrote their own layout and editing engine that manually rendered out DOM, and they're now changing that to render out to canvas.)

Re: Google Docs will now use canvas based rendering

#746

Post by felixfbecker »

delroth wrote: post #397
pwdisswordfish8 wrote: post #370

Earlier quoted context omitted.

This is a great example of a comment written by a developer or some otherwise technical person who is so used to thinking and speaking in terms of trees that they can't see the forest, let alone the village it's situated next to and the people inhabiting it. Google Docs may be an app, but a big part of the app, and confirmed to be one of the reasons for the migration here, is the part that renders the document to the…

"Displaying documents" and "displaying editable documents" are two completely different beasts. The web browser has never dealt well with displaying editable documents, the closest standard that exists is contentEditable and pretty much everyone agrees that it sucks and is not fit for complex use cases.

Why can't Google work on improving `contenteditable`? It would benefit so many and the problems are well-known. It's probably even used by Google somewhere

Re: Google Docs will now use canvas based rendering

#747

Post by tshaddox »

hctaw wrote: post #43
jhartmann wrote: post #25

Earlier quoted context omitted.

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…

Microsoft Word, Pages and Open Office don't seem to be bottlenecked by rendering performance like Google Docs. Perhaps the browser is the wrong platform for document editing.

This mode of argument seems odd to me. Google is announcing a solution to the problems they were having with the platform. Wouldn't the criticism "Perhaps the browser is the wrong platform for document editing" only be appropriate if Google was complaining that they have been unable to fix the problems?

The fact that, while developing for a given platform, you can encounter problems and fix them, doesn't seem to imply that there's something wrong with your choice of platform.

Re: Google Docs will now use canvas based rendering

#748

Post by pcwalton »

jd3 wrote: post #744
pcwalton wrote: post #719

Earlier quoted context omitted.

> I still don't completely understand why Mozilla is/was planning to axe[1][2] it since there's no web-based HTML5/JS replacement (the virtualized "tree" is implemented in C++, iirc) and it's still being actively used in places.{xul/xhtml}[3] and the Thunderbird/SeaMonkey[4][5] products. XUL is a maintenance burden and exacts a development tax on new features (having to make the Servo CSS engine support XUL so that i…

Thanks for the reply! I'm a big fan of your work. I can only imagine the nightmare of trying to implement two separate XUL HTML/CSS flex/box models in Servo/Rust. For readers that are unaware, there is also a great blog post breaking down some of these points in finer detail [0][1]. I guess my question is — are there replacements planned for any of the legacy yet performant XPCOM interfaces / XUL elements like nsITre…

I mean, you probably won't like this answer, but I don't think you should be writing a XUL-based app in 2021 if you want it to be useful, as opposed to for fun. XUL is 25-year old legacy technology, and using it is an exercise in retrocomputing.

Re: Google Docs will now use canvas based rendering

#749

Post by tshaddox »

BlueTemplar wrote: post #699
hctaw wrote: post #43

Earlier quoted context omitted.

Microsoft Word, Pages and Open Office don't seem to be bottlenecked by rendering performance like Google Docs. Perhaps the browser is the wrong platform for document editing.

The browser is the wrong platform for anything that isn't an HTML document, and not only for performance reasons, but perhaps much more importantly : for interface reasons. For instance : in your typical windowed program, when you press "Alt", it's supposed to show the Menu, which you can then quickly navigate using keyboard shortcuts. You can't do that properly inside the browser because it's going to conflict with…

Based on inspecting the DOM of the read-only preview document they link to, my guess is that they will be using traditional DOM elements for much of the editing UI. There appear to be many empty DOM elements that are there to hold various toolbars and other UI elements. And for what it's worth, there seem to be empty DOM elements intended to be read by screen readers.

Re: Google Docs will now use canvas based rendering

#750

Post by google234123 »

kgwxd wrote: post #140
recursive wrote: post #15

Earlier quoted context omitted.

This is exactly the reason I don't use an ad blocker. In the long run, it will make everything worse, and I still probably won't be able to block ads. I'm clearly on the losing side of this though.

"Ad blockers" need a new name. I don't consider uBlock Origin an "ad blocker". It's a proper user agent (like a browser is supposed to be) that gives the user control over what is allowed to happen on their machine. That just happens to have the side effect of not allowing most ads to render because the way they're typical delivered. It won't matter if everyone starts using canvas unless they also stop using my machi…

They also aren't obligated to serve you free content.
Post reply on HN