Although it uses more HTML and CSS than some similar things, I don’t think it’s fair to call it “plain HTML + CSS”, because it displays more functional characte

Although it uses more HTML and CSS than some similar things, I don’t think it’s fair to call it “plain HTML + CSS”, because it displays more functional characteristics of the pure canvas approach (where you throw away just about everything the browser gives you and start from scratch). My three primary heuristics for proper behaviour are: (a) using browser scrolling (the web doesn’t expose the right primitives to make a scroll-event-based reimplementation anything but bad, barely noticeable in some configurations but painfully broken in some of the most common configurations); (b) using browser text rendering (strongly preferably by DOM nodes, but even canvas plus fillText can be acceptable); and (c) handling links with real <a> elements (no alternative can provide the same functionality). Broadway fails all three of these (reimplementing scrolling, rendering text on the server and sending images, and I think actually locking up when you try to click on a link). It also fails my fourth and fifth tests, which are (d) handling text input properly (it looks like it just uses key events, not even a backing <input> or <textarea> or contenteditable, so IME composition fails completely and keyboard navigation will presumably be GTK rather than native); and (d) having a meaningful accessibility tree (preferably backed by normal DOM stuff, but not necessarily; I place this one last despite its importance because it’s likely to be more retrofittable than the others, though it’ll still generally be hard). I’d count Broadway as suitable for tech demos and for personal use where you know you don’t mind its limitations, but not for any sort of public deployment. It’s basically just an RDP/VNC sort of thing, with a smattering of DOM use. (Also remember that’s how it works—the code is all running on the server.)