Rethinking DOM from first principles • Hacker News Board

Re: Rethinking DOM from first principles

#151

Post by cosmic_cheese » Thu, Aug 07, 2025, 12:35 AM UTC

paulryanrogers wrote: post #150

cosmic_cheese wrote: post #148

Earlier quoted context omitted.

Personally, for something like this I’m not sure that getting consensus really matters or is even desirable (death by design by committee is real). Just pick a direction and go. If it’s sufficiently good it’ll catch on and blossom from there, if it doesn’t go back to drawing board and try again. The problem is that there aren’t even really any attempts out there. The closest as you say are web components, but they’re…

> ...if it doesn’t go back to drawing board and try again. My guess is that would put the burden of keeping up with evolving APIs on web developers and web companies. And there is a huge and very diverse ecosystem out there. Native app developers seem to be burning resources trying to stay in stores and working on modern devices.

The new APIs wouldn’t be for everybody in the early stages and that’s fine. It’s impossible to build something that everybody can get on board with from day one. There will be early adopters who are willing to pay the price of admission.

Staying in app stores in my experience has not been particularly difficult or resource intensive. If you stick to first party toolkits and don’t go nuts with custom widgets, maintenance is minimal and often you only need to compile against a newer SDK every few years. The horror stories are generally coming from projects with severe NIH syndrome and sometimes of users of cross platform frameworks.

Re: Rethinking DOM from first principles

#152

Post by mr_toad » Thu, Aug 07, 2025, 12:39 AM UTC

austin-cheney wrote: post #138

continuational wrote: post #34

Earlier quoted context omitted.

The reason working with the DOM directly is hard is that you have to implement arbitrary patching to go from one state to another. The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you. It's not irrational; quite the contrary.

Yeah, I prefer vanilla DOM and I don't have any problems with state. State is as ridiculously simple as storing state of user interactions to an object, saving that to somewhere like localStorage, and the applying it on page load. React makes this ant hill into a mountain of complication.

React isn’t about persistence between page loads. React is about declaratively declaring two different page states and “diffing” them so that only the diffs are applied to the DOM.

Storing the diffs to local storage is an interesting idea though.

Re: Rethinking DOM from first principles

#153

Post by mr_toad » Thu, Aug 07, 2025, 1:04 AM UTC

troupo wrote: post #58

austin-cheney wrote: post #17

Uggghhh, the article states correct facts about the DOM but grossly incorrect conclusions. Most developers have always feared working with the DOM. This irrationality is not new. I have no idea why, but tree models scare the shit out of college educated developers. That’s supremely weird because computer science education spends so much energy on data structures and tree models. It also makes the conversation about W…

> I have no idea why, but tree models scare the shit out of college educated developers. Very few people are "scared" of tree models. The problem of working with the DOM is that it's: - 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things - Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you…

[dead]

Re: Rethinking DOM from first principles

#154

Post by marcus_holmes » Thu, Aug 07, 2025, 1:24 AM UTC

This is satire, right? I mean, it has to be.

The author critiques a ~50-year-old set of tech that has been developed piecemeal over those ~50 years to cope with a vast array of different goals and priorities. And proposes their own toy tech as a replacement, with apparently no sense of irony.

HTML was never designed for web apps, but it powers billions of them. CSS was never designed for complex dynamic UIs, but it does the job. If you seriously think "hmm, well this is shit, I can do better" then I invite you to take a seat and actually look at what this shit tech is doing, and maybe step down the arrogance a bit.

The problem is, as always with tech that survives a few years, backwards compatibility combined with mission creep. The author ponders HTML6 removing some redundant stuff. The problem is that you can't remove or change anything because doing that would break 348574793 websites and the people who rely on that stuff working exactly as it does now will complain. Meanwhile people are demanding that they can build 3D models using the same stuff that was originally designed to serve static written documents.

And, just while we're there, the answer to replacing the DOM is not to implement it in shiny new browsers. The browsers aren't the problem, or a route to change. You'd need to get every single website to change. Even the ones written by the company owner's nephew, who then moved country and doesn't talk to his uncle any more, so the website is a bit outdated but no-one knows how to fix it any more. There are approximately 3498573495645 of those.

HTML, CSS, JS, SVG, the DOM, WASM, all of that is miracle tech. Learn from it, study it as an exercise in longevity. Instead of complaining about CSS, learn why it was designed that way, why that particular set of ugly compromises came about. I promise that every single part [0] of all of this tech was debated for weeks by a large room full of very, very, smart people who came up with this solution because it was the only way forward at the time.

And mate, have some humility.

[0] OK, the original first version of HTML was probably not this, and was hammered together by Tim Berners-Lee, who probably never imagined that this would happen to it.

Re: Rethinking DOM from first principles

#155

Post by lerp-io » Thu, Aug 07, 2025, 1:31 AM UTC

anyone had experience where assembly is not actually faster than optimized js when it’s clean like for example when working on preallocated memory in buffer because v8 optimizer is that good?

Re: Rethinking DOM from first principles

#156

Post by austin-cheney » Thu, Aug 07, 2025, 1:34 AM UTC

hinkley wrote: post #137

chrismorgan wrote: post #55

Earlier quoted context omitted.

> For WASM to become a replacement it would have to gain full DOM access to the containing page. To become a total replacement, as in no-JavaScript-at-all-needed, sure, WASM would need to be able to access the DOM. But to to replace JavaScript as the language you’re writing, you can easily generate DOM bindings so you trampoline via JavaScript, and people have been doing this for as long as WASM has been around. Givi…

> Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance. What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.

The point of WASM is a universal compile target that executes a sandbox. That is all.

The idea is that any application can be compiled to WASM and delivered via webpage instead needing to be installed to an OS desktop. Developers see something radically different because they want it to solve a different problem, but let’s remember it’s not about developers but portability and user experience for end users.

Re: Rethinking DOM from first principles

#157

Post by lmm » Thu, Aug 07, 2025, 1:42 AM UTC

skeezyboy wrote: post #23

lmm wrote: post #7

Earlier quoted context omitted.

This view is completely backwards and I'm baffled by its popularity. Given that even newspaper websites are now built as applications, we should accept that the web is an application platform (with one of those applications being displaying articles) and rework HTML as an application display language. And we need to start relying on JS more. (Specifically, we should reimplement most traditional HTML elements and CSS…

at that point just learn a programming language man. the inception like dreams within dreams within virtual machines running other virtual machines will never stop because CPU power will always increase

I know plenty of programming languages, I'm happy with them, what I want to cut out is the sub-Turing tarpit that is CSS.

Re: Rethinking DOM from first principles

#158

Post by lmm » Thu, Aug 07, 2025, 1:44 AM UTC

krapp wrote: post #76

lmm wrote: post #68

Earlier quoted context omitted.

> Why are newspaper websites, out of all the websites, the ones which should determine how we do things? My point is that if there was any category of websites for which a "document" model would work, it would be newspaper websites. When even those take an "application" approach, it's time to admit that the "document" model is a failure.

There is no "document" or "application" model, the distinction is mostly just vibes. News sites are meant to be read, therefore they are "documents." They are also applications, because all websites, even static ones, are also applications. Once you add hyperlinks and external resources, it ceases to be purely a document. Adding a script tag to an HTML page doesn't transform it from one to the other.

Agree that it's all vibes-based, but look at how the newspapers understand their own sites - in particular, what they consider to be an "article", how they edit those articles, and the pipeline from that to the article being rendered in the end user's browser.

Re: Rethinking DOM from first principles

#159

Post by skydhash » Thu, Aug 07, 2025, 1:55 AM UTC

morsecodist wrote: post #110

bloomca wrote: post #109

I've been looking at native development for quite some time now (WPF/WinUI/SwiftUI, starting with Win32 and AppKit), and honestly Web technologies are much better than that. The fact that it is cross-compatible is just a cherry on top. If finally WASM gets a cheap and easy way to manipulate DOM, I think even more stuff will move towards web tech like Electron and hopefully Tauri in the future.

I totally agree. I don't get why people feel so strongly that native apps are better. The web technologies we have are great both from a developer experience perspective and a UX perspective. People hate on electron apps but I think this is mostly due to bloat from electron. I hope Tauri closes the gap it's been great for me so far.

Things.app, Bear.app, and a few others from the macOS side are nice example of UX.

While the web can be great for RAD, the native side gives you raw control when you want it. And actual desktop UI widgets, like table, list, and windows.

Re: Rethinking DOM from first principles

#160

Post by skydhash » Thu, Aug 07, 2025, 2:03 AM UTC

austin-cheney wrote: post #156

hinkley wrote: post #137

Earlier quoted context omitted.

> Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance. What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.

The point of WASM is a universal compile target that executes a sandbox. That is all. The idea is that any application can be compiled to WASM and delivered via webpage instead needing to be installed to an OS desktop. Developers see something radically different because they want it to solve a different problem, but let’s remember it’s not about developers but portability and user experience for end users.

I always think of WASM as being like a C FFI. Something you reach out when your module is too slow by being JavaScript. Kinda how Python bind to almost every library in C and C++.

Not so usuful for CRUD, but imagine building some node based editor, you can out the solver in WASM.