> Take the humble 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 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).

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

Fastmail used to be based in Melbourne only, but after the Pobox merger it ended up with an office in Philadelphia too. No idea how the balance of things is between the offices now.

Various factors make me suppose this is low-effort vibe-coding, but I make this response anyway for the potential benefit of others.

• Modular type scales are harmful nonsense. I wrote about it in more detail a few years ago in https://news.ycombinator.com/item?id=36000879. They’re often presented as virtuous, but they actually produce arbitrary, bland, inferior results, mediocre at best.

• The range of base sizes is excessive. I think everyone should agree there’s no point in offering below 14px (8px!), and I wish everyone would agree beyond 24px is madness (32px!). Personally I recommend 16px on small screens, up to a maximum of 18–20px (or if you must, 22px) on large screens.

• Styling all heading levels the same is not a great idea. Yes, I know you have per-element overrides. Encouraging people to treat them the same is not wise. h1 especially is too often not treated differently enough from h2–h6. Sometimes I blame HTML for that, because despite its name, it’s not a heading, it’s the page title. Varying weight, and often varying size massively, between titles and headings and different-level headings, tends to be better than just using an anaemic modular scale with single steps. But there I go on that again…

• The auto-balancing button does some sensible things that show the nature of some of the other problems.

• Changing letter-spacing on headings (as is done by default) is a tad dubious.

• Changing letter-spacing on body text, and word-spacing on any text, should never be done; yet this option is offered.

• For “eyebrow” (interesting term, searching suggests it’s well-established yet somehow this is the first time I’ve come across it), 0.2em letter-spacing is definitely excessive. https://practicaltypography.com/letterspacing.html suggests 5–12% (0.05–0.12em). Incidentally, the per-element overrides doesn’t seem to know about that 0.2em, claims it’s at 0.

• I pressed random preset a few times, got some obviously bad results; e.g. Grand Hotel + Lato has a heading font with significantly smaller metrics than the body one, and where the negative letter-spacing is particularly bad, and where bold is not great. Significantly more than half the time, I strongly disliked the pairing. They felt completely random, even though it felt like half of the presets shown in the list were fine.

I’m very confident that if I looked further I’d find it riddled with errors. I just skimmed it and looked at a couple of the bits I’m most familiar with and immediately found notable errors.

When you parse a document or fragment that is in HTML syntax, the DOM representation is of elements in the http://www.w3.org/1999/xhtml namespace.

There is no difference.

> (Formerly in Israel, when a man went to inquire of God, he said, “Come, let us go to the seer”; for he who is now called a prophet was formerly called a seer.)

I love that one because it translates so well into English because we also have an older and a newer word for close enough to the same thing. Though when saying older and newer I should note that the words “prophet” and “seer” have been used consistently since the very first English translation, Wycliffe’s in ~1382. Maybe it’s more the feel of the words. (In Bible Gateway’s catalogue of English translations, only the CEV doesn’t use both of those words: <https://www.biblegateway.com/verse/en/1sam9.9>; I disqualify OJB as not English.)

That’s the only one I can think of off the top of my head that’s specifically about language, but there are plenty of others about changed customs over time, in Old and New Testaments.