11 ms·

Performance of DOM based rendering is very problematic and not unified across browser implementations. Canvas rendering will likely increase the performance of

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 just shoe horned things until they sort of work. I think this is a positive thing, UX will be better and the integration API's will become much cleaner and not depend on structure of how they design the UI. Concerns will be separated and the end result is something much cleaner, more performant, and more supportable.

hctaw 5y ago
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.
- refulgentis 5y ago
  Microsoft Word and Pages both also have web apps, for years, that are 'bottlenecked by rendering performance' (would put it as 'clearly would be improved by better rendering performance', as you're noting)
- silicon2401 5y ago
  I believe this 100%. After using google office for years (just because it's free and cloud-based), I recently tried MS Word and Excel recently at work. The different was mind-blowing. I forgot just how functional and straightforward MS Office is compared to the clunky, barebones google options. If I wanted a desktop-first, cloud-backed solution, what would be the most future-proof and durable? Can I use Open Office across OSes? What would be the best cloud backup service these days? (just a general question to readers)
  - thayne 5y ago
    > Can I use Open Office across OSes? I would recommend Libreoffice over Openoffice, but yes (for both) And you can of course backup to your cloud service of choice. The main benefit of google docs, o365, etc. Is real-time collaboration. But there is no reason why a desktop app couldn't support realtime collaboration with a suitable backend service.
    - richardwhiuk 5y ago
      There are lots of reasons.
      - moshmosh 5y ago
        There must be exactly zero reasons—not lots—why they can't, since some native applications do, in fact, support realtime collaboration.
    - silicon2401 5y ago
      What do you prefer about Libreoffice? I've used both once or twice but not enough to really learn anything about them
      - teddyh 5y ago
        LibreOffice is an actual active project; OpenOffice is a political ghost entity.
        silicon2401 5y ago
        Very good to know, thanks!
    - deckard1 5y ago
      The only time I've ever seen real-time Google Docs collaboration has been during meetings which should have been an email. Total waste of everyone's time. Not to mention the horrible UX of people constantly moving their cursor around and moving text around. I'd suggest that pass-the-baton style collaboration would be a much better UX if you absolutely must collaborate real-time on creating a document. Which I find the premise to be incredibly dubious to begin with.
- larodi 5y ago
  It was indeed a very strong marketing move for... decades to convince people, like smart people, that document editing can be a web-based thing. Actually, now that the browser is so ubiquitous that GUIs sit on top of it (think Electron), then is time to ask the very obvious question - since everyone seems to agree that universal GUI is needed (proof: the browser) then is the browser the right universal GUI? Not being heavily biased by any vendor, but really, is there anything better than XAML to describe user interfaces, that is also cross-platform and does not have the burden of DOM? Please - share examples.
  - josephg 5y ago
    > then is the browser the right universal GUI? Absolutely not; but the web has became the behemoth it is through an absurd amount of money and engineering work. Chrome (well, Chromium) has 34 million lines of code now[1]. If we assume any competing universal GUI platform will need a similar amount of engineering effort, there's a very small list of companies in the world who have the resources to fund an effort like that. And Apple, Microsoft and Facebook have very little strategic incentive to care. (React Native notwithstanding). Google is trying with Flutter - but we'll see. I wonder if maybe the the right direction is up. WASM is already supported by all major browser engines. I'd love to see a lower level layout & rendering API for the browser, exposed to wasm. We could do to the DOM what Vulcan did to OpenGL. And like opengl, if it was designed right, you should be able to reimplement the DOM on top in (native wasm) library code. Then the universal GUI of the future could be the gutted out shell of a web browser (we'd just need wasm + the low level layout engine), running libraries for whatever UI framework you want to use, written in any language you like. A UI environment like that would be small, portable and fast. [1] https://www.openhub.net/p/chrome/analyses/latest/languages_summary https://www.openhub.net/p/chrome/analyses/latest/languages_s...
    - PoignardAzur 5y ago
      I really like that scenario, but I don't think market forces are moving towards it. Then again, we got wasm, and that feels like a miracle in itself.
- tomjen3 5y ago
  Google docs is worth it for the coorporation, but if you are writting for yourself, or anything seriously it is simply not good enough, but I don't think the performance is the issue.
- BlueTemplar 5y ago
  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 the browser's own Alt-Menu.
  - tshaddox 5y ago
    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.
- tshaddox 5y ago
  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.
disease 5y ago
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.
- disease 5y ago
  Here's an article that talks about the switch to canvas for VS Code. The "5 to 45" times faster part really sticks out to me. Kind of surprised it took Google this long to do this with Docs. https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
  - shadowgovt 5y ago
    > Kind of surprised I'd assume a significant cost-benefit tradeoff. For all its flaws, the DOM rendering algorithm is at least "document-like," so there's a lot of wheel-reinventing to do going from just using the DOM to a custom document layout implementation underpinning a canvas-targeted rendering algorithm.
    - woah 5y ago
      Look at the Google docs generated html markup some time. It’s not making nice neat <p>’s and <h1>’s.
      - kaliszad 5y ago
        Yes, at OrgPad, we are writing our own rich text editor and if you want to use the DOM approach, you don't have much choice than to do it like this. You can see the WIP demo here (in Czech but it is quite visual): https://www.youtube.com/watch?v=SkFJ1zcRjQY https://www.youtube.com/watch?v=SkFJ1zcRjQY It is also written in ClojureScript. Some of the reasoning is here (in English, but 3 hours long): https://www.youtube.com/watch?v=4UoIfeb31UU https://www.youtube.com/watch?v=4UoIfeb31UU
mattwad 5y ago
I hope so. Just one example, but when you use the API to export HTML, nested lists aren't actually nested.. they just inject increasing padding on subsequent LI tags. This is ridiculous and causes big issues for me, but I'm sure they had to do it for formatting purposes. So hopefully they can give us semantic HTML now that it's not coupled to the editor.
suyash 5y ago
I get performance but for text based content, is canvas the best medium to render it?
gherkinnn 5y ago
Flutter uses renders everything on Canvas and performance and usability are terrible. Not even scrolling works properly. So no, I doubt it’s inherently cleaner.
vaughan 5y ago
The canvas actually seems less performant when I compared it now. Scrolling is not as smooth. Click `Save as copy` and try it out.

hctaw 5y ago

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.

refulgentis 5y ago
Microsoft Word and Pages both also have web apps, for years, that are 'bottlenecked by rendering performance' (would put it as 'clearly would be improved by better rendering performance', as you're noting)
silicon2401 5y ago
I believe this 100%. After using google office for years (just because it's free and cloud-based), I recently tried MS Word and Excel recently at work. The different was mind-blowing. I forgot just how functional and straightforward MS Office is compared to the clunky, barebones google options. If I wanted a desktop-first, cloud-backed solution, what would be the most future-proof and durable? Can I use Open Office across OSes? What would be the best cloud backup service these days? (just a general question to readers)
- thayne 5y ago
  > Can I use Open Office across OSes? I would recommend Libreoffice over Openoffice, but yes (for both) And you can of course backup to your cloud service of choice. The main benefit of google docs, o365, etc. Is real-time collaboration. But there is no reason why a desktop app couldn't support realtime collaboration with a suitable backend service.
  - richardwhiuk 5y ago
    There are lots of reasons.
    - moshmosh 5y ago
      There must be exactly zero reasons—not lots—why they can't, since some native applications do, in fact, support realtime collaboration.
  - silicon2401 5y ago
    What do you prefer about Libreoffice? I've used both once or twice but not enough to really learn anything about them
    - teddyh 5y ago
      LibreOffice is an actual active project; OpenOffice is a political ghost entity.
      - silicon2401 5y ago
        Very good to know, thanks!
  - deckard1 5y ago
    The only time I've ever seen real-time Google Docs collaboration has been during meetings which should have been an email. Total waste of everyone's time. Not to mention the horrible UX of people constantly moving their cursor around and moving text around. I'd suggest that pass-the-baton style collaboration would be a much better UX if you absolutely must collaborate real-time on creating a document. Which I find the premise to be incredibly dubious to begin with.
larodi 5y ago
It was indeed a very strong marketing move for... decades to convince people, like smart people, that document editing can be a web-based thing. Actually, now that the browser is so ubiquitous that GUIs sit on top of it (think Electron), then is time to ask the very obvious question - since everyone seems to agree that universal GUI is needed (proof: the browser) then is the browser the right universal GUI? Not being heavily biased by any vendor, but really, is there anything better than XAML to describe user interfaces, that is also cross-platform and does not have the burden of DOM? Please - share examples.
- josephg 5y ago
  > then is the browser the right universal GUI? Absolutely not; but the web has became the behemoth it is through an absurd amount of money and engineering work. Chrome (well, Chromium) has 34 million lines of code now[1]. If we assume any competing universal GUI platform will need a similar amount of engineering effort, there's a very small list of companies in the world who have the resources to fund an effort like that. And Apple, Microsoft and Facebook have very little strategic incentive to care. (React Native notwithstanding). Google is trying with Flutter - but we'll see. I wonder if maybe the the right direction is up. WASM is already supported by all major browser engines. I'd love to see a lower level layout & rendering API for the browser, exposed to wasm. We could do to the DOM what Vulcan did to OpenGL. And like opengl, if it was designed right, you should be able to reimplement the DOM on top in (native wasm) library code. Then the universal GUI of the future could be the gutted out shell of a web browser (we'd just need wasm + the low level layout engine), running libraries for whatever UI framework you want to use, written in any language you like. A UI environment like that would be small, portable and fast. [1] https://www.openhub.net/p/chrome/analyses/latest/languages_summary https://www.openhub.net/p/chrome/analyses/latest/languages_s...
  - PoignardAzur 5y ago
    I really like that scenario, but I don't think market forces are moving towards it. Then again, we got wasm, and that feels like a miracle in itself.
tomjen3 5y ago
Google docs is worth it for the coorporation, but if you are writting for yourself, or anything seriously it is simply not good enough, but I don't think the performance is the issue.
BlueTemplar 5y ago
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 the browser's own Alt-Menu.
- tshaddox 5y ago
  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.
tshaddox 5y ago
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.

disease 5y ago

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.

disease 5y ago
Here's an article that talks about the switch to canvas for VS Code. The "5 to 45" times faster part really sticks out to me. Kind of surprised it took Google this long to do this with Docs. https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
- shadowgovt 5y ago
  > Kind of surprised I'd assume a significant cost-benefit tradeoff. For all its flaws, the DOM rendering algorithm is at least "document-like," so there's a lot of wheel-reinventing to do going from just using the DOM to a custom document layout implementation underpinning a canvas-targeted rendering algorithm.
  - woah 5y ago
    Look at the Google docs generated html markup some time. It’s not making nice neat <p>’s and <h1>’s.
    - kaliszad 5y ago
      Yes, at OrgPad, we are writing our own rich text editor and if you want to use the DOM approach, you don't have much choice than to do it like this. You can see the WIP demo here (in Czech but it is quite visual): https://www.youtube.com/watch?v=SkFJ1zcRjQY https://www.youtube.com/watch?v=SkFJ1zcRjQY It is also written in ClojureScript. Some of the reasoning is here (in English, but 3 hours long): https://www.youtube.com/watch?v=4UoIfeb31UU https://www.youtube.com/watch?v=4UoIfeb31UU

mattwad 5y ago

I hope so. Just one example, but when you use the API to export HTML, nested lists aren't actually nested.. they just inject increasing padding on subsequent LI tags. This is ridiculous and causes big issues for me, but I'm sure they had to do it for formatting purposes. So hopefully they can give us semantic HTML now that it's not coupled to the editor.

suyash 5y ago

I get performance but for text based content, is canvas the best medium to render it?

gherkinnn 5y ago

Flutter uses renders everything on Canvas and performance and usability are terrible. Not even scrolling works properly. So no, I doubt it’s inherently cleaner.

vaughan 5y ago

The canvas actually seems less performant when I compared it now. Scrolling is not as smooth. Click `Save as copy` and try it out.