Hacker News

The problem with doing apps on the web is the DOM. It’s wild how much complication browsers will add instead of just adding a new UI rendering method/substrate that doesn’t inherit 30+ years of legacy (remember web apps didn’t even exist for like 15 of those).

The DOM is a slow annoying pile when you want to make actual applications.

I wanted to implement a whole canvas native workspace, I started with a html only implementation and "fake canvas" approach but even for moderate number of panels (~50) the responsiveness dropped quite a lot. So I went with a new implementation with "real canvas" and worked out the panels/interaction.

In terms of performance this approach worked out much better (able to easily handle 1000+ panels/nested panels at 60+ fps) but the complexity goes very high in the implementation of each panel. As in I cant just use for eg a markdown rendering js library or any third party ui component. And frequently make a change would result in massive performance degradation.

https://canaster.in/

Currently I have text/markdown/image/audio/video and pdf panel (you can drag and drop files)

I wonder if i should take another go at it and implement using html-in-canvas api. Afraid of the api being not maintained if they dont see benefit or usage?

Discussion a year ago about html-in-canvas: https://news.ycombinator.com/item?id=44772177

(116 comments)

Sorry i am a web noob, but does this work recursively? E.g can you have html-in-canvas in a html-in-canvas ? :D

(May 2026.)

Related bunch of comments from that time: https://news.ycombinator.com/item?id=48201222

Hmm, not immediately clear how this avoids potential privacy leaks, such as drawing DOM hyperlinks to the canvas and then scraping their visited-status colour from the pixel data.

Or maybe I'm behind the times; I've not done serious webdev for a long time.

Gosh how much I'd love to have a separate accessibility and text layout api like skia has and ditch the dom completely

I discussed concerns about HTML-in-Canvas a while back as part of this post: https://acko.net/blog/html-is-dead-long-live-html/

Since then I've actually met these two and had to conclude that:

- They didn't have any use-cases in mind that weren't cosmetic

- They don't quite understand how being part of an advertising company shapes how they build and conceive of web tech

- They react quite poorly to reactions that aren't cheerleading

The answer for curved elements was handwaving and "just approximate it with flat projective transforms" which tells you this is not a serious attempt to expose mature UI internals, but just another shiny epicycle on the creaky leviathan that is the HTML5 web api.

The list of features that "automatically work" rests on assumptions that are only valid for minor visual adjustments. The moment you try to use HTML-in-Canvas as a more basic building block, a lot of that falls away.

e.g. Suppose I render a piece of text and then use that as a mask for visual effects. If the browser now draws a text selection highlight into that mask, the text becomes unreadable.

Wouldn't it make more logical sense to add canvas to html elements? I.e. checkbox.getContext("2d").fillRect(...)

This is the best news ever! I can't believe it was implemented in just one year after that blogpost... Boy I'm going to be spending good portions of my life making with this API...

And so, we have come full circle to macromedia flash

would you trust a web app drawn in a canvas to work with your accessibility tools, and why or why not?

I would use it to render HTML elements such as inputs or a website in videos. Even though HTML is powerful the control over every pixel is important for high quality videos.

Back in the WebVR days the sentiment was we can never do this because security.

In my experience with standards bodies/Chrome, anything outside of the owning company's product goals is "no, because security", and then then they flip-flop on that when the browser feature becomes a dependency for something an internal team is working on (which happened many times with WebVR, now WebXR).

So I'm curious what is Google working on that has this as a dependency, now that they've 180'd on it?

This solves for an important use case:

You've committed to building your app using canvas but realize you actually wanted the DOM. Now you can dig yourself deeper rather than fixing the original mistake!

...all the advantages listed under "The advantages of bringing the DOM to Canvas" apply to using the DOM generally.

Actually, I can see the case for having a primarily canvas-based app that, nevertheless, sprinkles in some DOM. It's the presentation here that rankles.

(Extra points lost for using "intractable" where interactive could be used; intractable isn't an English word while interactive is. Now, since I'm not a purist, interactable can be used as a noun in contexts like game programming that need such a word, since no such English word exists. But using it as an adjective only seems OK when not a native speaker and when not making an announcement. It just reinforces the impression that they don't know what they are doing.)

This is cool! Unfortunately a side effect is going to be more flashy vibe coded product landing pages adding expensive shader effects to all of their HTML. If you thought scrolljacking was bad, we're going to be seeing some interesting hover / mouse / navigation effects.

The thing about HTML in Canvas is that canvas should always have had the ability to add html to its content, and there would be no debate about whether it's a good idea or not.

Honestly, I think the push to constantly add browser features (and thereby expand the already massive web API) is misguided. This feature, in particular, seems like it should be solved with library, rather than by further bloating the browser.

If I put on my conspiracy hat, it looks like Google is pushing to expand the web API as a means to maintain its lead in the browser market by making it harder for other browsers (i.e. Firefox) to maintain feature parity.

Ok. Cool and all. But isn't the need for this a hack to begin with? Why isn't there some more unified graphics system by now? When it comes to presentation, the entire industry is fragmented that necessitates these things.

[flagged]

[flagged]

[flagged]

[flagged]

Okayy interesting