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.
"Displaying documents" and "displaying editable documents" are two completely different beasts. The web browser has never dealt well with displaying editable documents, the closest standard that exists is contentEditable and pretty much everyone agrees that it sucks and is not fit for complex use cases.
Why can't Google work on improving `contenteditable`? It would benefit so many and the problems are well-known. It's probably even used by Google somewhere
I've heard there was actually a vocal push from Chrome for Docs to use contenteditable and even with motivated Chrome engineers they couldn't make it competitive. They basically could never fix it for Safari.
You could easily burn five years trying to fix `contenteditable` and get nowhere. There's too much legacy and impedance mismatch. Better to start fresh at this point.
Ok, and then the new version is only supported by chrome. So they still need to keep their old rendering engine up to date. Will the other big browsers ever go along with supporting it? Or will that work be lamented as google trying to own the web and just updating standards that benefit their bottom line?
All web pages are editable currently, they are editable via Javascript. Not sure the distinction you are making is meaningful. The only thing we are missing is a good edit UI.
> 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.
You seem to be basing your whole point on the misplaced idea that the web is great at displaying, nay was specifically made to display Google Docs' class of content. This is incorrect. At its core, Google Docs is a typesetting engine with semantics and features that don't align well with HTML+CSS. Typesetting is about graphics, the web (and HTML) is about content. They're very different use cases.
> [...] what this is is just shy of an abrogation of their responsibility to act as a steward for the Web
Google has no obligation, either moral or legal, to be a technical leader. They're simply a market player. The only way in which I care about this change is how it affects me as a user and it's nowhere near as catastrophic as you make it sound imho.
> Google's decision here reflects the belief that, despite this, the Web is not suited for documents.
I don’t see how you jumped to that conclusion. They’re not changing the way documents are stored, they’re only changing how documents are rendered.
Who’s relying on the render API? What functionality do you think you’re losing, as a web user?
The web of HTML+CSS is good for some kinds of documents - static documents, but it has never been good at editing documents, and it has never been good at all documents, and it has never been the best platform for high performance applications like editors or games.
> this 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
Ignoring the problems with your assumption that Google should act as a steward for today’s Web (Google’s mission statement doesn’t mention preserving HTML. And it’s better if public, not private for-profit entities are our stewards) -- this decision is being made to best serve users, no? As a user, I want Docs to render faster, don’t you?
I’m not quite seeing your reasoning why this affects the long term health of the Web. I can’t help but note that many large web apps have transitioned to canvas rendering for performance, and the internet is still growing. There is, in fact, a problem with rendering HTML+CSS in a performant way when editing things, and it might be too late, and there might be too much legacy to fix it... maybe. It’s still pretty good at what it does, and not likely to go away.
If that's your point of view then no, the web has never been suited to spreadsheets, it was only suited to PowerPoint-like presentations when Opera had some nice markup for that functionality, and it is only suited for Word-like documents, with ugly hacks for equations.
In the end, you end up making Google's argument just stronger.
Google Docs produces printable documents not hypertext. Print was never a priority of HTML. And I guess it shouldn't be either. Just look at the complexities of DocBook, LaTeX or Open Office XML.
> Documents are the quintessential use case for the Web, full stop
In 1996, yes. And you can still use the Web that way. Nobody's stopping you. Much of the Web is still used that way, and that's not going to change.
But in 2021, the web serves documents, and applications. And HTML/CSS was never intended as a way to build applications.
It's why people came up with Flash, Java Applets, ActiveX, and all that other shit. And the web today wouldn't be one whit better off if the vendors of those technologies took your advice, and rolled their functionality into the core web. In fact, it would be in many, many ways worse off.
This is not a response to the point being made at the point where the quoted text originates, even though superficially it looks like it is. Please re-read the comment you're responding to.
Actually, it responds to the entire[1] train of thought that follows that statement. Please re-read what I am saying, and consider it in context. You are suggesting that Google work on updating the standards to make their desired use case work better. I am suggesting that Google's desired use case will never be served by document-oriented standards, and that is why it shouldn't mess with those standards.
Again, the world would not be better off if ActiveX were rolled into web standards back in the oughts.
Leave document standards responsible for displaying documents, and don't let the needs of application people get in the way of that.
[1] Well, I don't respond to your point that Google Docs is intended to display documents - because, as another commenter points out, it's incredibly obvious that its most important function is to edit documents.
Thank you for articulating this.
For the last decade we have had frontend developers trying to force the web to be an app delivery platform. We have bent over backwards to accommodate this. We have turned browsers into a giant pile of hacks essentially emulating their own operating systems. And for what? As soon as they're able, they say oh, the browser is a giant bundle of hacks now, let's implement our own app delivery system on top of it.
Next time we get a document delivery format and people start trying to make it something it's not, because oh gosh it's easier to install the app, we need to push back and say hey, maybe clicking a few buttons in an installer isn't the worst thing in the world.
So, because you don't want binary blobs to be deployed over the web, you would like users to download and install binary blob native applications... And that makes things better in what way, for whom, exactly?
Let's start with accessibility, because this is a field I am forced to be an expert in. Native "binary blobs" have access to the operating system accessibility APIs, and consequently any native app is a lot more likely to be accessible out of the box than something rendered to a canvas. People have spent literally decades building out APIs for the native platforms [0] [1] [2].
To think that a native app is equivalent to a canvas-rendered app is to not understand either.
it's viable to make accessible apps in DOM though - it's just canvas apps that can't be made accessible, and I agree with the GP that Google should not be trying to circumvent the DOM for the Docs interface.
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')`.
For starters, a binary blob on your computer can be prevented from "phoning home" to collect personal data much more effectively than a web app can. Additionally, the vendor is often forced to compete with their own old software because they can't always force you to run the newest binary blob. This prevents the wholesale loss of features from products you rely on at the whim of the vendor.
>
For starters, a binary blob on your computer can be prevented from "phoning home" to collect personal data much more effectively than a web app can.
In theory, it can be. In practice, the average user doesn't do a damn thing to do so, and installing a random native blob from the internet is far more dangerous than a webapp running in a browser sandbox.
> Additionally, the vendor is often forced to compete with their own old software because they can't always force you to run the newest binary blob.
This is also how we get people running years-old software instead of deploying security patches.
I understand that a power user may prefer these trade-offs. Most users are not power users.
Surely, you realize that docs needs to be connected to a server in order to perform it's basic use case of collaborative editing... Right?
You must also realize that an arbitrary native blob can and will happily connect out to whatever server it's authors want it to.
I can't say that 'there are a few techies who aren't happy that Google doesn't ship docs as a native application' is a very compelling reason for Google to try to change core web standards.
You know what I'm tired of? Slow apps. Google Docs is a great platform but performance has always been slow compared to native Office. I welcome this change. Draw the document quickly and make me more productive.
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.