[jokoon]

Burn the DOM with fire. I'm so allergic to it. I'd rather write my own 2D tile tree format, with a simple flex-like rendering layout, than to work with HTML and expect reliability. HTML was never designed for interactive applications.

The historic reality is that HTML served as a "backdoor"/gateway to let the linux community compete with microsoft: linux devs could ship their code for windows clients.

Now, HTML webapps cannot run properly on a mobile platform without depleting expensive batteries. So each mobile platform are making bucks on the back of developers who have to work twice as hard.

I have very high hopes that webassembly could somehow solve all those problems, but there are several problems:

* Not all browser vendors like WASM and I doubt that any WASM progress would be supported equally.

* WASM toolchains are not really mature for most languages. Compiler makers don't have a lot of incentive working with WASM.

* The DOM would still exist.

[chrismorgan]

No one has made anything as capable as the DOM.

It’s excellent for documents, and very capable for apps. Games and other intensely custom-graphical interfaces are really the only situation where it’s not great, and in that case you can drop into a canvas and/or SVG (SVG admittedly still being DOM, but not HTML DOM) with no difficulty.

HTML was not initially designed for interactive applications, but for many years has progressively been.

The DOM gets you things like support for accessibility tech in a way that few other technologies can rival; the only real defect it has is that it strictly uses a push model and you can’t query the screen reader—so you can’t do things like tweak things for particular screen readers (for good or ill), or skip parts of the accessibility tree for efficiency based on where the tool is looking at present, but must present the entire accessibility tree up front. But although this is limiting, there are also reasons why it is so, around privacy and robustness.

WebAssembly never had anything at all to do with the DOM, let alone replacing it.

[ajuc]

> I'd rather write my own 2D tile tree format, with a simple flex-like rendering layout, than to work with HTML and expect reliability.

I suspect you'd quickly find there's a lot more complexity there than you predicted.

Anyway - if that's what you want check out Qt + QML. You can do it badly, but when you use it well it's the best declarative UI framework I know.

[rektide]

what would hacker news here be helped by by removing the dom? do you think this website would be better with your solution? why?

[rektide]

fwiw there's almost nothing on the dom in this article.

I'm quite tired of the hot air pointless uneducated uninformed web bashing. I don't know why the web attracts such angry angry people but for all the complaining the grandparent post is about as real of a counter-idea to the dom as I have ever seen.

what we do with the web is often bad. fully agreed there are terrible experiences everywhere. but starting fresh, starting with different source materials, different rendering data structures: I don't think that targets at all what is wrong. so I just see such complaining as misdirected, complaints against a pop culture that instead focus on the tech that allows that pop culture. and I see it as sabotaging the best tech humanity has going, the freest most expressive most versatile data we've got that we often yes use quite poorly. but that we do get better at. that we continue to evolve our architectures of use around. and I see such grumbles as undermining this great thing, while supporting something limited & domineering & utterly in corporate control, something apart from the greater connected cyberspace: native (awful) apps.

[jerf]

I'd be interested in some people expanding on what they think is so "wrong" with the DOM, especially from the point of view of performance, and (emphasis on this!) what would be so much better. It's not that different than any other widget toolkit anymore, which have all largely converged on the same sort of model for the same reasons.

I can't think of very many things that affect performance in big ways. An explicit "I'm going to do a lot of things to the DOM here, please hold the reflows until I'm done, I understand that some of the properties may go out of date in the meantime" might be nice. (Perhaps it's a death-of-a-thousand-cuts.)

The API itself is a bit klunky, but the rough edges are easy to paper over with any number of libraries, and is hardly the world's first klunky-but-functional API to be so papered over by libraries that add no significant slowdown. (Note I'm not talking about "react" here, but just things that make the DOM API a bit less klunky. Thin little wrappers that mostly get JIT'd out.) Native XPath-like integration into JS would be nice, but honestly, that's going to be a net slowdown because people will do lots of slow, easy things rather than write the more tedious, but faster, DOM manipulation.

But just being klunky doesn't actually make it slow.

[lhorie]

It's not so much there being something "wrong" with it, it's more that there are trade-offs. Look, for example, at https://tc39.es/ecma262 (the JS spec) and try to jump around the page: you'll notice that it takes quite a bit of time for some things to render simply because the document is absolutely humongous. BUT, once it does load completely, you can insta-search it with ctrl+f, it reflows/wraps correctly in a mobile browser and and if you throw your iphone's accessibility feature at it, it'll read the document for you. Being able to google the thing in the first place is also due to ability to programmatically crawl the document and analyze its contents. These are important features that are usually forgotten by the people proposing that everything should be a thin bitmap buffer on top of raw hardware.

[yaccz]

> The historic reality is that HTML served as a "backdoor"/gateway to let the linux community compete with microsoft: linux devs could ship their code for windows clients.

lmao. sources?