72 ms·

Google Docs will now use canvas based rendering

• smitop 5y ago
  This might be a way to make Google Doc's feature that allows copy/paste to be disabled (https://workspaceupdates.googleblog.com/2015/07/disable-downloading-printing-and.html https://workspaceupdates.googleblog.com/2015/07/disable-down...) to be more secure.
  • cute_boi 5y ago
    but it is false sense of security as any one can screenshot it and use ocr to generate text again?
    • throwaway3699 5y ago
      If a worker circumvents these options being disabled, that's a far worse issue. While before you can say "oh I didn't know", afterwards you can just be fired.
    • earthboundkid 5y ago
      Or just intercept the API calls by looking at the network activity tab.
• notyourwork 5y ago
  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 Workspace Add-ons framework, which uses the supported Workspace APIs and integration points. This will help ensure there will be less work in the future to support periodic UI implementation changes to Docs. This is basically putting an API on top of an API as far as I'm concerned. The web renders markup and executes javascript to produce experience. Putting an API on top and using canvas to render your content creates a more closed system. For those more deep in web technology, I'd like to know if there are reasons to move to canvas for strictly technical merits.
  • 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?
• jerry1979 5y ago
  I would like to know which ui library they use.
  • defrex 5y ago
    Perhaps Flutter. It uses Canvas to render in the web. https://flutter.dev/ https://flutter.dev/
    • sgt 5y ago
      Flutter web can use both DOM and Canvas, but the default is Canvas. I haven't to this day seen any disadvantages of using Canvas though, possibly speed on slow mobile devices.
  • mekkkkkk 5y ago
    I want to say that Flutter would be a good candidate, but I don't think it's ready for this. Or is it?
    • gardaani 5y ago
      Isn't Flutter intended exactly for this use case? If Google Docs won't use Flutter then I'd say Flutter has failed badly.
      • mekkkkkk 5y ago
        I'm a Flutter dev and last time I checked out the web target it resulted in massive bundle sizes and bad performance. This was a couple of months or so ago, but still after their "official" 2.0 release which took web from beta feature to stable. EDIT: Removed hyperbole: performance was bad, but not unusable
      • pjmlp 5y ago
        I guess Flutter matters mostly to Ad Words team, as they rescued Dart from falling appart. It remains to be seen how much long lasting love it is having across the Googleplex.
• ZuLuuuuuu 5y ago
  Maybe because I am out of loop with web development, but this sounds like a huge change to me. So instead of HTML elements, there will be just one big <canvas> element, and everything will be rendered there? How will text selection work for example? Will Google Docs basically implement a GUI library like GTK, which renders everything itself, but for the web?
  • abraxas 5y ago
    I think they already have with Flutter
    • riffraff 5y ago
      yeah flutter's "web" target has a whole UI framework built inside the <canvas> tag
      • spuz 5y ago
        Specifically Flutter 2 which was announced recently and introduces the "web" target and is based on <canvas>.
    • rektide 5y ago
      This tech is called CanvasKit, and it scares the shit out of me. Google has, in this case, carefully written a proprietary custom API to take the role of Web Extensions (albeit with far more controls/restrictions/less flexibility) for Docs, but as more and more web properties switch to using Flutter with CanvasKit, we'll see less and less of the web be hypertext, less of the web be scrapeable, less of the web have good accessibility, less of the web be able to use extensions. To me, pushing pixels in people's faces is not the web. The web implies hypertext, the web implies user-agents that fulfill the user's desired agencies. Developers switching to Canvas obstructs everything good, unique, & empowering about the web, converts it to the same terrible awful anti-user mess that everything else in tech is.
      • munificent 5y ago
• wlesieutre 5y ago
  RIP web accessibility when everyone starts doing this to make ad blocking more difficult
  • recursive 5y ago
    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.
    • kgwxd 5y ago
      "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 machine to fetch random third-party content, which they won't, because the "ad" industry is now really the "tracking" industry. The very few times I've seen ads over the last decade or so, they were standard images hosted directly by the site. That's all ads should be. The contract between the site and advertiser should be their problem, my machine isn't obligated to be their mediator.
      • recursive 5y ago
        I like this take a lot. The problem is that most people that are using ad blockers actually seem to want ad blockers.
      • google234123 5y ago
        They also aren't obligated to serve you free content.
        • kgwxd 5y ago
          No one said they are.
• KhalPanda 5y ago
  If they're going to make the leap of switching the render layer, I'm surprised the leap isn't to flutter (which is supposedly stable/ready for production web apps?).
  • defrex 5y ago
    Flutter is Canvas-based on the web, so this post well-could mean a switch to Flutter. Hard to see how non-Flutter customer Canvas-renderer for Google Docs makes sense.
  • sime2009 5y ago
    Flutter is for doing UIs. Google are using canvas to render the (text) document the user is working on, not the UI elements.
• austincheney 5y ago
  How will they achieve accessibility? I can only imagine screen readers trying to parse a bunch of vectors.
  • zdragnar 5y ago
    You can render elements inside of the canvas tag, they simply won't be visible. This gives screen readers something to do, though it becomes trickier since they also have to bugger keyboard shortcuts to implement key navigation for sighted users.
  • jerry1979 5y ago
    The programmers will need to add accessibility features to their apps: https://html.spec.whatwg.org/multipage/canvas.html#best-practices https://html.spec.whatwg.org/multipage/canvas.html#best-prac...
    • austincheney 5y ago
      This is a huge amount of work, and authors are most strongly encouraged to avoid doing any of it by instead using the input element, the textarea element, or the contenteditable attribute. When the spec warns you in advance that this is a high risk approach.
      • quotemstr 5y ago
        High work != high risk
• easton 5y ago
  Example doc: https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
  • jpeter 5y ago
    Even has fake text search. Not bad.
    • neurostimulant 5y ago
      Browser's built-in search feature (e.g. "find in this page..." on firefox) doesn't work though.
      • bhl 5y ago
        Given for a text editor, find-and-replace is a feature anyways that's not natively supported by contenteditable.., you will need to build out a custom app search feature anyways. But yeah, for preview only mode, sad to see native features not work on a static document.
• neals 5y ago
  I believe this is an example output? https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview# https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
  • neurostimulant 5y ago
    Interesting. Looks like each page is a separate canvas, and the canvas are reused as you scroll the pages (just like how list view reuse cells when you scroll in a mobile app). The canvas seem to be only used for rendering text and tables though, images and graphic elements are still drawn as svg dom elements.
• stuaxo 5y ago
  No easy extraction of the data then.
• lewisjoe 5y ago
  We are working on a full-featured Google Docs alternative - https://writer.zoho.com https://writer.zoho.com . We are already capitalizing canvas technology for rendering documents across devices, except for the Web which still is DOM. Having a single codebase that renders across all platforms is our long-term motive, and it does require rendering to a cross-platform canvas backend - like Skia. I'm assuming Google Docs is already on that direction as well. Would be great if someone from Google can clarify the technical internals.
  • cphoover 5y ago
    I love zoho's suite of free tools. When I first got started in web development business 10+ years ago, I used their invoicing tool, and thought it was perfect for a freelancer like I was at the time.
    • coffeefamine 5y ago
      As a small business owner, I found refrens.com extremely useful for invoicing.
  • Andrew_nenakhov 5y ago
    Does Zoho have a self-hosted version? If not, is there any reason to trade one vendor lock for another?
    • heipei 5y ago
      I consider neither Zoho nor Google Docs to be vendor lock-in since you can always download the documents as docx and continue working on them locally. I'm gonna give Zoho Writer a spin since Google Docs is missing some vital features for me, most notably the option to have custom page designs (font/colors/footers) that you can centrally update and apply to a bunch of documents. If anyone has another Google Docs alternative, I'm all ears.
      • Andrew_nenakhov 5y ago
• ericls 5y ago
  Are they going to duplicate all the logic to handle all the keyboard events, mouse events, composition events? Wow
  • vjeux 5y ago
    They unfortunately already do. The state of contentEditable on the web is such that you need to if you want to have a non standard experience like google docs.
• altcognito 5y ago
  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.
  • jcelerier 5y ago
    > The dom is really, really fast, no, it is barely tolerable. Web apps in 2021 have trouble reaching the UI performance (latency) of early 2000 desktop software.
    • deleted 5y ago
      [deleted]
    • Red_Leaves_Flyy 5y ago
      Is that the fault of the web apps programmers (or their library/design choices!) or the engine?
      • shadowgovt 5y ago
        A little bit of both. The DOM enforces a specific model of presentation focused on a structural, hierarchical, declarative description with layout including an automated vertical bias. Great if I want to layout something "document-shaped," a colossally bad match to the problem domain if I just want to draw a pentagon and animate it around the screen. The libraries exist to mitigate the huge problem-domain gap between the DOM model and other models.
    • minusf 5y ago
      quite a blanket statement both for web and desktop apps... some are fast some are slow on both platforms, no?
      • jcelerier 5y ago
        the immense majority of my experience on the web is slow, and on the non-web is fast, it's definitely not 50/50. I wouldn't be able to give you the name of a slow desktop app I use actually.
• pictur 5y ago
  https://github.com/myliang/x-spreadsheet https://github.com/myliang/x-spreadsheet
  • pictur 5y ago
    I don't understand why stupid people downvote my comment. I just posted a link. Why are you so dumb?
    • dang 5y ago
      Your link was fine, and has since been upvoted (see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corrective%20upvote https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...), but a comment like this one breaks the site guidelines. Would you mind reviewing them? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Edit: could you please stop posting unsubstantive comments generally? Your account has been doing a lot of that, and we're hoping for a little higher quality of discussion here.
      • pictur 5y ago
        You can delete my account. I do not want to be on this site any longer. There can be no quality in an environment with moderators like you.
      • pictur 5y ago
        I was going to write at length how bad a moderator you are, but I don't think you are capable of understanding it. I just feel sorry for you. You can be a better moderator. this is not your potential. let's delete my account and relax.
• rlili 5y ago
  So Dark Reader won't work anymore. Great.
• amelius 5y ago
  How would they implement things like copy-to-clipboard then?
  • dezmou 5y ago
    I don't know but Figma do it without issues, maybe there are some hidden inputs behind the canvas that are selected
    • amelius 5y ago
      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.
      • remram 5y ago
        This is already possible with tiny or invisible text, I don't think browsers are trying to protect from that. The protections that exist are to prevent sites from reading your clipboard or replacing it without you clicking on anything, other than that the site already has control over what goes in it.
  • city41 5y ago
    They already have, the sample document has copy implemented.
  • sime2009 5y ago
    Web browsers have APIs for things like the clipboard these days.
    • tmalsburg2 5y ago
      Which makes you wonder why it doesn't work in Firefox (where it='copy & paste in Google docs').
  • andrewingram 5y ago
• larodi 5y ago
  This is absolutely expected, reasonable and the way to go for an rich GUI app such as Google DOX. Particularly since WASM is so widely adopted, so does Canvas, WebGL etc... and Rust compiles to WASM, not to forget. So it was about time that some major apps ditched all the DOM glory. Wonder whether they're using the greatly overrated Angular to render the canvas, i guess not, but that's for Google insiders to say.
• anfilt 5y ago
  I have the canvas element disabled to prevent fingerprinting, good thing I don't really use google docs.
• est31 5y ago
  Btw there is a project to compile LibreOffice to wasm and render it to canvas as well: https://wiki.documentfoundation.org/Development/WASM https://wiki.documentfoundation.org/Development/WASM
• kyrra 5y ago
  (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.
  • ZeroCool2u 5y ago
    I've looked at some of the public spec documents (Specifically the windowing system for Flutter desktop) that Google has hosted in GDocs and that was also the first time I noticed performance degradation. If I had to guess, I'd say there's not a better way around this performance barrier.
  • k__ 5y ago
    I hope so too. But I once read, most performance problems come from all the changes that are chached for a document and yoh can fix the problem by copying the text of an old document in a new one. This doesn't let me hope for huge performance gains.
    • worldsayshi 5y ago
      Yeah cached changes shouldn't have anything to do with dom performance.
  • worldsayshi 5y ago
    Switching to canvas sounds like a very roundabout way to handle an issue related to the dom growing out of hand. Surely unmounting pages that you you're not currently looking at should work? Of course there could be many reasons but we're left to speculate...
    • cellularmitosis 5y ago
      You can ditch the off-screen rendered pages but you are still stuck with the entire 1000-page data structure. Should your current line be on page 997 or 998? You have to calculate the size of every line of every page to answer that.
• lenkite 5y ago
  Huh - might as well use WASM then if canvas is going to be the display target.
• rektide 5y ago
  This is incredibly destructive, an attack on the core technologies & interoperability of the DOM. It's highly concerning, highly scary that they would do this.
  • dvvavinash 5y ago
    why
• notjustanymike 5y ago
  It makes a hell of a lot of sense, even from a QA perspective alone. Canvas is going to be far more predictable as a rendering target than the wide swath of browsers they manage now. The DOM certainly has a place, but if you've looked at Google docs rendered output you'd notice it left web standards behind a long long time ago. This is an application which happens to be served on the web, not a traditional website. It's more Figma, less NYTimes.
  • hajile 5y ago
    VS Code already shows why Google would do this. They moved the Terminal from DOM nodes to canvas and got somewhere like a 20x render improvement (after already having spent a lot of time optimizing the DOM implementation). The previous jank all but went away too. EDIT: added their blog article https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
    • bruce343434 5y ago
      So the previous jank did not go away?
      • Wingy 5y ago
        : very nearly : almost https://www.merriam-webster.com/dictionary/all%20but https://www.merriam-webster.com/dictionary/all%20but
        • bruce343434 5y ago
          right, I thought "all but" meant "everything except for".
  • ainar-g 5y ago
    How would you test something like that using Selenium or something like that?
• pdkl95 5y ago
  Ever since WebAssembly was first introduced, I thought it was obvious[1][2] that the end game for those that want to control the web is sending opaque binary blobs of code that only use the browser for the canvas tag's framebuffer. Font rendering and layout can all easily be accomplished by embedding libraries like freetype. This breaks all forms of user control - like ad blockers - and turns the web back into cable TV. I didn't expect the first move towards canvas-only rendering to be traditional wordprocessors. As usual, this is merely the first step. Once the tech has been normalized by developers, transitioning regular webpages will be a fait accompli. [1] https://news.ycombinator.com/item?id=10294187 https://news.ycombinator.com/item?id=10294187 [2] https://news.ycombinator.com/item?id=26351771 https://news.ycombinator.com/item?id=26351771
  • sgt 5y ago
    It's a bad thing in terms of openness but a good thing in terms of performance and making web applications more like real desktop applications. A lot of DOM work is a nightmare, so I sort of welcome to the Canvas based approach.
    • zozbot234 5y ago
      DOM is just HTML/CSS. It's not a 'nightmare', it's actually a pretty good fit for the semantics of most UI's.
      • kaliszad 5y ago
        Yes, DOM is "just" HTML and CSS with a JS API. All of that is quite broken in various places, the APIs usually rather bad, mutability everywhere and performance suffers as soon as you e.g. switch the cursor from an arrow to hand/ finger, there can be a complete re-render. Google especially is in a position to fix most of these things if they wanted to. They even have the best test-data of any company. But they choose to side-step some of these problems by introducing another, completely new technology and then a small team of people goes on to hack something useable using this technology as if they were a small startup. The problem is, Google is basically a collection of teams with very different focus points. Some are paid to develop new technology no matter if they want it for a specific product. Other people are paid to "improve" an existing product, e.g. Google Docs and have to use what is available. Any kind of exchange of information between teams is a friction and blocks things from being improved. At OrgPad, 10% of CPU time is the maximum we can use if we want a smooth experience. The rest is eaten by the browser and inefficiencies there. I don't think we are alone in stepping over bugs, idiotic APIs and implementation differences everywhere all the time. The fix is not to delegate most of the work to the web developer but for the browser and web standards people to step up and do a thorough job with existing stuff.
• ozten 5y ago
  Accessibility notes: “ we generate a second DOM tree parallel to the DOM tree used as the RenderObject tree and translate the flags, actions, labels, and other semantic properties into ARIA.” https://medium.com/flutter/going-deeper-with-flutters-web-support-66d7ad95eb52 https://medium.com/flutter/going-deeper-with-flutters-web-su...
  • ozten 5y ago
    Their example page doesn't appear to have A11y features enabled. https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview#heading=h.ogp52fyi6djo https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS... I don't see a secondary ARIA DOM. Wave tool sees no semantic content. Can someone from Google docs team explain what A11y features will be enabled at launch? https://wave.webaim.org/report#/https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview#heading=h.ogp52fyi6djo https://wave.webaim.org/report#/https://docs.google.com/docu...
• shaunregenbaum 5y ago
  So Google is betting on Flutter's ethos of canvas rendering for everything. I really hope this doesn't catch on. If Figma, a design tool, doesnt need to use canvases, then neither does Google Docs.
  • leodriesch 5y ago
    Figma does use canvas, Framer doesn't if that's what you meant.
  • andrewingram 5y ago
    Figma uses canvas to render the document, just not for the editor UI.
• tinyhouse 5y ago
  Is this going to make it faster? It's so slow and I use Chrome.
• qunabu 5y ago
  It's like going back in time with Flash Player, There were many WYSIWYG flash based editors around 2010. The problem was it required a browser plugin but it did work much better then HTML4 at that time. For canvas rendering no plugin is needed. Even there was a feature to export SWF file to canvas. There are some issues like accessibility, browser features like search or text highlighting, lazy loading etc. What HTML provides out of the box must be implemented from scratch.
  • pjmlp 5y ago
    Padora box was already open the day, WebAssembly and WebGL came into the browser.
    • qunabu 5y ago
      You can render in canvas with JavaScript only, no WebAssembly nor WebGL is needed.
      • pjmlp 5y ago
        Naturally, the point being made was about Flash.
• disease 5y ago
  Attempting to use the 'Read Aloud' feature of my browser on the example page lead to no text being read aloud.
• iandanforth 5y ago
  "Let's remove the foundations that made the web possible!"
• thekyle 5y ago
  This reminds me a lot of those websites that used to be implemented in Flash. It's just one giant opaque blob that gets downloaded and can do whatever it wants. When this stuff inevitably starts being used by every news and shopping website I wonder how search engines will be able to index it.
  • EvanAnderson 5y ago
    When this stuff inevitably starts being used by every news and shopping website I wonder how search engines will be able to index it. Legal agreements and money changing hands between publishers and Google.
  • MivLives 5y ago
    They'll just have a separate version that is SSR'd for Googlebot.
  • leodriesch 5y ago
    Does not make much sense. If search engines can't index it, no news website will do it.
    • thekyle 5y ago
      If news websites can use this to bypass ad blockers then it might still be worthwhile, and I imagine a lot of traffic comes from social media sites these days.
  • Sleepytime 5y ago
    Google and their AI won't have any issues, but their competitors probably will.
  • kizer 5y ago
    meta tags, and crawlers will use headless browsers or another thing and OCR on top of that. Google already handles SPAs where the content isn’t available until the JS is run. I wouldn’t be surprised if they already have tested or use a modified chromium and for crawling, plus OCR if necessary.
• londons_explore 5y ago
  Am I the only one who doesn't really have any performance issues with Google Docs? The initial loading speed is aggravating - but that is just down to the size of the codebase. Actual rendering performance when I type is imperceptible to me. Putting a few hundred words and a few images onto the screen is presumably very quick whatever technology one uses to render it.
  • sime2009 5y ago
    I suspect that accuracy of rendering and consistency across platforms is the bigger concern here. There are enough differences between how different browsers and operating systems render text via the DOM, to make it very hard to get consistent results between then all. By using canvas they can get very close to pixel perfect consistency. (Especially if they bring their own FreeType library or similar along.)
    • londons_explore 5y ago
      You can already get nearly pixel-perfect consistency by rendering each character as a separate dom element at specific X-Y coordinates. Then the browser isn't responsible for line wrapping or anything. It has the benefit you can still use the browser for GPU acceleration and calculation of damage rectangles. I'd also question how important identical cross-device rendering is in todays world of vastly different screen sizes.
      • sime2009 5y ago
        > You can already get nearly pixel-perfect consistency by rendering each character as a separate dom element at specific X-Y coordinates. You could do that for every character, but the size of the DOM and updating it will kill your performance. You're better off just drawing the characters yourself into a canvas then.
• ryeguy_24 5y ago
  Are there open source document layout engines that are even remotely close to Google Docs quality?
  • Iwan-Zotow 5y ago
    ТеХ?
• tmalsburg2 5y ago
  Perhaps Java applets were not such a bad idea after all?
• BiteCode_dev 5y ago
  And just like that, flash is back
• chadlavi 5y ago
  not really relevant to the topic at hand, but it's wild that google still uses blogger
• scoopertrooper 5y ago
  I just tried the example they provided on an iPad and the scrolling experience is… not great. https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
• lwhi 5y ago
  Feels to me like this could _partly_ be a line of attack. The fight for advertising and tracking on the open web is being lost, which is detrimental to Google. If you have your own ecosystem, what does it matter?
  • lwhi 5y ago
    To the down-voter - please elucidate your displeasure.
• Ajedi32 5y ago
  I think this is actually one of the few cases where canvas-based rendering makes sense as a replacement for the DOM. Docs is a full-featured application which already has to re-implement a lot of DOM-like features in order to fulfill its primary function (things like text formatting and layout, spell checking, etc). Doing it all in canvas doesn't sound significantly more difficult than what they're already doing. The loss of extensibility is regrettable, but probably worth the trade-off for better performance. If this starts happening with more traditional websites, then yes I'd agree that'd be a bad thing. We're certainly not there yet though.
  • irrational 5y ago
    > We're certainly not there yet though. Won’t it be too late when we are there?
  • pwdisswordfish8 5y ago
    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 screen. Only the sorts of techno-fetishists found on this site and in programmer circles would be able to make the argument you just have and not recognize the perverseness of what you're saying and what this decision by Google really means. Documents are the quintessential use case for the Web, full stop, and they're the direct object of whatever the verb form of "Google Docs" would be. Google's decision here reflects the belief that, despite this, the Web is not suited for documents. We're not talking here about the mere act of the "app" chrome at the edges (surrounding the edited document itself) being switched over to use some more perfect framework better suited for e.g. painting interactive widgets, etc. No, it's right there in the announcement: "we’ll be migrating the underlying technical implementation of Docs from the current HTML-based rendering approach to a canvas-based approach". Google is completely dropping the ball here and leading us down the path towards the picture painted in the top comment; what this is is just shy of an abrogation of their responsibility to act as a steward for the Web and the intention that it best serve users (rather than overpaid frontend developers trafficking in flavour-of-the-month fads, frameworks, etc and who already disproportionately receive attention under the status quo). If the Docs team has identified deficiencies in the underlying standards-based model for—let's repeat it—presenting documents, then they are perfectly situated for translating that into feedback about how to improve things so that the Web is better fit for that use case. Even if that meant the Docs team going off into a corner, identifying what the problems with the Web are down to its fundamentals (DOM, etc), and then emerging with an entirely new approach for how to lay down bits so they might be better interpreted by the viewer running on the end user's computer, and then get the Chrome team to bake native support into Blink while disregarding every other vendor's possible objection to this act of steamrolling the standards process, then that would still be better in the long-term than what Google is doing here.
• catchmeifyoucan 5y ago
  HTML Canvas is really smooth. Especially with all graphics acceleration work. Afaik, it's smart enough to load elements that aren't in the view port. I believe text rendering was an issue, but it's mostly usable now. It might work well for rendering logs as well :) [1]https://news.ycombinator.com/item?id=26587951 https://news.ycombinator.com/item?id=26587951
• llacb47 5y ago
  Not thrilled about this.
• nirushiv 5y ago
  Hold up - Google docs didn’t already use canvas? You’re telling me the existing docs apps is HTML and CSS? That’s a mighty impressive engineering achievement to have gotten it working as well as it does now.
• LightG 5y ago
  I'll give up HTML when you pry it from my cold, dead hands ...
• nine_k 5y ago
  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 important sites switch to canvas rendering, what used to be the browser can be radically simplified and made lightweight and much faster. The 'legacy' full-web sites can be shown using a plugin that does all the fancy and heavyweight HTML 5 and CSS 3 stuff. Also, with webassembly running JITted platform-independent code delivered over the network, and displaying it in a platform-independent graphical client (née browser), the promise of Java from 30 years ago will finally come true — sans Java proper, though.
  • hobs 5y ago
    You say this like it wont be used to completely remove all user choice and be an utter disaster.
    • nine_k 5y ago
      Why, I thought I was describing an anti-utopia, a kind of a dark cyberpunk future, because half of the dark cyberpunk future predictions from 1980s have come true already.
    • artificial 5y ago
      You’re going to own nothing and be happy.
      • quickthrower2 5y ago
        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.
        • 5y ago
• gnicholas 5y ago
  I give the gdocs team credit for reaching out to developers of Chrome extensions that may be affected. My accessibility Chrome extension [1] will be broken by this change, and I reported this when asked by the gdocs team a couple months back. I don't know if feedback from my company and others might sway this decision, or if it's set in stone (it's kind of weird to ask for feedback on something that has already been fully decided). I also don't know if they'll be providing more details regarding the timing of the rollout, which seems important since this will break third-party products. 1: https://chrome.google.com/webstore/detail/beeline-reader/ifjafammaookpiajfbedmacfldaiamgg?hl=en https://chrome.google.com/webstore/detail/beeline-reader/ifj...
• pbnjay 5y ago
  As someone who spends an inordinate amount of time in Docs, some speedups would definitely be welcome... but if this is going to break the workflows I'm using now (most importantly Zotero integration) you can be damn sure I'll go back to Word.
• ithkuil 5y ago
  I have a vague memory of some people who installed the https://github.com/panicsteve/cloud-to-butt https://github.com/panicsteve/cloud-to-butt extension for fun, thinking it only modifies text on the screen, but since it modified the dom it caused the changes to somehow end up modifying the open google docs
• kalmi10 5y ago
  Google Sheets is canvas-based. I don’t remember anyone being upset about that.
• diveanon 5y ago
  Hopefully this is the beginning of the end for the JS web.
• jasonjayr 5y ago
  There is a demo doc on their site, and it breaks the X11 primary selection.
  • RenePardo 5y ago
    On the topic of spreadsheets: Rich Harris has it right. LANPAR is in fact the world's first electronic spreadsheet. The inventors/creators also invented implementing Forward Referencing - the cornerstone of spreadsheets. This was in 1969, ten years before Visicac and 14 years before Lotus 1-2-3. LANPAR was used extensively for Plant Budgeting operations across every telephone company in North America throughout the early 70's. VisiCalc, SuperCalc and TKSolver did not have Forward referencing. You had to manually refresh the screen (recalculate the entire spreadsheet) and watch to see when cells stopped changing values (if they needed results from cells further in the spreadsheet (left to right, top to bottom). Lotus 1-2-3 did have Forward Referencing. Multiplan I, did not and accordingly could not hurt Lotus until MultiPlan II incorporated it. I had communications from magazine editor(s) who simply had not been aware of LANPAR because it was so far ahead of its time, and 10 years later VisiCalc implemented its spreadsheet on Apple's microcomputer - popularizing spreadsheets at a consumer level. So Yes, Rich Harris got it totally 100% right!!
• OnlyRepliesToBS 5y ago
  lol remember adobe flash swf binary files and how much that was fought against because it was anti-open-web?
• RyanGoosling 5y ago
  what about screen readers for blind people (aka accessibility)?
• Tyriar 5y ago
  I wrote the terminal canvas renderers in VS Code that has been called out a few times here. Initially I implemented a canvas renderer using just a 2d context to draw many textures which sped things up "5 to 45 times"[1] over the older DOM renderer. Since then I moved onto a WebGL renderer[2] which was mostly a personal project, it's basically the first canvas renderer but better in every way since it works by organizing a typed array (very fast) and sending it to the GPU in one go, as opposed to piece meal and having the browser do its best to optimize/reduce calls. This was measured to improve performance by up to 900% in some cases over the canvas renderer, but actually much more than that if for example the browser has GPU rendering disabled and tried to user the canvas renderer on the CPU. My opinion here is that canvas is a great technology, capable of speeding things up significantly and getting close to native app performance. It comes with very real trade offs though: - Cost of implementation and maintenance is much higher with canvas. This is particularly the case with WebGL, there have been very few contributions to xterm.js (the terminal frontend component) in the WebGL renderer because of the knowledge required. - Accessibility needs to be implemented from scratch using a parallel DOM structure that only gets exposed to the screen reader. Supporting screen readers will probably also negate the benefits of using canvas to begin with since you need to maintain the DOM structure anyway (the Accessibility Object Model DOM API should help here). - Plugins/extensibility for webapps are still very possible but requires extra thinking and explicit APIs. For xterm.js we're hoping to allow decorating cells in the terminal by giving embedders DOM elements that are managed/positioned by the library[3]. More recently I built an extension for VS Code called Luna Paint[4] which is an image editor built on WebGL, taking the lessons I learned from working on the terminal canvas renderer to make a surprisingly capable image editor embedded in a VS Code webview. [1]: https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend... [2]: https://code.visualstudio.com/updates/v1_55#_webgl-renderer-is-the-new-default https://code.visualstudio.com/updates/v1_55#_webgl-renderer-... [3]: https://github.com/xtermjs/xterm.js/issues/1852 https://github.com/xtermjs/xterm.js/issues/1852 [4]: https://marketplace.visualstudio.com/items?itemName=Tyriar.luna-paint https://marketplace.visualstudio.com/items?itemName=Tyriar.l...
  • trinovantes 5y ago
    Do you think the large performance benefits can be achieved for any general web app (e.g. if I rewrite my Vue app's render functions to using a canvas instead of the DOM) or is the canvas' benefits mainly for niche workloads?
• spankalee 5y ago
  This is one reason I think projects like Servo are potentially very beneficial even well before they can render every legacy quirk you find on the open web. Instead of bringing a custom rendering engine to the web via WASM and canvas, it'd be better in so many ways to bring a subset of spec-compliant HTML rendering to embedded contexts. If your content renderer can run on Servo, and render the same in modern browsers, you can use HTML as the basis for cross-platform rendering. At least I would hope that would be possible by now so we don't have to write renderers for every platform anymore.
• specialist 5y ago
  One step closer to Display PostScript. Woot! https://en.wikipedia.org/wiki/Display_PostScript https://en.wikipedia.org/wiki/Display_PostScript As the original HTML-hater, I've been joking for a while that we're slowly, painfully recreating X-Windows. I've been wondering if I'll live long enough to see a return to sanity. https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
• stadium 5y ago
  Is this similar to how flash was used for dynamics content before html/css could do it?
• deleted 5y ago
  [deleted]
• kejjjiee 5y ago
  Google motivation: make adblockers unable to work properly
• crb002 5y ago
  I'm worried about screen reader compatibility. FAANG should push to support Lynx text browsing for blind users - and our bandwidth.
• tgiba 5y ago
  So we're building binaries, to run them in WASM, that's running in JavaScript, which is running in browser, that is written in C++ .. is that what we're doing now?
  • EvanAnderson 5y ago
    Obligatory reference to The Birth and Death of Javascript: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  • VMtest 5y ago
    This is misleading. 1. You write Canvas in Javascript, the article did not mention anything about Canvas in WebAssembly. 2. Although WebAssembly used to run in Javascript with asm.js, WebAssembly code can be executed by V8 engine (C++ based) already.
• stephc_int13 5y ago
  I think this is a pretty logical evolution. In my opinion they should wait a bit and build a solid C++/WebGPU on WebAssembly renderer to skip a few steps and avoid doing the same work a few years down the line. The web was designed to display document, not to host application, it was stretched very far but is also extremely complex and kind of slow.
• abxytg 5y ago
  Would love to hear a Googler justify this. It's just closing down the web. No more view source for the curious kids. Shame on you.
  • thehappypm 5y ago
    Not a Googler, but I've done many projects in both Canvas and HTML/CSS/JS. Canvas is actually really hard to get right. You basically are given these super basic tools and have to go do everything yourself. With HTML and CSS you're standing on the shoulders of giants. With Canvas you're drawing arcs and squares and lines. That being said, canvas is the kind of thing if you DO get it right, it's awesome. It's just fast. And really portable: every platform supports a canvas of some kind, and the primitives tend to be really similar.
• aranchelk 5y ago
  On multiple levels it seems nuts to use canvas for a stylized text editor. There are layout consistency issues across browser and OS. The place I’ve seen this is page breaks changing between computers (or even zoom levels). Line length isn’t controlled solely by the browser, IIRC both kerning (letter spacing) and word spacing is determined by the OS. I implemented something like Docs myself, but with the goal of total consistency of line/page breaks. Knowing about these issues I used SVG. In SVG text you can override line length, but you still need to have a value in mind, a reference to be calculated independent of user environment details. Regarding performance, one issue I can speak to is the cascading changes to line breaks. This can be pretty brutal when making a change to the beginning of a long document. To get acceptable performance I had to partially remove the application framework I had been using. I liked my solution and it worked quite well in prototypes, but I don’t know how it would have faired in the wild.
  • kizer 5y ago
    You can render the fonts and do the text shaping yourself. You don’t even have to use any of the Canvas API except putImageData, or WebGL. Also you can use your own curve drawing algorithms so you own all pixels of the application.
• yayr 5y ago
  Am I right to assume that also parts of the interaction UX are now rendered by canvas? I looked at the source and even text selections etc. do not have DOM tree elements anymore.
• contravariant 5y ago
  Great now it's even less useful if I don't allow fingerprinting.
• spdustin 5y ago
  A lot of discussion going on here, but I want to add two things in support of this change: 1. A browser- and OS-agnostic layout experience will have real effects. Just last week, a doc I wrote on my Mac (with Chrome) ended up with several pages with orphaned text, because the page/section breaks I inserted near the end of a page on purpose ended up breaking for Windows Chrome users due to slight variations in font rendering. 2. They have a sample document linked in that post. The text is still 100% selectable/copyable, and assistive technology is able to read and navigate it.
• xnx 5y ago
  26 years later and we're back to java applets. It was fun while it lasted.
• deleted 5y ago
  [deleted]
• jcuenod 5y ago
  I wonder what their plans are for accessibility?
• IceHegel 5y ago
  As someone who's never worked with canvas, I'm now curious about how it works. What is the workflow like for rendering text? Under the hood, is canvas implemented using WebGL APIs or do browsers have their own separate implementation for canvas?
  • rikroots 5y ago
    The canvas 2D API[1] has support for rendering text, but it is ... limited. For instance, there's no inbuilt multiline support. Which means that if you're serious about rendering text to the canvas, then you have to reimplement a whole host of things yourself in Javascript. Another worry is that browsers have an inconsistent approach to interpreting `ctx.font = "CSS font string"` - Safari, for instance, does not support the 'bold' keyword; the only way to get that browser to display bold text is to supply it with an already emboldened font. However with a lot of work, it's possible to do some amazing things with text. Below, links to a couple of demos of text rendering using my own canvas library[2][3]. [1] I highlight the 2D engine because the Google Workspace team specifically linked to the W3C HTML Canvas 2D Context specs in their announcement. I understand that rendering text in the WebGL context is far more complicated. https://www.w3.org/TR/2dcontext/ https://www.w3.org/TR/2dcontext/ [2] https://scrawl-v8.rikweb.org.uk/demo/canvas-017.html https://scrawl-v8.rikweb.org.uk/demo/canvas-017.html - Phrase entity: test lineHeight, letterSpacing and justify attributes. Section classes functionality [3] https://scrawl-v8.rikweb.org.uk/demo/canvas-018.html https://scrawl-v8.rikweb.org.uk/demo/canvas-018.html - Phrase entity - text along a path
• eitland 5y ago
  Here's one thing Google hasn't yet realized it seems: They are neither the coolest kid in the class anymore nor the teachers favorite; they can't just do whatever they want anymore. This is a good thing but I wonder how long it will be before Google get the message. Seing how long Microsoft pushed Silverlight I'm afraid well have to live with this for years to come.
• joeberon 5y ago
  Slowly adding more features to the web, a system really not designed for those features, seems to have been the only way to get a really cross platform application ecosystem. Very weird for it to happen through this random technology, but obvious in retrospect.
• asumandiras 5y ago
  despite the fears of locking down the web, this is really neat from a UI/UX perspective. i'm assuming they're using flutter to do the rendering. is anyone working on an open sourced js framework that also does render to canvas UI?
• sim_card_map 5y ago
  Open web is dying...
• deleted 5y ago
  [deleted]
• jokoon 5y ago
  I wonder how much simpler and lighter a browser would be if it only supported canvas.
• cblconfederate 5y ago
  Oh good , Flash is back! Or maybe java applets. Or silverlight, but this time it's gonna be different
• Yuioup 5y ago
  What's next, a Canvas rendered web browser?
• Liskni_si 5y ago
  Has anyone found a way to report bugs in the preview implementation?
• satyanash 5y ago
  Canvas will become de-facto, just like React did. Once that happens, indexing and scraping the web won't be trivial anymore. One would have to "opt-in" to using HTML/CSS to make sure that their page would be indexable. Clearly also indicates that Google is willing to give up on its web-indexing capabilities in the long term, now that they have a stronghold on the Mobile app marketplace. Most likely spells doom for websites, further making "apps" the norm.
  • kizer 5y ago
    Their crawlers are more advanced now. They already handle SPAs with # URLs and content that’s only fetched once the JS is executed, and likely use some OCR and more powered by AI magic.
• dangoor 5y ago
  In 2009, I joined Mozilla and started working on the Bespin[1] project, which Ben Galbraith & Dion Almaer had brought to Moz. Bespin was built with a canvas-based renderer. Bespin was way faster than other browser-based code editors at the time. Then the Ajax.org/Cloud9 folks came along with their Ace editor[2], which was DOM-based and still very fast. We ended up merging the projects. edit to add: and switching to DOM rendering Rik Arends[3] was one of the Ajax.org folks and he's been working on a WebGL-based code environment called Makepad[4], which is entirely built in Rust and has its own UI toolkit. He's complained a lot about how difficult it is to make a performant JS-based editing environment. My point in all of this is just that there are absolutely tradeoffs in performance, accessibility, ease-of-development, internationalization, and likely other aspects. If raw performance is what you're going for, it's hard to beat just drawing on a canvas or using WebGL. Google Docs needs to worry about all of that other stuff, too, so I'll be interested to see how this shapes up. [1]: https://en.wikipedia.org/wiki/Mozilla_Skywriter https://en.wikipedia.org/wiki/Mozilla_Skywriter [2]: https://en.wikipedia.org/wiki/Ace_(editor) https://en.wikipedia.org/wiki/Ace_(editor) [3]: https://twitter.com/rikarends https://twitter.com/rikarends [4]: https://makepad.dev https://makepad.dev
  • skyde 5y ago
    Can someone explain why https://makepad.dev/ https://makepad.dev/ is extremely slow and "unusable" on Microsoft Edge browser but run smoothly on Chrome? Is it because of bad WebGL perf on JavasSript perf in general?
    • ComputerGuru 5y ago
      Edge or Edgium?
    • tyingq 5y ago
      Another possibility is code that acts differently depending on user-agent.
      • rikarendsmp 5y ago
        It most definitely does not.
• quickthrower2 5y ago
  Are accessibility features like aria available for canvas based apps?
• vzaliva 5y ago
  It it kills grammarly extension I will be so dissapointed. Could they keep the old mode as an option for some time?
• amelius 5y ago
  What if I want to embed some HTML+CSS in the document?
• azinman2 5y ago
  My understanding of canvas is that it’s a 2D bitmap you can draw to. So how is text selection (and a keyboard up in mobile Safari) working here? Do they have hidden text elements behind the canvas or something?
  • progval 5y ago
    They probably reimplement entirely from scratch by getting the position of the mouse and listening to click events.
    • azinman2 5y ago
      Meaning they're creating text dynamically with the click event? I'd assume that'd be chicken-and-egg where the browser wouldn't respond to the click event if there's no text to select?
      • progval 5y ago
        No, I mean they would draw the selection themselves on the canvas. And they would get the event simply because the user clicked on the canvas.
        • azinman2 5y ago
          But that's not happening, as I'm able to select text on iOS Safari and have it give me the copy/paste options above it. If the text wasn't available, it would also completely break any kind of screen reader / accessibility feature so something has to be supporting this at a native-browser level.
          • progval 5y ago
            I don't know about iOS, but on Firefox Desktop, the right-click menu is emulated by the canvas, and it uses the clipboard API to copy it. > If the text wasn't available, it would also completely break any kind of screen reader / accessibility feature so something has to be supporting this at a native-browser level. When using a screen reader, it tells you you press Ctrl+Alt+Z, which loads an iframe containing (only?!) the first paragraph of the text, so it is made available to screen readers independently. I have no idea if this would work for editing though.
• slmjkdbtl 5y ago
  DOM is just not the way to build complex UI, we need to have control over the lower level draw loop and graphics, it's a pain to build a high level system on top of another high level system, it leads to hacks and unintuitiveness like react hooks. Building UI framework in canvas is way more fun and clean and the only way (in the browser) to think about UI programming from first principal, I dream of a browser environment where DOM / HTML is an optional library.
• p1mrx 5y ago
  Does this mean I'll be able to jump to the end of a document without, like, 30 seconds of rendering computation?
• larodi 5y ago
  ...how long before someone strips the browser and ships a runtime with no DOM, canvas and WASM/v9 only. Very platform independent and perhaps fast also...
• jgalt212 5y ago
  I'd be very curious to hear if they looked at SVG. I assume it's less peformant, but maybe for word processor it would be about equal. Easy to imagine canvas outperforming SVG for a spreadsheet app.
• olliej 5y ago
  Sample doc isn't editable affect, presumably to hide the fact that in addition to overriding standard scrolling it also doesn't support international text entry or, 50/50, standard and custom key shortcuts from the OS [edit: I was right - cmd-f doesn't use the proper find ui, cmd-e doesn't update the search pasteboard, and cmd-f doesn't track the system search pasteboard.]
• Animats 5y ago
  The next step will be that they just send you images.
  • deafcalculus 5y ago
    Mighty seems to want to do that even sooner!
• yread 5y ago
  I wonder if it will help improve ios canvas performance - currently it's somewhere on ie9 level for our use case at least
• aazaa 5y ago
  > ... Over the course of the next several months, we’ll be migrating the underlying technical implementation of Docs from the current HTML-based rendering approach to a canvas-based approach to improve performance and improve consistency in how content appears across different platforms. This article talks about some of the tradeoffs between Canvas and DOM approaches: https://www.kirupa.com/html5/dom_vs_canvas.htm https://www.kirupa.com/html5/dom_vs_canvas.htm The thing that seems least appealing about replacing DOM rendering with Canvas rendering is the lack of CSS. You may gain performance, but assuming even a fraction of the responsibilities CSS handles so well seems very daunting. That's why I suspect this approach will do best where the content least resembles a read-only document, and more resembles a game, such as Google Docs.
• ok123456 5y ago
  It's sort of clear they intend to do a rewrite of Google Docs in C++ or some other systems language and compile it to webasm because of better tooling. That's why they went went canvas instead of webgl, since webasm+gl was never widely adopted or complete.
• deleted 5y ago
  [deleted]
• willyg123 5y ago
  Someone please ELI5 how this might impact the Grammarly Chrome Extension. Thanks in advance!
• snewman 5y ago
  Speaking as one of the original three authors of Google Docs (Writely), but zero involvement in this project (I left Google in 2010): I'm seeing a lot of comments asking how JavaScript-on-Canvas could possibly outperform the highly optimized native code built into the browser engines. It's been a long time since I've really been involved in browser coding, but having written both Writely and, farther back, several native-app word processing engines, here are some thoughts. Word processors have extremely specific requirements for layout, rendering, and incremental updates. I'll name just two examples. First, to highlight a text selection in mixed left-to-right / right-to-left text, it's necessary to obtain extremely specific information regarding text layout; information that the DOM may not be set up to provide. Second, to smoothly update as the user is typing text, it's often desirable to "cheat" the reflow process and focus on updating just the line of text containing the insertion point. (Obviously browser engines support text selections, but they probably don't expose the underlying primitives the way a word processor would need. Similarly, they support incremental layout + rendering, but probably not specifically optimized in the precise way a word processor would need.) Modern browser engines are amazing feats of engineering, but the feature set they provide, while enormous, is unlikely to exactly match the exacting requirements of a WYSIWYG word processor. As soon as your requirements differ even slightly from the feature set provided, you start tipping over into complex workarounds which impact performance and are hell on developer productivity and application stability / compatibility. This is loosely analogous to CISC vs. RISC: browsers are amazing "CISCy" engines but if your use case doesn't precisely fit the expectations of the instruction set designer then you're better off with something lower-level, like Canvas and WASM. (I don't know whether Docs uses WASM but it would seem like a good fit for this Canvas project.) Frameworks in general suffer from this problem. If you've ever had to fight with an app framework, or orchestration framework, or whatever sort of framework to accomplish something 5% outside of what the framework is set up to support, then you understand the concept. Also, as noted in many comments here, browser engines have to solve a much more general problem than Docs, and thus have extra overhead.
  • aloer 5y ago
    How would you recommend someone to get started learning about the architecture of Text editors / word processors? I think Monaco from vscode is probably an interesting read but I’ve never looked at such a big open source code base before. Is there something you can recommend to understand better how it works architecturally?
• khc 5y ago
  All I want to know is: is this going to make google docs on firefox faster or slower?
• agilob 5y ago
  Can this be because of Dart and Flutter? Flutter for Web uses own canvas rendering system instead converting to html/js.
• EGreg 5y ago
  They have already been using that for spreadsheets where you can't copy things. You may think... "I'm a 1337 developer, I will use Developer Tools" and select elements and run JS. But it's canvas rendering, so nope.
• crazygringo 5y ago
  This is great news. If you've tried using Google Docs extensively for layout-heavy things, you've probably noticed a bunch of subtle things break a little bit, for example as pixel rounding errors accumulate down a page. This can be especially evident when using things like lots of table cells, borders, and zoom levels different from 100%. The blinking cursor can sometimes be almost a full line misaligned from the text being edited. Also if you've tried using Docs across different platforms and browsers, there can be subtle differences in line heights, word-wrapping, and so on. Which might not seem like a big deal, until you try to write your term paper to be no more than 25 pages long, and then when you go to a shared computer to print it, it's now 26 pages because a bunch of lines are now wrapping that weren't before, and your professor won't accept it! If canvas means Google now has total control over precise element and letter positioning and wrapping, this will be a BIG step forwards in truly being a consistent, cross-platform, WYSIWYG word processor, as opposed to the way it's often been "usually mostly right but not always exactly". Websites are supposed to be responsive and flexible and not depend on exact font rendering. But word processors really do need reliable control over layout when producing serious documents like papers, resumes, etc.
• resters 5y ago
  It will be interesting to see if Google Docs undergoes a feature explosion and achieves parity with MS Word after the rendering engine enhancements. I wonder what competitive pressures Google is responding to with this decision. My guess would be adding features taht facilitate selling into businesses that have significant dependency on MS Office.
• throw_m239339 5y ago
  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...
• svat 5y ago
  Noticed something to try: The post links to an example document: https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS... If you change the /preview to /edit you can then go to File→"Make a copy", and you'll have your own editable version of this document. If you change that one to /preview again, you (unsurprisingly) get something that doesn't use canvas, but uses the DOM with the usual div/span soup. Here's an example I created: https://docs.google.com/document/d/1RnQonRlivBogXxSl1nTZSCfRhowGTunOIf8x5HJq1Is/preview https://docs.google.com/document/d/1RnQonRlivBogXxSl1nTZSCfR... These two /preview versions would be a good basis for comparison (until we have examples of editable documents that use canvas-based rendering). Visually, comparing the two /preview documents by alternating rapidly back and forth between the two tabs shows some minute differences in kerning (on only some of the lines). It might be interesting to repeat this experiment on multiple devices and see whether and in what way the differences themselves differ across devices. One difference I've been able to find is that using the browser's in-built find doesn't work. But all the common ways of triggering search (Ctrl-F or Cmd-F, etc) trigger the search function of Docs, and that seems to work identically in both versions. And anyway the browser's find cannot find things off-page before scrolling down the page, so it's not usable in general anyway.
  • augustl 5y ago
    Makes me wonder if they actually implemented their own kerning..
• deleted 5y ago
  [deleted]
• vaughan 5y ago
  If you click `Save as Copy` on the example doc you get an editable DOM-based version to compare. The scrolling is a lot less smooth on the canvas than the DOM. Text selection seems faster but the canvas version is not editable... Maybe they are working out the kinks though...
• bob1029 5y ago
  I've been playing around with pure-canvas web apps that are set up as follows: Client -> Server: Raw event stream (keyboard/mouse/touch/resize events) Server -> Client: Canvas draw batch stream The server provides a small javascript shim that bootstraps a websocket & subscribes to all required event sources. It also subscribes to the server issued batch events and has logic to dispatch draw commands to the canvas element. On the server, I use LMAX Disruptor to aggregate the client events and process them in micro batches (the size of which are determined dynamically based on backpressure). This results in an incredibly low-latency/low-jitter UI. Client events are passed around as readonly structs, so very little allocation or GC is involved throughout (.NET5/C# codebase). Processing is concluded with async/parallel dispatch of the appropriate client-side draw batches as they are ready to be issued. Not all client events result in a draw, and not all client events result in draws on the same client. There are some synchronous concerns between clients in my application, so having a single fast thread allows for lock-free processing of all events at the same time. The only caveat I have encountered is the latency constraint. Going over ~100ms makes this sort of interface feel like crap. For LAN/localhost, this approach is effectively instantaneous.
  • kizer 5y ago
    I’ve considered making something similar, but I’ve thought: what’s the advantage? Just more computation for the server that could be done client side. Why not just have the app on the client. I’ve dubbed this the “cloud gaming” approach, lol.
• alvarob 5y ago
  I think the trend of rendering web apps in canvas is about to explode and it will be ironically promoted by one of the biggest defenders of HTML: Google. The reason I believe is that they no longer need to parse web apps using the DOM because instead they are/will be using Machine Vision.
• devongovett 5y ago
  This is very bad for accessibility. Rendering things in canvas means there is no DOM, which means nothing for screen readers to read. To be fair, the old google docs editor was also very bad for a11y, but at least there was potential to improve it. This removes that option. They could have worked with the Chrome team to help improve standards for everyone, but decided to reimplement the rendering engine from scratch without regard for accessibility. I'm very disappointed that this wasn't flagged at a company the size of Google.
  • lhnz 5y ago
    The example that Google shows in their post has accessibility features [0], although currently these need to be switched on with a keyboard shortcut (⌘+Option+Z). Pay attention to `document.getElementById('docs-aria-speakable')`. [0] https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
    • devongovett 5y ago
      Yeah it's pretty bad to have accessibility be a mode though. Also, since it's completely non-standard, the usual screen reader navigation keys don't work as expected and users have to learn a completely custom interface. Better than nothing but it's not great.
• kizer 5y ago
  I've been working on a canvas-mostly render library. Some things like text input would require using the native component to some degree; e.g., the input element could be invisible while the canvas would render the text field in its place. Honestly, why even bother with the DOM? Even for "article" sites; you can have pixel perfect control over your rendering, especially if you even implement your own anti-aliased bezier curve rendering algorithms. There's already a library that processes fonts (opentype.js) and returns the parameters of the bezier curves that need to be drawn to construct the glyphs. You're fine still using HTML/CSS for a bunch of reasons (lighter static sites, already have developed codebases for each). But, why not own the whole thing in TS/JS? For web applications, you'd then have pixel perfect consistency across browsers and mobile devices. There are two ways Flutter, for example, compiles to a web application[0]: either to a mix of canvas, CSS, SVG, and HTML, or just to pure WebGL Canvas using a WASM build of Skia (that's right - the engine that renders HTML/CSS in the first place). So with WebAssembly and the Canvas, especially taking into account the upcoming WebGPU API which will unlock even better render performance, I'd rather have my whole application be defined in JS/TS and own all of the experience down to the pixel -- complete control. Obviously this is assuming convenient libraries (in WASM/JS) for rendering text/curves/etc. to canvas will exist. Would be awesome for certain web app usecases. [0] https://flutter.dev/docs/development/tools/web-renderers https://flutter.dev/docs/development/tools/web-renderers
• perfunctory 5y ago
  Strangely, this reminded me of Bret Victor > To deliver her message most effectively, the visual designer needs as much control as possible over what the viewer sees. But, by definition, the designer only has direct control over the tool. She is at the mercy of whatever platform implementation the recipient happens to supply. This implies that a good platform must be as simple and as general as possible. > From a practical (and historical) standpoint, we can assume that no complex specification will be implemented exactly. This, in itself, is not a problem. However, multiple, decentralized implementations of a complex specification will be incorrect in different ways. A platform consisting of the union of all possible implementations is thus arbitrarily unreliable—the designer can have no assurance of what a recipient actually receives. For a platform to be reliable, it must either have a single implementation, or be so utterly simple that it can be implemented uniformly. If we assume a practical need for open, freely implementable standards, the only option is simplicity.
• yashap 5y ago
  For everyone saying "Google is pushing canvas usage to kill ad-blocker effectiveness", maybe, but most of Google's ad revenue already works around ad blockers. Most of their ad revenue comes not from their display network (ads that they serve on other ppl's property), but from showing ads on their own properties. Only ~13% of their revenue comes from ads displayed on properties they don't own: https://finshots.in/infographic/breaking-down-revenue-streams-of-google-the-alphabet/ https://finshots.in/infographic/breaking-down-revenue-stream... And "only" ~25% of users use ad blockers, so ad blockers likely only hit Google's total revenue by ~3%. Ad blockers mostly work by blocking known display-ad-serving JS scripts, that ppl include on their page. Ads within Google search, Gmail, YouTube (and big non-Google advertisers like Facebook, Twitter, Reddit), don't use this approach, the ads are much more built into the page (embedded in product JS bundles, or simply returned by the backend from Ajax calls, mingled in with non-ad data). These ads are really hard to block, regardless of whether the page is a traditional web document, or uses canvas. Blocking them basically involves parsing the page and looking for things you think are ads, which is incredibly difficult to make work reliably over time, so nobody really bothers, and that's true regardless of canvas vs. traditional web document.
  • philosopher1234 5y ago
    That 3% you're referring to is 5.5 billion dollars, which easily justifies canvas usage. I don't personally see the connection between google docs and ads, but I think this analysis is misleading.
    • yashap 5y ago
      Fair enough, I’m sure they’d love to kill ad-blockers in general. But ... using canvas in a product that doesn’t show ads of any kind, nevermind display network ads, it is indeed a very tenuous argument that this is an anti-ad-blocker play.
• Simran-B 5y ago
  Huh, I thought it would already be based on canvas, but I'm not sure why. I believe I observed some behavior or looked into the developer console once and got the impression that they can't be using DOM.
• timmg 5y ago
  FWIW, Sheets has been doing this for 5+ years. (Source: I worked on the team when this was implemented -- by someone else.)
• marcan_42 5y ago
  I get why they're doing this, but this sucks for me. It's going to permanently and unfixably break browser extensions that work on the DOM, for these docs. In particular, I am learning Japanese and use Rikaikun/Rikaichamp to get kanji definitions/readings on hover. I don't see this getting fixed in the extension, since it would involve having a completely separate brittle path just for Docs. I may end up having to switch to an alternative platform for document sharing, at least some of the time.
• nyanpasu64 5y ago
  I'll be shocked if they manage to create a canvas which will render without off-by-1 pixel dimensions and blurry text when I'm using fractional DPI scaling or browser zoom (not Google Docs zoom). VSCode's canvas terminal failed, Chrome's PDF reader failed... EDIT: Hmm, it actually works, at 125% DPI and various browser zoom levels, the text isn't blurry. Maybe that's linked to how the page doesn't change size when you resize your window.
• elwell 5y ago
  I didn't see any mention of it in the article, but I wonder if this has some code-sharing with Flutter. IIRC, Flutter uses canvas when rendering in the browser.
• thordenmark 5y ago
  Google Docs, from a user's point of view, is an incredible bit of software engineering. It has revolutionized my work flow and collaboration with partners. So whatever you engineers did to make it happen: KUDOS! The only thing that worries me is Google's finickiness. I have a lot of data on Google drive and many important Docs. When I hear of Google just cancelling someone's account or abandoning some software I get a bit nervous. I keep backups of course, but it is unnecessary stress.
• alphabet9000 5y ago
  I wonder if they will expand their use of canvas to other products of theirs, such as google images.
• jan_schultink 5y ago
  I had to put in a lot of effort to write a useable slide rendering engine for my presentation app SlideMagic that was super precise, scales up and down without issues, and still enabled clicking things in the UI. If Google has a good canvas-based engine, hopefully they will open source it as a new standard.
• cesarvarela 5y ago
  Here waiting for the announcement of a canvas based browser.
• jart 5y ago
  How long before most of the web is canvas rendered by webassembly blobs that communicate opaquely?
• wly_cdgr 5y ago
  Cf. my point in a recent D3 thread about why don't we just use something sane like Pixi.js for dataviz
• needle0 5y ago
  Oh boy, god knows how many international text rendering bugs this is going to uncover
• anonytrary 5y ago
  CTRL + F? I feel like I remember using that in Google Docs. How will they rectify this?
• dontwannabe 5y ago
  Why not WASM?
• nyordanov 5y ago
  All text in the example document[1] is blurry on Firefox 89.0b11 (Linux) with a 4k display at 2x scaling. Anyone else having the same problem? [1] https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
• teddyh 5y ago
  It is surprising to me how blind Google is to the second-order effects of this is. Suppose that this model of rendering pixels to canvas is a success. Suppose it is adopted by various content serving systems like WordPress, JavaScript frameworks, etc. Now Google Search has nothing to index! The whole web just became completely unsearchable. Google Search, and all web search as a concept, becomes mostly useless. You might think that Google assumes that they’d be served special content to index, but I remember the shenanigans that people used to pull with serving the Google bot one set of content and actual page visitors other content, and how Google has to continually fight against this to preserve the relevancy of search results. If canvas rendering becomes normal, Google will have no way to fight against this anymore, and Google search results will be dominated by links which does not contain the promised content. It’s possible that Google thinks that Google is big enough that nobody will opt out of being searchable by Google, but consider Facebook. Facebook content is basically impossible to find using Google, and everybody wants to be the new Facebook, right? As I see it, the efficacy of Google Search rests on a few premises which were true in the 1990s: 1. Web content which is created without indexing in mind will be able to be indexed by Google. 2. If web content creators have indexing in mind, they want Google to index the content, and the path of least resistance will allow Google to do it. 3. If web content creators want to play funny games and serve one set of content to Google and other content to site visitors, this is difficult and requires playing a constant game of cat-and-mouse with Google. If canvas rendering becomes the new thing, all three of these things reverse and becomes false. How, then, could Google Search stay relevant? Why would people pay to advertise on Google if Search becomes useless? Especially when Facebook ads exist, and Facebook is where people spend more than 90% of their web time on, anyway.
  • stuffbyspencer 5y ago
    I highly doubt Google would embrace something that kills there business without having a plan. Off the top of my head I can think of 3 scenarios: 1. Google is investing in tech that allows them to index canvas-rendered items (putting them far ahead of all other search engines if they are the only ones with this tech) 2. Google will put out an "index.txt" guideline ushering in a new way to create SEO content for the internet (there are problems here but, like with anything, they can be addressed in time) 3. Google might ditch indexing altogether and look into alternative ranking methods (curation groups? popular in your social sphere? heavier reliance on ads?)
• ThomasBHickey 5y ago
  This whole discussion reminds me of work we did in the early 80's trying to convert typesetting tapes into TeX/Metafont for display/printing. One the things we tried was converting scanned images into rectangles which could then be typeset by TeX using 'rules' of various sizes. Another approach was to convert the scans into specialized fonts, either whole or in contiguous chunks that could be assembled.
• augustl 5y ago
  I wonder how they will _measure_ the text. You can use the range API to get the client rects for individual letters of text nodes in DOM, and then you could render that into a canvas letter-by-letter. You'd get kerning etc handled by the browser. But canvas has no such API afaik. Maybe Google has implemented their own kerning?
• jmatthews 5y ago
  Why are they not implementing this in flutter? They're going to end up rewriting half of skia