Why Google Docs, Sheets, and Miro render in Canvas instead of HTML
You might want to build your WebApp in Canvas instead of HTML
Google Docs, Google Sheets, Excel for the web, Canva, and Miro all render their core interfaces in Canvas rather than HTML. The author, who built a scheduling interface in Canvas, explains the trade-offs: Canvas offers speed, control, consistency, and portability, but sacrifices accessibility, text handling, and built-in input features. He argues Canvas is the right choice when your app is a spatial workspace with complex positioning, zooming, and many visual elements, and shares practical tips like managing render scheduling, layering multiple canvases, and handling pixel density.
So don’t choose Canvas simply because it sounds fast. Choose it when your interface no longer behaves like a document and starts behaving more like a scene.
- josephg
Please don't do this.
Native controls have dozens to hundreds of subtle UI interactions. Consider a text input element. On macos there are text shortcuts - cmd+A to select all. cmd+left / right to go to the next or previous word. Page up / page down. Home / end. Spell check. A right click menu with about 10 more options, including OS based text services. Tapping on a text input element on ios or android will pull up the native on-screen keyboard, configured in system settings. Every major OS version, the UI changes in small and subtle ways.
You simply can't reimplement this functionality in the web browser. Browser APIs don't let you intercept a lot of the keyboard shortcuts you need. You don't have access to macos text services, or the native iOS keyboard UI.
Some people try to reimplement this stuff in the browser, but it always feels horrible to use. Nearly native, but laggy. Nothing looks quite right. You can't select text on the page properly. Fonts render slightly wrong. I have muscle memory for keyboard shortcuts that don't work. I hate it.
- dinkelberg
The dev tools in the browser become much more useless when you draw everything in a canvas. It's gonna be sad when everyone starts using frameworks that draw on canvases. Arguably more sad than when Webassembly came. One could probably write new dev tools for those frameworks though.
I also imagine this will be a big setback for web accessibility.
- efficax
Not a word in here about accessibility, of course. If you’re blind you’re blind to the canvas as well without a lot of work, it’s much more straightforward to make the DOM accessible
- groomlake
I’m always curious how Google, Microsoft and Co. build their web apps - given that they need to work well on any computer, from a top-shelf speed machine to a potato with wires.
In my experience, Microsoft webapps (which now includes many of their desktop apps) are rather sluggish. Even the Copilot Chat website. How hard could it be to make a chatbox and a session transcript not be sluggish?
- lisperforlife
I call this the bluebox problem. Back when I worked for SAP there used to be this control called the bluebox control that embedded a browser (shdocvw) into a C++/MFC app. Almost every single annoying UI bug came from that control. I see the same now in the other direction. Every 5 years we come up with the bright idea to use browser as a distribution engine for a UI surface that is rendered by a box. This has historically never worked. I just wanted to recount applets, activex controls, flash, flex (also flash), silverlight, flutter ... and now this. The issue is developer tooling, screen readers, browser extensions and all the other small things that are difficult to account for.