You might want to build your WebApp in Canvas instead of HTML
hivekit.io
hivekit.io
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.
> for most web apps, you’re much better off with good old DOM elements. Take the humble <input type="text"> element, for example. With it, you get crispy rendering at any resolution, support for tab, focus, selection, mouse interactions and arrow key navigation, internationalization for right-to-left text and Asian compound characters, accessibility for screen readers…
There are a lot of comments in this thread excited by the idea of turning my web browser into a dumb frame buffer for someone’s home grown, laggy, half baked UI framework that cannot function on par with the DOM for hard technical reasons. I don't want to run software like that.
I've been working for a number of years to make the HTML canvas element more accessible for those situations where using a canvas element makes better sense (allegedly) than using standard tools - because there's always those special edge cases, and if people are going to use canvas elements then I want them to build them in the most accessible and responsive way possible.
I'll not spam my product, but as part of my work I have produced a webpage where I try to list the things a HTML canvas element needs to do to meet WCAG requirements. These are my own, personal views so challenging my claims is entirely justifiable, and correct!
https://scrawl-v8.rikweb.org.uk/docs/reference/sc-accessibil...
I also imagine this will be a big setback for web accessibility.
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?
The scrollbar is blocked on the bottom by the chat window. Keyboard navigation page up, page down, arrow up, arrow down only work if you are inside inside the answer window otherwise you get a totally different scroll behavior.
On Edge you can’t change anything of that per extension because MS block any change
Especially in the era of AI, performance has been thrown out of the window
I was using Entra and Azure the other day and boy are they slow and clunky.
> For most web apps, the DOM remains the better choice. It gives you accessibility, responsive layouts, text selection, input handling, and countless other features for free
I was thinking you could probably get a fair bit of accessibility by using <div>s for your text rendering- or by maintaining a separate, hidden outline of DOM elements mirroring what’s on screen.
Is there any analysis on the efficacy of this approach? This is always my first thought in these discussions. Performance of WASM with native text IO. Being fully "hidden" one could just use semantic elements, skipping most layout div's, maybe in turn reaping untold accessibility benefits?
Being such a simple idea I cannot believe that it wasn't tried and abandoned before.
For canvas rendering in general, this is essentially what Flutter and a lot of newer GUI frameworks like Composer Multiplatform and Rust based GUIs do. Accessibility is possible for these as there is semantic tree support but it's not as "free" as the DOM so it takes a bit more work.
Been thinking about doing a toy project where I try to build my own alternative to HTML/CSS that runs on top of Canvas, drawing inspiration from how Wayland is actually less abstracted than X11.
I've been tempted to do something similar for browser canvas, perhaps with some slightly different choices than he made. His approach uses a very elegant way of looking at things though.
Interactive Flash Banner Ads Animation from the 2000s https://www.youtube.com/watch?v=w0Lu8BsjvK0
It's a shame that this is what the web is trending towards with more and more enterprise interest in the internet.
Unity can literally deploy scenes to web canvases with its webgl target.
If you are going to use canvas, why not use the most extreme form of it with the most complete tooling available? You can put the universal render pipeline in anyone's browser in 5 minutes. These deployed web assets are surprisingly small if we are responsible with art.
Accessibility is even an option because we are leveraging a gigantic corporate engineering team and actually have time to try and solve this rather than reinventing basic layout and rendering concerns.
In 99.9% of the cases it's completely enough.
When you use canvas you're giving up on not just accessibility but also optimizations that the browser does for you transparently when you use the native render tree. There's no guarantee that your app will be faster in canvas, it could easily be slower. Do you really think you can beat the browser's C++ by writing code in a language that doesn't even have a native integer type? Perhaps you can, but your base assumption should be that you can't.
When you’re dealing with things like spreadsheet viewers, disengaging from the DOM for sighted users can actually make accessibility simpler.
Do you have any examples? In my experience, a lot of software written like this just doesn't work with screen readers at all.
This is only mostly true, and no justification at that. I’ll just quote myself from a couple of years ago <https://news.ycombinator.com/item?id=42253177>:
> Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications.
I haven’t ever examined Google Sheets closely, but it looks to use a similar approach, but worse in scrolling (it’s very obnoxious compared with native on my device—lags fiercely, and breaks inertia).
Excel I can’t comment on.
Docs should definitely have stayed HTML.
Sheets and Excel should probably be HTML, or possibly SVG.
For Hivekit’s scheduling interface as shown, I’d say most of the area should be HTML, but that I wouldn’t object to canvas or SVG for the centre area.
Now, for their reasons.
• Speed: at the level of complexity they’re talking about, this is flat nonsense. Yes, the browser does more than necessary, but a lot of effort has gone into making it perform far better than it has any right to, and DOM performance is not your bottleneck. (I mean by this that, if it looks like it is, it would be if you did the same thing with canvas too.) And as soon as it comes to things like scrolling, you cannot perform or behave as well as the browser, because the browser is a compositor and you can’t work at that level. Even in the rest, unless the entire thing is owned by a single small team skilled at saying “no” and at implementing everything from scratch rather than leaning on others’ libraries, your code is very unlikely to do better than the browser.
• Control: it undermines its own point completely by talking of scrolling. You must use real DOM for the scrolling, or else it will be horrible to use on a reasonably large fraction of devices. Note how the likes of Google Docs and Sheets use real DOM and render slices with the adding and removing and such that it criticises.
• Consistency: you only get this if you do all the text rendering yourself from first principles, which Google Docs and Sheets don’t do because it performs terribly. So no, this one falls flat too.
(I’ll continue more later, got to go again.)
> Take the humble <input type="text"> element, for example. With it, you get crispy rendering at any resolution, support for tab, focus, selection, mouse interactions and arrow key navigation, internationalization for right-to-left text and Asian compound characters, accessibility for screen readers… the list goes on.
This is a poor choice of example for “why wouldn’t you use Canvas”, because even pure-canvas apps will use a backing <input type=text> for text input (probably invisible, hopefully appropriately positioned), because that’s the most primitive thing there is in this way; you cannot emulate it.
—⁂—
The rest of the article is fairly reasonable, showing some of the important considerations and why doing it to acceptable quality is more complex than people often imagine, because you’re basically reinventing a sizeable subset of what the browser already offers; and you can’t do as good a job of it in various areas, and are unlikely to do as good a job in most of the rest.
I’d say: things like Canva and Google Maps should obviously use canvas; things like Google Docs and Sheets should almost certainly not. I see enough of their product to see why they would choose canvas, but I’m not yet convinced that HTML only wouldn’t have served them better, and I strongly suspect that, if not, HTML + SVG would have been a better choice than HTML + canvas (and I hope they’re not pure canvas, because that’s an irredeemably bad approach for the foreseeable future of browsers).