I like the DOM. I think people keep forgetting all the small details, like being responsive (working on mobile and desktop) and many other issues related to privacy and usability. IMEs, dictionaries, spelling correction, etc... All of these happen in text areas. If you implement things yourself, say in canvas on a webpage, you can't provide these. For example if I misspel somethng the browser can lookup that word in the user's dictionary but your page can not as looking through a user's dictionary would be a privacy issue.
That said, if you want a non-DOM framework, surprisingly Google already provides it. It's called Flutter and it has the option to use a canvas, no DOM. You can see a large complex example at
Go there and type in NYC. You'll see text and images popup over the earth, etc. You'll see a toolbar and menus and a status bar etc... Click settings. The stuff that appears is all canvas. Click the Data Layers icon. The stuff that appears as all canvas. I think they finally made the search input box an input element for the reasons above but the rest is canvas.
Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
Flutter is amazing exactly because it was a response to the problem of creating modern cross-platform apps for the modern zoo of hardware. The text typesetting engine from the 80s is clearly not a good foundation for it.
It's probably safe to say that the majority of the dev workforce in the last 2 decades started their career with learning HTML/JS/CSS stack, and it's understandable why they like it. It doesn't make this stack any better for creating apps, no matter how many abstractions on top we place.
Text selection is such a great example precisely because it is incredibly useful to have in many unexpected situations (and a great many more that should be expected), but UI designers as a rule do not think about these situations!
It is so bad that one of the most impressive operating system features to be added in recent years is the ability to select and copy arbitrary text from app UIs, using either accessibility APIs or (more recently) straight-up OCR (because of course accessibility is another thing UI designers forget).
It's not like adding text selection in native apps is even hard; it's just not on the radar, and never has been. The number of old-school apps that added some form of "open log file" to either support instructions or as an actual function in the UI instead of making error messages selectable / copyable is depressing; I've seen programmers spend more time mocking end users for not knowing how to take proper screenshots than it would have taken to implement selectable UIs.
...and by historical accident, this problem is now solved in the vast majority of new applications. A small mercy!
> Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
It's far from the only thing it has issues with; I've found obviously broken UI patterns within a couple clicks of opening Earth's map view:
- right click doesn't appear to work anywhere (except input boxes), even on elements that have direct equivalents in other Google sites (like the account switcher),
- when you click the account switcher, as long as its open, the rest of the site ignores the mouse events; attempting to drag the map screen doesn't close the switcher, hovering over buttons doesn't change the cursor etc.
I hate this and it's the default for a canvas app since the app would have to implement doing something on right click where as in the browser it's the default. Unfortunately, an HTML app can disable right click too :(
In fact, I hate that issue on all native apps. Things I want to select/copy/lookup are not selectable/copyable/lookup-able. As an example, Sublime Merge, a native app, quite often I want to copy a path but there is no option to do so. Every place that displays a path would need custom code (or a shared control) to make the path copyable. HTML doesn't generally have this issue as it's opt-out not opt-in for being copyable.
I'm not a fan of Flutter or other canvas bases sites. Emoji didn't work for like 3 years in google docs after their canvas change. It works now but not always.
It's worse too in that it doesn't matter if flutter eventually fixes these issues. Every app needs to be update. That's not true with HTML where the browser updates to support "insert password into input type=password" and it just works. Even better, an extension (1 password) can insert the password but it can't on a canvas based app.
That said, if you want a non-DOM framework, surprisingly Google already provides it. It's called Flutter and it has the option to use a canvas, no DOM. You can see a large complex example at
https://earth.google.com
Go there and type in NYC. You'll see text and images popup over the earth, etc. You'll see a toolbar and menus and a status bar etc... Click settings. The stuff that appears is all canvas. Click the Data Layers icon. The stuff that appears as all canvas. I think they finally made the search input box an input element for the reasons above but the rest is canvas.
Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.