Google Docs users, you are on notice: Code rewrite may break browser extensions
- Reference: 1620887051
- News link: https://www.theregister.co.uk/2021/05/13/google_warns_docs_rewrite_will/
- Source link:
In a [1]blog post on Tuesday, the Chocolate Factory said it plans to move Docs from HTML-based rendering to Canvas-based rendering "to improve performance and improve consistency in how content appears across different platforms."
In so doing, there may be casualties. Chrome extensions that interact with Google Docs, for example, may break.
[2]
[3]
[4]
"Some Chrome extensions rely on the way the backend of a Google Doc is structured or specific bits of HTML to function properly," the ad giant explains. "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."
[5]Maximiliano Firtman , a mobile and web developer and author, told The Register he expects problems with extensions and accessibility as a result of the rendering transition.
"For example, I use Grammarly and I understand it won't work as easily now, unless they provide an API for extensions," he said. "I haven't tried the new version, so I don't know how accessibility works on the new system. I expect Google to cover that at least. It's true that HTML is limited for doing some things and other Google products such as Flutter already use Canvas as the rendering engine when HTML can't solve a problem easily."
Performance
The [6]Canvas element provides a way to create bitmapped images in the browser; it offers better performance than HTML-based (DOM-based) rendering in part because it supports hardware acceleration. Google's cross-platform development framework Flutter [7]takes a similar approach , rendering applications using its CanvasKit API to take advantage of speedy graphics technologies like WebGL and recent innovations like WebAssembly.
Microsoft's Visual Studio Code, which is based on the Electron web framework, [8]shifted its integrated terminal from HTML-based rendering to Canvas-based rendering in 2017.
[9]
"In some cases, composing elements and doing a layout could take longer than a frame (16.6ms) all by itself, which is unacceptable if we want to maintain a smooth 60 frames per second (FPS) in the terminal," explained Microsoft software engineer Daniel Imms at the time. "The solution for this was a new Canvas-based rendering engine."
The transition worked out well for Microsoft: Imms reported that rendering benchmarks for VS Code's integrated terminal showed improvement ranging from 5x to 45x faster.
In an email to The Register , Steve Newman, founder of [10]Scalyer (recently acquired by SentinelOne), said while he couldn't say for certain whether Canvas-based rendering will really improve performance, he finds the claim quite plausible. "Also, conceivably, I could imagine it might be more robust (eg, across browsers) or more flexible in terms of being able to accommodate new rendering effects," he said.
[11]
Newman was a Google Docs tech lead more than a decade ago and left the company around the time Google was rolling out [12]a major DOM-based rewrite of the app.
[13]Google's multi-platform app framework Flutter reaches version 2, expands to the web
[14]'It's where the industry is heading': LibreOffice team working on WebAssembly port
[15]HTML5 may as well stand for Hey, Track Me Longtime 5. Ads can use it to fingerprint netizens
[16]WebAssembly: Key to a high-performance web, or ideal for malware? Reg speaks to co-designer Andreas Rossberg
A common concern as web apps implement technologies that are less user-readable (and user-alterable) than traditional HTML, CSS, and JavaScript is that the web platform becomes less open. There are certainly examples of that: Facebook [17]obfuscates its webpage code to stymie client-side ad blocking; websites have so much JavaScript, much of it related to ads and tracking, that it is common to minify (compress) web code to hit load time targets; proposals like Google's Web Bundles have been [18]criticized as anti-web; and WebAssembly bytecode, while it may be fast, isn't easy to decipher.
Newman, however, doesn't see Canvas-based rendering having much to do with source readability. The trend toward less easily viewed source code is real, he said, "but it seems orthogonal to Canvas versus DOM."
"If there are third-party tools that are hacking their way into DOM elements to interact with Docs page elements, then yes, this probably makes their life harder," he said. "But my perspective would be that in the context of a rich application, that sort of integration is always going to be a rickety thing at best unless it's explicitly designed for, via either an application-specific API or something like COM. It's just not feasible to get that kind of integration 'for free' using a base platform (HTML + JS + DOM) that wasn't designed for it."
Feross Aboukhadijeh, an open-source developer and co-creator of [19]Wormhole , told The Register that word processors have very specific requirements that don't exactly align with the capabilities of the DOM. "It seems the Google Docs team realized this and was able to eke out better performance by dropping to a lower level by using Canvas and perhaps WASM as well," he said.
A website like Google Docs was probably never going to be a simple HTML website that a beginner could 'View Source' on to learn about how it was built
"I'm an advocate for simple websites built with plain HTML, CSS, and JS. There's definitely a trend of new websites being built with complicated technology where simple technology would have sufficed, but a website like Google Docs was probably never going to be a simple HTML website that a beginner could 'View Source' on to learn about how it was built."
Aboukhadijeh described the web as simultaneously a simple document viewer and a powerful application runtime.
"For content websites, there's still a huge benefit to keeping code readable and understandable – to help beginners learn but also because a simple HTML website will always perform better than a JavaScript-heavy behemoth," he said. "But for a full-featured application like Google Docs, it's inevitable that the code will get to a point that a casual observer can't simply 'View Source' and learn anything meaningful."
These capabilities, he said, entail trade-offs that have implications for performance, accessibility internationalization, right-to-left language support, and browser extension support. "It seems Google weighed the trade-offs and decided that performance was the most important concern," he said. ®
Get our [20]Tech Resources
[1] https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YJz4wEaFsC-BZIfg1dccIQAAAFM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YJz4wEaFsC-BZIfg1dccIQAAAFM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YJz4wEaFsC-BZIfg1dccIQAAAFM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://firt.dev/
[6] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas
[7] https://www.theregister.com/2021/03/03/google_allinone_app_framework_flutter/
[8] https://code.visualstudio.com/blogs/2017/10/03/terminal-ren
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YJz4wEaFsC-BZIfg1dccIQAAAFM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://www.scalyr.com/
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YJz4wEaFsC-BZIfg1dccIQAAAFM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[12] https://www.networkcomputing.com/data-centers/rewrite-google-docs-takes-microsoft-office-head/page/1/0
[13] http://www.theregister.com/2021/03/03/google_allinone_app_framework_flutter/
[14] http://www.theregister.com/2021/02/16/libreoffice_team_working_on_port/
[15] http://www.theregister.com/2018/01/17/html5_online_tracking/
[16] http://www.theregister.com/2020/01/17/webassembly_key_to_a_highperformance_web_or_ideal_for_malware/
[17] https://www.bbc.com/news/technology-46508234
[18] https://brave.com/webbundles-harmful-to-content-blocking-security-tools-and-the-open-web/
[19] https://wormhole.app/
[20] https://whitepapers.theregister.com/
Re: What would be nice
If you bothered to read the article you'll notice that is one of the reasons they're switching to canvas rendering.
Re: What would be nice
Bit harsh, I read the article reasonably well it does come over mostly concerned with performance.
Speed optimizations ARRGHHH DANGER!
This is the same chocolate factory that removed 'destructors' from Java, the garbage collector no longer collects all the garbage, and finalize() is never called and so lots of cleanups never happen because an object never gets told its done with and never gets freed.
All to make the garbage collector a bit faster. Oh boy, if you see them optimize for speed RUN AWAY!
Android is leaking bitmaps
finalize()
{
myBitMap.recycle();
}
Leaking handles, leaking resources, leak networks, leak leak leak.
It even leaks heap memory that the garbage collector doesn't know about, because, for example....
finalize()
{
CacheMat.delete(m_id);
}
...because some heap isn't reference by an object but rather an id and the garbage collector is ignorant of such complex relationships.
My god this is incompetent shit. Undermining the basic smartpointer system that an OS is built on to make a badly designed garbage collector run a little faster, by not collecting all the garbage.
That's not chocolate Google is shovelling. They are a shark-jump company, and if you want to build you work on their turds, be sure to grab an Android 8 tablet, play with apps, like YouTube for a few hours and realize it works. Then try the same tablet upgraded to Android 9 or worse Android 10..... see how it slows down?
This is Google now.
I have to restart activities daily, and reboot tablets weekly. Restarting the activity daily forces the graphics heap to be garbage collected. Rebooting* the tablet weekly, forces the service's heap to be garbage collected. Not using Google crappy incompetent products at all, forces Google's developer department to be garbage collected.
* I can't even exit the service and restart it again on a scheduler, I have to do a full reboot, because since Android 10, that service, even a foreground one, cannot start an activity. They (i.e. morons shoveling shit) suggest using notifications, having already mangled notifications.
So, an example use case, a background service spots a problem on a server that needs fixed immediately, can it pop up a dialog and get them to fix it? NO, because someone in Google decided that would be too distracting. Even if the user chose that software for that purpose, the shit shoveller knows better than the user and developer.
Pardon my angry rant, but I don't apologize for its underlying message. Do not use Google products expecting the same level of competence you recall from the past. This is not that Google.
Re: Speed optimizations ARRGHHH DANGER!
I agree. Google is terrible at removing / lockdowning / changing things on Android and youtube without the option / API to revert it.
I didn't know about the garbage collection, but I'm well aware of access to things being removed with no corresponding permission added to re-enable it. They've long ago dropped the pretense of being developer friendly, and now just want to make a consumer iPhone clone.
More and more things need root because either Google "no longer wants you to do that" or they are tightening up the underlying OS without adding an appropriate permission controlled API for apps that need them.
Hello?
"....to improve performance and improve consistency in how content appears across different platforms ."
It is appearance consistency that is the requirement driver here. That's the brass ring for document renderers. You're going to get want you want (eventually). Using canvas is the means, the speed up is a bonus.
You get want you want. Other people get features removed.
While I can appreciate why they'd want to be very particular with text placement by using lowest-level code, not having a text-based representation is taking away the ability to extend Docs using add-ons. It is as though they were pulling rendering back under the OS covers - a form of obfuscation.
One browser to rule them all
and the next step is that Google Docs will only work properly in Chrome.
Google's developing a monopoly Microsoft could only dream of 20 years ago.
Re: Google's developing a monopoly
That's why some of us try really hard to have nothing to do with Google. Google is EVIL through and through (along with the likes of Facebook).
Google's developing a monopoly
I recently moved to helloSystem, and when I found out that Google doesn't support the Falkon web browser, I installed LibreOffice and alpine mail client. At first I was going to try with Firefox, but after a lot of thinking my answer was "I don't need any more of their crap, so why bother?"
Time to split the "browser"
So eventually browser have to use the same techniques operating system have been using for ages, if they want to deliver really usable applications.
Maybe it is time to split the "browser" into a document viewer and and application framework? So maybe we could have dialogs that could be moved around the screen again, and not confined to a "browser" window, and often not moveable at all, like in 1980?
But keep on reinventing the wheel, Google & C.... maybe in another decade or so web application will be where native applications were thirty years ago. Maybe if less time had been spent to find new ways to steal user data and behaviours, and used to develop useful application, we would have had something better already.
Re: Time to split the "browser"
keep on reinventing the wheel
Minicomputers started off as relatively light-weight alternatives to mainframes and then gradually morphed into their equivalents. PCs started out as smaller versions of original minicomputers and gradually acquired all of the characteristics of a "modern" (c 1968) time-sharing system. Browsers started out as simple document viewers and you can now boot operating systems in them.
Unfortunately, the history of computing is to keep reinventing the wheel. Even more unfortunately, the wheel we have doesn't usefully define the security principles or protection domains required to secure today's remote application model (hence the constant breaches) and the universal application front-end is still a grotesque hack (a document viewer twisted into an interactive UI).
It is rather depressing that there has been so little effort over the last 10 years (when it would perhaps have been easier, before there was so much investment in the status quo) in addressing these fundamentals and so much effort devoted to inventing "new" languages and "new" coding frameworks, none of which materially moves us far forwards.
But maybe we're just destined to keep pushing that rock up the hill.
Re: Time to split the "browser"
I specifically meant to write "principal", not "principle". The hazards of [1]relying on a spell-checker .
[1] https://twitter.com/DavidHerdson/status/1392458661260402688/photo/1
"the history of computing is to keep reinventing the wheel"
There's a little difference when you start with a little wheel because the computing power is not there at an affordable price, and when you give the user a "free" square wheel badly designed because in the meantime you can steal their data - and user fall in the trap of the "free" wheel and for reasons I can't understand fully adapt to use a square wheel with all of its bumps.
Now probably they will deliver a pentagonal wheel, which may be somehow better, but still far from a round wheel. And that's because they need to stubbornly mix contents, applications, and data slurping - since all their money come from the latter. So the problem is not only they are reinventing the wheel - it's how much time they're taking to reinvent it because the wheel is just the decoy for the users' data.
Re: Time to split the "browser"
"Unfortunately, the history of computing is to keep reinventing the wheel. "
Well maybe, but to me it looks more like "gilding the lily" or perhaps more appropriately "putting lipstick on a pig".
There does seem to be a tendency for IT companies, once they have a foot in the door, to try to get a lock on their consumers so as to extract high rents and charges.
Personally I avoid the likes of Google, Amazon and Apple as much as I can, treating them like an infection and sanitising my systems after I use any of their services.
Re: Time to split the "browser"
IMHO the modern browser is too powerful. Found this interesting read...
Attacking the internal network from the public Internet using a browser as a proxy.
https://www.forcepoint.com/sites/default/files/resources/files/report-attacking-internal-network-en_0.pdf
We have shown a chain of attacks that can all be made from the public Internet, even in face of a
firewall: via a victim browser you can look for hosts and open ports on the internal network, fingerprint
the open ports and finally exploit them. The only security issue needed for this attack chain to work is
that the service to exploit is vulnerable to CSRF. Other than that, every step of the attack relies on things
working as intended.
Chrome?
Well there's your first problem.
Re: Chrome?
Remember when Chrome was the lightweight, nimble alternative to moribund Firefox?
What would be nice
Is that instead of worrying about rendering speed, they consider caring about rendering accuracy.
The Android app in print preview mode, the website editor, and the PDF that gets generated when you export or print...
...are all different . From things lined up using tabs to where page breaks happen. Essentially any of the "your page will look like this" views are broken, because, no, your page doesn't look like that.