Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

321–330 of 953 posts

Re: Google Docs will now use canvas based rendering

#321
post #99

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…

Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every in-browser WYSIWYG text editor is a steaming pile of hacks. Some of them work well despite this, but, it’s a horrible set of code to maintain and very, very hard to make a good user experience. One of the very hardest things to do well in the browser, actually.

Thus I wouldn’t necessarily interpret Google Docs making this move as the start of an inescapable trend. It may be, or it may just be that certain kinds of applications (like Docs and Games) can work a lot better by providing their own rendering engine.

Re: Google Docs will now use canvas based rendering

#322
post #172

RIP web accessibility when everyone starts doing this to make ad blocking more difficult

(googler, opinions are my own, I know nothing about this project). I will bet that this will ship with accessibility support. If it doesn't, maybe they will launch with it being opt-in, as they flesh out a11y. But if I were to put money on it, it will ship with a11y functionality. The good thing here is that Google already has experience with accessibility on canvas UIs . Flutter, which uses canvas on web[0] and open…

Do you have an example? The demos here are not accessible at all:

https://gallery.flutter.dev/#/

Re: Google Docs will now use canvas based rendering

#323
post #99

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…

Yet another reason to use Pi-hole. The web browser is the wrong place to try and fight against this sort of thing. Secure your home network once instead of fighting an arms race on each device you have.

A proxy can do very little to actually block ads compared to what a web browser can do. Web browser _is_ the right place, or at least it is the only place where you can actually do something intelligent to block ads. For example, if you are blocking ads at a proxy, it is trivial for site owners to detect it and then your filtering proxy can literally do nothing to compensate. A huge chunk of all the filters in adblocking lists are basically to defeat anti-adblocking functionality...

Re: Google Docs will now use canvas based rendering

#324

Earlier quoted context omitted.

I for one would welcome the death of HTML and CSS. Unfortunately I suspect they will merely be re-used for this.

HTML and CSS are fantastic; when used what they were designed for. Document markup and display. I blame webapp developers for the scope creep and subsequent denigration of a perfectly reasonable set of standards.

HTML and css are great for making application GUIs. I used a bunch of frameworks like qt and Java and wpf and they were all worse than php, css and HTML.

Re: Google Docs will now use canvas based rendering

#325
post #99

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…

Google de-facto controls the browser but it doesn't control the OS, its motivation is absolutely transparent here: make the browser the OS. It even auto-updates transparently by default so Google can push its code almost live to its users.

As someone who always fought against the bloat of the web and reimplementing everything on top of HTTP and JS I feel a bit like an anti-atomic weapon activist who, upon seeing the mushroom cloud in the distance, can utter a final "see, I told you so!" before being demapped by a G-shapped shockwave.

The open web was fun while it lasted, but ads are more important.

Re: Google Docs will now use canvas based rendering

#326

Earlier quoted context omitted.

This is what Flutter on the web is, by the way. You can try it out here: https://gallery.flutter.dev/#/ and marvel at the impossible to select text, one of the many affordances violently excised here. If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.

It`s not slow on an old intel i3 laptop and on a motorola one phone. I keep seeing these comments about flutter web with different examples, they are never slow on my old devices. Also you can make the text selectable if you want to.

Just loaded it and it ran awfully. We all have anecdotal experiences and it doesn’t make yours any less valid than mine but it does point out that they don’t show much besides what you personally experienced.

Re: Google Docs will now use canvas based rendering

#327
post #99

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…

This is what Flutter on the web is, by the way. You can try it out here: https://gallery.flutter.dev/#/ and marvel at the impossible to select text, one of the many affordances violently excised here. If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.

I had these exact complaints about web apps many years ago, and I was dead wrong. Nobody cared that web apps were slow, had/has horrible UX compared to native apps, and feel janky by comparison. These demos elicit similar feelings. Now, they're not as fast as I like, but they feel better than most webapps already. (It reminds me of Flash, actually.)

If the Flutter dev experience is good enough, this will eat traditional web apps slowly. In a way, the web was designed for this sort of scenario: a delivery mechanism agnostic of the client implementation. We've gone from pushing server-generated HTML to megabytes of JS + SPAs, and now a WASM/Canvas hybrid seems inevitable.

It all comes down to how well these perform on mobile devices, what the dev experience is like, and how the end product feels. There's still a lot up in the air, but, I'm honestly impressed with the progress shown by Flutter here. There's still a host of considerations unaddressed (including accessibility) that I hope they have an approach for.

Re: Google Docs will now use canvas based rendering

#328

We are working on a full-featured Google Docs alternative - 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 dir…

How do you deal with the fact that fonts render differently on different platforms and it might look off on one of them, because the user isn’t used to the Canvas font rendering? Or is this not an issue?

Re: Google Docs will now use canvas based rendering

#329
post #77
post #43

Earlier quoted context omitted.

Microsoft Word, Pages and Open Office don't seem to be bottlenecked by rendering performance like Google Docs. Perhaps the browser is the wrong platform for document editing.

It was indeed a very strong marketing move for... decades to convince people, like smart people, that document editing can be a web-based thing. Actually, now that the browser is so ubiquitous that GUIs sit on top of it (think Electron), then is time to ask the very obvious question - since everyone seems to agree that universal GUI is needed (proof: the browser) then is the browser the right universal GUI? Not being…

I feel the need to argue that the browser is not the browser engine. An app sitting in a chrome tab is significantly different than an app built on electron, they just share some rendering code paths.

Electron apps have shown that you can use a browser's rendering engine to make high quality apps distributed on multiple platforms. They also have the benefit of persistence, filesystem access, hooks into native code should you need them (not WASM - mind you), you can implement true multithreading and explicit SIMD optimizations. You don't have memory limitations, and you don't have to worry about browser sandboxing, malicious or well intentioned extensions that break the experience, etc.

The browser is not the same platform as electron. I would guess that Google Docs would function much better in electron than on the web.

Re: Google Docs will now use canvas based rendering

#330

Earlier quoted context omitted.

(Un)folding a 100+ comment subtree is kind of slow, don't you think?

Same experience on my Android phone. I just tried to unfold 75 comment, it has a noticeable latency in both chrome and firefox.

Same here, just this comment's tree starts to have some perceptible latency on my one+ 8 pro (which should be pretty powerful. In contrast I have some Qt apps where unfolding trees with tens of thousands of nodes is instant.
Post reply on HN