14 ms·

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. >

• tantalor 5y ago
  The article says the reasons are, > to improve performance and improve consistency
  • deleted 5y ago
    [deleted]
• cj 5y ago
  > I'd like to know if there are reasons to move to canvas for strictly technical merits. In Google's announcements, they say the reason is performance.
  • austincheney 5y ago
    That seems like a moderately weak argument. DOM tables are slow, but if you know what you are doing the DOM is otherwise an insanely fast interface. You can get sub-nanosecond response speed from DOM calls in Firefox (faster than a billion operations per second). It would be interesting to see the performance differences in numbers. The performance impact of a canvas based approach can be approximated from measuring the performance of heavy SVG animations on GPU load.
    • dmitriid 5y ago
      Raw calls to DOM mean literally nothing when you have to layout those nodes. And yes, tables are slow. "If you know what you're doing" routinely becomes "let's reinvent virtual lists on an interface that doesn't have a single API to make this pleasant or performant in any conceivable way".
• harikb 5y ago
  The part I don’t understand is how in the world is a renderer written in JavaScript better performing than their own Chrome c++ code? With Edge being a Chrome clone and Safari being also performant browser, what are they worried about?
  • recursive 5y ago
    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.
    • zozbot234 5y ago
      "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).
      • dmitriid 5y ago
        No, it can't be done in HTML+CSS in a performant way.
        • strogonoff 5y ago
          VS Code feels performant enough, with its complex functionality IMO exceeding Google Docs, and yet I don't think it is using canvas. I believe it comes down to strategic design that avoids unnecessary layout and reflow events in the UI. That said, the UI of VS Code (the desktop app) only needs to run in Chromium. And generally Google Docs could be a different enough beast that it can’t take advantage of the same tricks—hard to say from the outside.
          • d-yakovlev 5y ago
            some of VS Code has been canvas-based since 2017 - https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
• LorenzA 5y ago
  in general a lot of dom-nodes can reduce performance and with canvas you have much more control over what and how things get rendered. I would assume this is also nothing new or "special" afaik google spreadsheets is using canvas for years under the hood with some dom for nicer ux
  • zozbot234 5y ago
    "A lot of dom nodes" is not inherently problematic if you do not insist on twiddling them individually in a JS for-loop. Other than that, it's just HTML - and plain HTML/CSS rendering is blazing fast.
• jhartmann 5y ago
  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.
• justapassenger 5y ago
  > For those more deep in web technology, I'd like to know if there are reasons to move to canvas for strictly technical merits. We’ll see the results, but let’s be honest - web is bad fit for apps. It was never designed for it, and has tons of hacks and layers to make it possible, that makes them messy and slow.
• jerry1979 5y ago
  I would not consider myself super deep in web technology, but rendering to canvas allows programmers to have pixel perfect control over the look of their applications across all devices. Currently, web developers need to "reset" lots of default rendering behaviors in every major browser to ensure that their applications look the same. After building lots of specialized UI components within the HTML standard, a programmer may ask themself if they might as well write their own UI library. Specifically, lots of specialized applications have UI components which do not have a corresponding HTML standard. For example, in a spreadsheet, a cell may have a clickable triangle in its upper right corner that should display a comment bubble. Should a programmer create that in css or write a specialized library?
  • remram 5y ago
    Do your users care about your app looking the same or do they care about their browser looking and acting like a browser? Moving to canvas is sure to break many features such as text selection, adblocking, and accessibility. All in the name of more controls over the pixels? Are you truly doing it for the users?
    • kroltan 5y ago
      Very good point, users do not care that a padding is rounded up or down when they switch from their laptop to their desktop, as long as the application is usable, understandable and visually competent. But mindspace is much more important for interaction, so if their laptop is a Mac, their brain will be in "Mac mode", and "Linux" or "Windows" mode when on their other device. Respecting the platform's conventions will allow them to keep their cognitive load due to "fiddling" to a minimum.
      • remram 5y ago
        I don't think the GP was talking about the app looking consistent with the rest of the platform, but the exact opposite: the app looking the same whatever the platform. Using Flutter allows them to have the app look the same on the browser as on mobile. This means that at best it will look "Mac mode" for everyone, including Windows users; at worst it will look foreign to everyone.
• sixothree 5y ago
  I have a running theory - Google doesn't create a product unless it captures data in a unique manner compared to their other products. Maybe they have moved past this phase. Maybe I just don't see the collection happening here.
  • ocdtrekkie 5y ago
    Docs value prospect isn't really consumer use at all: It's businesses and (mostly) schools, paying for G Suite licensing.
• thayne 5y ago
  > For those more deep in web technology, I'd like to know if there are reasons to move to canvas for strictly technical merits. Performance. My company switched from dom to canvas (and then to webgl) for a document-centric app a long time ago because of performance reasons. drawing to a canvas is much faster than updating dom. Also better control over how it displays. With dom you have to worry about differences in how differeny browsers render the same dom a loy more. Although that is less of an issue than it used to be. There are downsides too though. Besides making it much more difficult for extensions to modify things, you also have to build your own spell check, because there isn't a browser API for that. However, I think google docs was already using google's own spellchecker.
• MereInterest 5y ago
  > this reads like Google wants more control over their stuff. The web is becoming less open. Absolutely agreed. I'd also be surprised if they don't try to roll out the same for search results, ostensibly for the purpose of improving performance, but actually to thwart ad-blockers.
  • moshmosh 5y ago
    The only thing that's kept everyone from doing that, so far, is accessibility. If not for that all the major ad platform companies (FB, Twitter, Google, and so on) would be already be all-in on Canvas. Accessibility concerns make it both expensive to develop a UI that renders to canvas, and ensures that the content can be processed & understood by a program (else how will assistive tools read it?), which opens up the door to ad blockers again, defeating the purpose of the whole exercise. We literally have blind people to thank for the Web remaining as open as it has, for this long.
    • alisonkisk 5y ago
      Do you have any evidence for this idea?
      • moshmosh 5y ago
        Only that it's a really obvious move for them, for a few reasons (including that making it the norm for stopping ad blockers and trackers forces all their would-be competitors to play catch-up on basic taken-for-granted stuff like displaying text on a screen) and accessibility is the only thing I'm aware of that attacks both the difficulty of the project and the feasibility of the desired outcome, sufficiently to explain why they've not at least given it a shot.
• blacktriangle 5y ago
  It's not about the web being more or less open, it's about the browser playing the role of a distributed application run time. I'd argue that Google Docs is basically not a part of the web, it just incidentally happens to run in the same browser as the web does for logistic reasons.
  • sime2009 5y ago
    Web apps have been around for well over a decade but some people are still struggling with the idea that a web browser can display hypertext documents and also run applications, plus a whole universe of hybrid things which lie in between these two extremes. Not everything a browser displays has to fit in the "page" paradigm.
    • deckard1 5y ago
      Web 2.0 enabling web apps was always a myth. There have been web "apps" since the 1990s with CGI. XMLHttpRequest merely allowed for the moving of some of that logic to the client side. In that respect, we've been working around the "page" paradigm since the web was practically born. It was a flawed analogy because, even back then, screen sizes and display tech varied among users. Designers still approach web design as if they are designing for print. I've always maintained that if the web were based on a vector technology (think PostScript, but obviously not PostScript) we would be in a much better place both design-wise and accessibility-wise. Content would flow in a much more controlled manner with much less room for browser interpretation and second-guessing. But people were still clinging on to the write once run anywhere (ahem, Java) naivety of the day. And likewise they really thought that you could divorce presentation from semantics and... have something that just worked? I guess? Just sprinkle on some afterthought CSS tech crap and no one will ever notice that the entire thing is flawed at a fundamental level.
• shadowgovt 5y ago
  > technical merits The DOM gives a developer very little control over when something should be repainted (or how repainting occurs) relative to the compositing options available when controlling one's own canvas. Moving the rendering engine to canvas allows the docs team more control over the optimizations of layout and rendering they can do (especially cross-platform; there are a hundred hundred mutually-incompatible bugs and quirks in Firefox, Chrome, IE, etc.'s layout and content rendering algorithms that make cross-platform high-performance very hard to guarantee at the DOM layer of abstraction).
• sime2009 5y ago
  > This is basically putting an API on top of an API as far as I'm concerned. Exposing a raw on-screen DOM tree as part of your API for extensions/plugins to use is terribly fragile and generally a bad idea.
• dgudkov 5y ago
  >Google wants more control over their stuff. The web is becoming less open. That's because the old problem "web-document vs web-application" hasn't been solved properly. HTML was designed for documents. It wasn't designed for applications. No wonder as applications become more sophisticated they try to squeeze out HTML/DOM where possible.
  • seumars 5y ago
    The irony being that Docs is a web document editor
    • mort96 5y ago
      And a document editor usually has a very different feature set from a document viewer.
• riho 5y ago
  In this case, I think the switch is most likely entirely based on technical merits, rather than some way of asserting more control. So with that in mind, the fact that the team behind one of Google's most interactive pieces of software has to throw up their hands and say "DOM is too slow, we gotta roll our own" should be a wakeup call for everyone working on Chrome and other browsers, but mostly for Google itself. When you escape the DOM, you're going to be doing pretty much everything yourself. And for someone like Google, that might be worth the absolutely insane amount of effort, but what about everyone else? You're Google, Chrome has 60%+ market share. Why isn't the plan here to systematically start improving DOM performance, or create APIs to more directly modify how elements are laid out and created? Why do all of this work to benefit only Google Docs? We've had years (decades!) of articles and talk about how the DOM is slow (including a bunch from Google), so why not improve it? Why give up and waste all this time on a custom solution? Why not create something that is *actually* capable of handling the complexity of modern, highly interactive applications, including Google's own products? You can say it's Flutter, but that's yet another effort to escape the DOM, rather than actually improve it. Maybe this has been the plan behind the Google Docs team, to push people on the browser side and other Google teams to start seriously looking at what to do with the DOM, if so, I hope this actually has the intended effect. We all deserve a better, more performant web.
  • themacguffinman 5y ago
    DOM performance has already improved leaps and bounds after millions of dollars of engineering and countless hours of effort. Same with Javascript. At some point you have to accept that the DOM has fundamental design flaws, its specification and requirements are the problem yet cannot be radically changed because of backward compatibility concerns. Browsers have spent decades optimizing everything possible, one should start by acknowledging that before tiredly trotting out magical performance improvements as the answer.
  • netheril96 5y ago
    > Why isn't the plan here to systematically start improving DOM performance, There are already many steps taken to improve DOM performance over these years. However, DOM is designed for documents. The performance can never be good enough when it is abused for non-document usage. > or create APIs to more directly modify how elements are laid out and created? Why do all of this work to benefit only Google Docs? Because other browser engines are unlikely to adopt these APIs just so that Google Docs can have better performance. Not to mention that these new APIs will take years to be present in every user's devices.
• dahart 5y ago
  > The web is becoming less open. Canvas and WebGL are both open standards, no? There are a million and one examples of losing openness, but I think this isn’t one of them.
  • mort96 5y ago
    I bet it's a feeling of, "I used to be able to right click -> view source on any web page and see source code I could understand and learn from. I can't do that anymore, which makes it less open." Which has some truth to it, but it applies almost equally to the current HTML-rendered Google Docs I'd bet.
• SebastianKra 5y ago
  I did a small project where I drew a large animated graph with SVG. Despite careful optimization, it ran at a mediocre frame rate and kept spinning up my fans. I know about another project (whiteboard with notes) that ran into the same issues. PowerPoint, Miro and Figma all run in the Canvas. I don't blame Google for doing the same.
• jakemal 5y ago
  It is not unreasonable to request that devs building on top of your platform use an API. They also aren't requiring it, they are simply suggesting it to avoid future breakages when they change the internals of how their application works. Requiring that they maintain this compatibility would be like requiring the maintainer of an OS library to maintain the contract of a private method because my app relies on grepping their code base to parse the contents of the method. When you don't have a defined set of public interactions with your app, every change is a breaking change.
• ehsankia 5y ago
  Did you feel the same when Maps went from HTML to Canvas? There is no factual basis for your claims. The simplest and most obvious answer is performance. Docs these days can take 5-10s to fully open, especially with comments and annotations.
  • notyourwork 5y ago
    No factual basis? Moving from DOM produced content to canvas produced content closes off your ability as a user to see what is happening. As for Google Maps, it is not speedy or snappy by any stretch of the imagination. In fact, it is pretty abysmal in terms of page performance on the web.
  • SilverRed 5y ago
    I think the panic over this is a little unfounded. For docs this makes perfect sense. My concern I guess is if this becomes the normal way of doing development, and people build HTML replacements that work using canvas. What will the impacts be. * How many browser functions will break. * Will middle click still work. * Will screen readers still work? * Will search engines/ctrl+f still work? One of the awesome things about web browsers is you get so many features for free on every website. Making the text bigger on a website mostly just works everywhere while on traditional apps it only does if the app has a specific setting for it.
    • ehsankia 5y ago
      I don't think it'll become the normal way. If anything, the opposite is true, people making Electron apps to get to access the power of web development, instead of making native apps. It's definitely not easy, it requires you to re-implement everything from scratch. It only makes sense in cases where performance is paramount. I could imagine applications being migrated to the web doing it though, like Photoshop an the like. But I absolutely don't see normal web development migrating over, it's just way too much pain for little value. Development, debugging, testing, etc. Everything becomes much harder.
      • SilverRed 5y ago
• greggman3 5y ago
  I worry about the same thing, but in Google's defense, docs is a wysiwyg document editor, not a webpage for displaying info. It's meant to help users create and edit documents. It has different needs than HTML.
  • greggman3 5y ago
    replying to myself though haha. I use rikaikun, an extension to add popup translations to Japanese words. It obviously won't work on google docs drawn in canvas which sucks if someone posts a link to a google docs doc. It will also suck for support for brail etc... Maybe they'll need a "fallback to HTML" button I also wonder how they'll support CKJ IMEs. Generally when sites try to do their own input the languages that need an IME get 2nd class support. You can see an example but looking at the Qt WASM examples which draw the entire app in canvas using WebGL. They don't support anything but English https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly