6 ms·

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>

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
    > The web implies hypertext, the web implies user-agents that fulfill the user's desired agencies. That's entirely valid for many things people put on the web, but clearly not all. A document editor is not hypertext with agencies fulfilled by the user-agent. The web now supports a wide range of user experiences, and the "text + links" model is great for a subset of those, but not all. The fact that some apps are moving to a different model to me does not imply any existential threat to apps/sites that do fit well as hypertext. I see a lot of comments in the thread as essentially arguing that now that UPS using jets to ship packages means that soon they're going to take our cars and bicycles away from us.
    - jl6 5y ago
      Just imagine the sheer glee on the faces of the marketing department when their SEO experts tell them there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. The web is about to get a whole lot more user hostile.
      - munificent 5y ago
        > there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. That was exactly true in the Flash days and yet it didn't take over the world or kill the open web.
        rektide 5y ago
        Flash was small & ignorable enough to block. Nothing significant was lost. The web was winning, easily. This is the return of Flash, except now, it's backed by Google.
        jl6 5y ago
        Canvas is more capable than Flash, it’s supported by everything already, it’s well sandboxed, it’s apparently faster than the alternatives, the technique in question now has the backing of a powerful industry leader, and the underlying technology is an open standard so it’s even got moral high ground. And it’s possible we only managed to escape Flash-hell thanks to the fortuitous self-interest of Apple, so let’s not be complacent by assuming we’ll escape the next trap. Having said all that, I actually like the idea of separating web applications from web documents and I don’t at all begrudge web application developers from doing what it takes to improve their applications. I just know it will be abused. The best I can hope for is that it leads to some re-focus on HTML as a stable and finished document language.
nothis 5y ago
And it puts the entire structure behind a giant blackbox. Yucky. As if fate tries to prove a point, I recently struggled with a random ass google docs document and just wanted to download and import to use in my own spreadsheet software. There probably would have been a Google Approved way of doing it but if there was, they intentionally made it hard. I ended up copying the HTML somehow. I guess that will no longer be possible in the near future.
- throwaway3699 5y ago
  File -> Download -> XLS
  - hjek 5y ago
    ... which is a menu item you can reach through the canvas rendered by a giant blob of non-free JS.
    - tomcam 5y ago
      Or through scripting
      - zo1 5y ago
        Assuming they allow you programmatic access to the elements inside their binary blob rendered in the canvas. My bet is they won't.
        cnity 5y ago
        They couldn't stop you: either the interaction is handled in JS (in which case you can programmatically call the JS) or it is handled in WASM (in which case the interaction is actually still handled in JS, and exposed WASM functions are called). In neither case can programmability be blocked.
- Grazester 5y ago
  I question if you even had such an experience or this is just a fud post because it is dead simple as was pointed out by a pervious posted...Too simple to have been missed
attilakun 5y ago
I'm not sure but what you are suggesting is not outside the realm of possibility. There are already projects like https://makepad.dev/ https://makepad.dev/ which implement their GUI on top of WebGL. (Which is arguably more challenging than implementation on top of Canvas 2D.)
- snak 5y ago
  That's amazing, the IDE itself and the shader preview running on a WebGL canvas. Thanks for sharing!
- ignoranceprior 5y ago
  Visiting that website made my laptop's fans start running.
  - danans 5y ago
    If you look at the bottom left of the screen, it is live compiling/rendering a 3D particle swarm animation while you edit the code, so really not so surprising that it makes the machine work a bit. On my laptop (a Core i7 Chromebook - fast but not crazy by HN standards) the fan runs for a half second at first load - presumably during the compilation step - then shuts off immediately.
  - skyde 5y ago
    try using a better web browser ?
- russellbeattie 5y ago
  Perfect example of the pitfalls this approach has. I'm on a Samsung Galaxy Tab S7+ and visited that site using Chrome for Android. I can't enter text as the on-screen keyboard is never activated. Easy to fix, but these are the sorts of edge cases a canvas-only solution is going to have to deal with.
- davb 5y ago
  I expected scrolling to feel janky and "non-native" but it was fine. Text rendering, on the other hand... it was a bit of a blurry mess, compared to Chrome's native rendering (on Ubuntu 21.04).
andruc 5y ago
Looking at the example document linked in the article, it looks like each page is rendered in its own canvas tag. Text selection and interacting with the content of the page seems to behave as expected.
pfortuny 5y ago
Yes, then you will need a unified approach to text editing, and another markup language inside.
- jmull 5y ago
  Ah, ffs, you're right. It's just a matter of time: we will have markup rendered by a UI framework into a canvas that is in an HTML document. I almost hesitate to write this, because someone will point us to where that has already happened, and then I'll feel a little sad.
pjmlp 5y ago
Basically yes, for example https://platform.uno/ https://platform.uno/
neurostimulant 5y ago
Yup, afaik Flutter web is already rendering its components in canvas instead of DOM [1]. Text selection works, but kinda jarring and opt-in instead of opt-out. If the developer forgot to enable text selection in an element then the user can't select and copy the text in that element at all. It might be an indicator that google will continue with this approach going forward. [1] https://flutter.dev/web https://flutter.dev/web
- swyx 5y ago
  so the bigger story is... is Google Docs switching to Flutter Web? is that what's going on here?
  - neurostimulant 5y ago
    Not necessarily. Only the text rendering is done in canvas, which indicates they don't switch to flutter because in flutter everything is in a canvas. But if google, a major player in w3c and whatwg, decides that they don't want to use dom anymore and go through a great length to re-implement a major feature in canvas, this might indicates that this approach is beneficial enough and might double down on this route in the future. If they simply dissatisfied with dom feature, they can simply influence the standard to make the feature they wanted happen like they always do. As to why they don't want to use dom and instead use canvas at great expense of re-implementing a lot of basic text handling and accessibility feature, one can only guess. My take is moving to canvas will be beneficial to google because they can effectively kill dom-based adblocker, so it's only logical to start experimenting with canvas-only web applications.
hajile 5y ago
VS Code did this years ago with their terminal. https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
augustl 5y ago
It already does. The old DOM renderer renders _everything_ by hand. Selected text are absolutely positioned divs, so is the cursor, etc. So switching to canvas is not a big change in that regard.

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
  > The web implies hypertext, the web implies user-agents that fulfill the user's desired agencies. That's entirely valid for many things people put on the web, but clearly not all. A document editor is not hypertext with agencies fulfilled by the user-agent. The web now supports a wide range of user experiences, and the "text + links" model is great for a subset of those, but not all. The fact that some apps are moving to a different model to me does not imply any existential threat to apps/sites that do fit well as hypertext. I see a lot of comments in the thread as essentially arguing that now that UPS using jets to ship packages means that soon they're going to take our cars and bicycles away from us.
  - jl6 5y ago
    Just imagine the sheer glee on the faces of the marketing department when their SEO experts tell them there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. The web is about to get a whole lot more user hostile.
    - munificent 5y ago
      > there is a technology that allows them to push pixels in peoples' faces while making it harder for users to engage in "unauthorized content use" and harder to block ads. That was exactly true in the Flash days and yet it didn't take over the world or kill the open web.
      - rektide 5y ago
        Flash was small & ignorable enough to block. Nothing significant was lost. The web was winning, easily. This is the return of Flash, except now, it's backed by Google.
      - jl6 5y ago
        Canvas is more capable than Flash, it’s supported by everything already, it’s well sandboxed, it’s apparently faster than the alternatives, the technique in question now has the backing of a powerful industry leader, and the underlying technology is an open standard so it’s even got moral high ground. And it’s possible we only managed to escape Flash-hell thanks to the fortuitous self-interest of Apple, so let’s not be complacent by assuming we’ll escape the next trap. Having said all that, I actually like the idea of separating web applications from web documents and I don’t at all begrudge web application developers from doing what it takes to improve their applications. I just know it will be abused. The best I can hope for is that it leads to some re-focus on HTML as a stable and finished document language.

nothis 5y ago

And it puts the entire structure behind a giant blackbox. Yucky. As if fate tries to prove a point, I recently struggled with a random ass google docs document and just wanted to download and import to use in my own spreadsheet software. There probably would have been a Google Approved way of doing it but if there was, they intentionally made it hard. I ended up copying the HTML somehow. I guess that will no longer be possible in the near future.

throwaway3699 5y ago
File -> Download -> XLS
- hjek 5y ago
  ... which is a menu item you can reach through the canvas rendered by a giant blob of non-free JS.
  - tomcam 5y ago
    Or through scripting
    - zo1 5y ago
      Assuming they allow you programmatic access to the elements inside their binary blob rendered in the canvas. My bet is they won't.
      - cnity 5y ago
        They couldn't stop you: either the interaction is handled in JS (in which case you can programmatically call the JS) or it is handled in WASM (in which case the interaction is actually still handled in JS, and exposed WASM functions are called). In neither case can programmability be blocked.
Grazester 5y ago
I question if you even had such an experience or this is just a fud post because it is dead simple as was pointed out by a pervious posted...Too simple to have been missed

attilakun 5y ago

I'm not sure but what you are suggesting is not outside the realm of possibility. There are already projects like https://makepad.dev/ https://makepad.dev/ which implement their GUI on top of WebGL. (Which is arguably more challenging than implementation on top of Canvas 2D.)

snak 5y ago
That's amazing, the IDE itself and the shader preview running on a WebGL canvas. Thanks for sharing!
ignoranceprior 5y ago
Visiting that website made my laptop's fans start running.
- danans 5y ago
  If you look at the bottom left of the screen, it is live compiling/rendering a 3D particle swarm animation while you edit the code, so really not so surprising that it makes the machine work a bit. On my laptop (a Core i7 Chromebook - fast but not crazy by HN standards) the fan runs for a half second at first load - presumably during the compilation step - then shuts off immediately.
- skyde 5y ago
  try using a better web browser ?
russellbeattie 5y ago
Perfect example of the pitfalls this approach has. I'm on a Samsung Galaxy Tab S7+ and visited that site using Chrome for Android. I can't enter text as the on-screen keyboard is never activated. Easy to fix, but these are the sorts of edge cases a canvas-only solution is going to have to deal with.
davb 5y ago
I expected scrolling to feel janky and "non-native" but it was fine. Text rendering, on the other hand... it was a bit of a blurry mess, compared to Chrome's native rendering (on Ubuntu 21.04).

andruc 5y ago

Looking at the example document linked in the article, it looks like each page is rendered in its own canvas tag. Text selection and interacting with the content of the page seems to behave as expected.

pfortuny 5y ago

Yes, then you will need a unified approach to text editing, and another markup language inside.

jmull 5y ago
Ah, ffs, you're right. It's just a matter of time: we will have markup rendered by a UI framework into a canvas that is in an HTML document. I almost hesitate to write this, because someone will point us to where that has already happened, and then I'll feel a little sad.

pjmlp 5y ago

Basically yes, for example https://platform.uno/ https://platform.uno/

neurostimulant 5y ago

Yup, afaik Flutter web is already rendering its components in canvas instead of DOM [1]. Text selection works, but kinda jarring and opt-in instead of opt-out. If the developer forgot to enable text selection in an element then the user can't select and copy the text in that element at all. It might be an indicator that google will continue with this approach going forward. [1] https://flutter.dev/web https://flutter.dev/web

swyx 5y ago
so the bigger story is... is Google Docs switching to Flutter Web? is that what's going on here?
- neurostimulant 5y ago
  Not necessarily. Only the text rendering is done in canvas, which indicates they don't switch to flutter because in flutter everything is in a canvas. But if google, a major player in w3c and whatwg, decides that they don't want to use dom anymore and go through a great length to re-implement a major feature in canvas, this might indicates that this approach is beneficial enough and might double down on this route in the future. If they simply dissatisfied with dom feature, they can simply influence the standard to make the feature they wanted happen like they always do. As to why they don't want to use dom and instead use canvas at great expense of re-implementing a lot of basic text handling and accessibility feature, one can only guess. My take is moving to canvas will be beneficial to google because they can effectively kill dom-based adblocker, so it's only logical to start experimenting with canvas-only web applications.

hajile 5y ago

VS Code did this years ago with their terminal. https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

augustl 5y ago

It already does. The old DOM renderer renders _everything_ by hand. Selected text are absolutely positioned divs, so is the cursor, etc. So switching to canvas is not a big change in that regard.