I thought about the idea to do so because DOM rendering and the available ecosystem of libraries seems to miss a lot of my use cases.
As others already mention, you may have shortcomings of a non-DOM based UI in the following areas :
- Search engine crawling
- Accessibility using assistive technologies
- Text typing experience
Evaluate your use case and chances are that you do not need all of these. You do not require crawling ability by search engines everywhere. A password-protected admin area does not have to be indexed on Google. Regarding accessibility, at least make sure that widgets can be navigated using the keyboard using Tab and arrow keys, just like desktop apps have been doing for ages. Support for assistive technologies and text typing can be a different story, though, because of the variety of input methods (physical keyboard, on-screen keyboard for touch apps, pinyin / complex input methods for Asian languages...)
On the other side, here are the shortcomings of a DOM-based UI I found out regarding my use cases:
Different support of CSS properties over browser versions. If something useful comes out, for instance a new CSS property, I still need to wait for some months or years for the browser user base figures to catch up in order to make sure the new feature will be widely supported, or use hacky polyfills. If relying on a single UI library that is not dependent on browser CSS, I can update it as soon as it is released and start using it right away.
Scrolls by default: the assumption that everything is on a scrollable webpage. I have to fight against this system by strikes of
overflow:hiddenand similar. There are quirks everywhere, such as those 3px of overflow and some parasiting unwanted "giggling" scrolling for instance you spend hours hunting with the CSS debugging tools... Components that grow from the inside are able to "push the walls" and make their containers overflow in turn by default.The 300ms touch feedback delay on touchscreens, which is quite difficult to counter. Having a button that lights up as soon as your finger lands on the glass is still a struggle without hacking your way around, because the browser takes this time to evaluate if the gesture is a scroll... even on content that does not scroll. This is the very aspect that speaks out "sluggish" or "webview" to me, along with accidental selection of text labels or the browser context menu popping up on long press.
Most DOM UI libraries are opinionated for mobile "website" aspect and have limits on customizability. For example, using Bootstrap, you have to stick to those 12 columns and preset breakpoint sizes, spacings between components are fixed, you can choose sizes among a set number of options only. Else you have to get your hands dirty in CSS anyway or recompile the framework.
Widgets used to build a desktop-app-like UI are few and far between in the DOM UI library world. I mean data grids with resizable columns, tree views, draggable split panes, menu bars, toolbars that are able to hide some of their buttons as they are sized down and show a "more" menu automatically instead, among others. Some offering exists but they are paid and not cheap, while such components are available for free in some desktop UI libraries such as Qt.
Some of those aspects can be worked around by a bit of hacking, while others are more difficult.
Actually, the process of showing widgets in the browser without using the DOM and directly drawing those on screen is widely used in the world of game engines. For example, the Godot engine uses webassembly to render on the browser window in its HTML5 exports, and this includes a comprehensive set of UI widgets you can use.