Hacker News Reader

Comment by ZuLuuuuuu | Hacker News Reader

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?

View on HN

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

so the bigger story is... is Google Docs switching to Flutter Web? is that what's going on here?

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.

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

Ran very smoothly for me. My only complaint is that right clicking doesn't offer a context menu, and that scroll bars don't allow snapping back to a previous position on Windows.

It would be interesting to see a project that allows integration of these native features into an otherwise canvas-like environment. Copying all the minutiae of OS features and quirks seems like an unending task.

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).

Ctrl+scrollwheel for zoom also doesn't work; this seems awful for accessibility.

Ran well for a few minutes on my iPhone, but froze up and then again after refresh. But very responsive and crisp. Obviously not yet optimized for touch devices; have to tap and hold the scrollbar to scroll, native iOS stuff didn’t come up after text selection. Very cool and while imperfect according to other comments, this is not bad at all.

Visiting that website made my laptop's fans start running.

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.

try using a better web browser ?

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.

That's amazing, the IDE itself and the shader preview running on a WebGL canvas. Thanks for sharing!

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.

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.

And it puts the entire structure behind a giant blackbox. Yucky.

Technically, sure, but the reality is that very few people are interacting directly with the HTML content of a Google Doc. What it does behind the scenes is really only relevant to the developers working on the app.

Well it also breaks all context menu functionality. No more right click -> copy text unless the website specifically implements it. Any custom context menu you use is now useless.

Personally I always use 'Right click -> Search..'

I think we can assume that Google Docs will implement right click -> copy text.

... in gray.

File -> Download -> XLS

... which is a menu item you can reach through the canvas rendered by a giant blob of non-free JS.

Or through scripting

Assuming they allow you programmatic access to the elements inside their binary blob rendered in the canvas. My bet is they won't.

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.

I think they already have with Flutter

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.

> 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.

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.

> 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.

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.

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.

yeah flutter's "web" target has a whole UI framework built inside the <canvas> tag

Specifically Flutter 2 which was announced recently and introduces the "web" target and is based on <canvas>.

Basically yes, for example

https://platform.uno/

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

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.

VS Code did this years ago with their terminal.

https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...

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.

Reply on news.ycombinator.com