I'm worried about screen reader compatibility. FAANG should push to support Lynx text browsing for blind users - and our bandwidth.
Google Docs will now use canvas based rendering
361–370 of 953 posts
Re: Google Docs will now use canvas based rendering
#362Earlier 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.
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 traditio…
Despite their shortcomings webapps won because they had a number of advantages that native lacked, most of all software distribution.
What has flutter to offer that a regular webapp lacks? (not performance, it seems)
Re: Google Docs will now use canvas based rendering
#363Earlier quoted context omitted.
DOM is just HTML/CSS. It's not a 'nightmare', it's actually a pretty good fit for the semantics of most UI's.
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…
I'm one of those persons that really want browsers to be viable options to building fully fledged applications but I sincerely like the core concepts of HTML and CSS.
I think the biggest issue is that things kept on being tacked on the primitive specification to solve ever evolving needs. The browsers themselves are written in languages that are meant to go fast - which is important for drawing of elements, rebuilding trees, etc - but not good for doing concerted async operations in a structured fashion. Just looking at those codebases makes you want to stab your eyes with a fork up to your brain.
In my, very valuable, opinion, a re-assessment of what HTML is (ignoring the name, and treating it as the language of the browser instead of hyper text) and what at web page can be - along with a browser designed to be multi-tabbed, async by nature, supporting advanced non-tree based layouts (maybe still trees, but trees that could be part of zindexed layers? detached layers that allowed for interaction handlers separate from the visual elements?) in a language that has tools to model those behaviours, could probably re-use all the lessons from HTML, CSS and JS apps.
Of course, it would still be like building everything again - but I'm not sure wasm/canvas blobs is a better solution long-term.
Re: Google Docs will now use canvas based rendering
#364Earlier quoted context omitted.
Its already possible to have server side rendering bake in ads on web pages, but just about nobody does it. I think the percent of people who know about pi-Hole vs the cost of server side rendering will always make client-side rendering the optimal choice for the people running the websites. They can block adblocking browser extensions, and that will be enough for them.
That's because the ad networks require a level of validation of their views that they prefer to have control over with javascript snippets or pixels. But it's technically a bit different, since an ad-blocker could still block those baked in advertisements while it's traditional web technology. If it's a binary blob rendered with canvas, that won't be true anymore, which I think was what the parent comment was getting…
> If it's a binary blob rendered with canvas, that won't be true anymore.
The request for the ads will either happen server side or client side. If it happens client side, it can be blocked at the network level by the pihole regardless of whether a blob or js script is making the request. The request happening server side is unlikely per my previous comment.
Re: Google Docs will now use canvas based rendering
#365Ever 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…
> I didn't expect the first move towards canvas-only rendering to be traditional wordprocessors.
It makes sense. Rich text editing on the web is a disaster.
Re: Google Docs will now use canvas based rendering
#366Earlier quoted context omitted.
I think this is the real reason for the change as well. A few years ago Visual Studio Code underwent a similar change where rendering the terminal moved from using DOM to canvas. I never noticed a huge difference between the two methods but I imagine using canvas gave them a lot more flexibility in addition to being more performant.
Here's an article that talks about the switch to canvas for VS Code. The "5 to 45" times faster part really sticks out to me. Kind of surprised it took Google this long to do this with Docs. https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
I personally didn't even bother checking out VS code because it was based on electron, and so I figured the performance just wouldn't be there because it's doing all of this awkward web stuff while trying to be an IDE.
I was completely wrong though. Using it, it really doesn't feel like a web app at all. It's really shocking and impressive. It feels like a text editor. Perhaps I should learn more about what they're doing.
Re: Google Docs will now use canvas based rendering
#367So 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?
Re: Google Docs will now use canvas based rendering
#368Earlier quoted context omitted.
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 traditio…
Despite their shortcomings webapps won because they had a number of advantages that native lacked, most of all software distribution. What has flutter to offer that a regular webapp lacks? (not performance, it seems)
Resume lines.
Re: Google Docs will now use canvas based rendering
#369Earlier quoted context omitted.
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.
I don't think that's true. Flutter is having a shitload of momentum right now. Just recently Canonical embraced Flutter as a first class option for building Wayland apps. Flutter is running on Google hardware such as smart speakers. Of course you also have the ever-looming Fuchsia OS that will have Flutter as the premier toolkit for apps. Etc. etc.
Like Ubuntu Touch?
Re: Google Docs will now use canvas based rendering
#370I 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…
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.