Rethinking DOM from first principles • Hacker News Board

Re: Rethinking DOM from first principles

#161

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

austin-cheney wrote: post #63

troupo wrote: post #58

Earlier quoted context omitted.

> 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…

This is exactly what I am talking about. All these excuses, especially about vanity, are masking behaviors. DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow. Chrome has always been much slower.…

"In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory."

When you profile something and you get "a billion per second" what you've got there is a loop where the body has been entirely optimized away. Presumably the JIT noticed you were doing nothing and making no changes and optimized it away. I don't think there's a single real DOM operation you can do in an amortized 3-ish CPU cycles per operation (2015 3GHz-ish CPU, but even at 5GHz it wouldn't matter).

That's not a real performance number and you won't be seeing any real DOM operations being done at a billion per second anytime soon.

Re: Rethinking DOM from first principles

#162

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

benoau wrote: post #75

7bit wrote: post #59

Earlier quoted context omitted.

As for the vertical centering, trying this 20 years ago, it was a pain in the ass. These and layouting in general got massively simplified in the past 20 years. Remember that back then, everything was cramped into tables? I do. So if someone tells me, "DOM, HTML and CSS is becoming more and more difficult" just tells me to ignore their amateurish and unfounded opinion... Hah!

20 years ago it was much easier, you could ethically use tables for layouts which semantically did not make much sense, but in terms of code structure it was very simple: this table is the full size of the page, this cell is the header with this height, this cell is the sidebar with this width, this cell occupies the rest of the space with content positioned in the middle, all expressible without any styling at all.

Not 20 years ago and not now because it makes no sense to blind people using screen readers.

And ~15 years ago a consensus formed that making separate sites for phones and other devices was not the way forward and tables are ill suited for responsiveness.

We've had CSS Grid for 7-8 years and Flexbox for longer, tables can be left for what they're good at, tabular data, not layout.

Re: Rethinking DOM from first principles

#163

Post by extra88 » Thu, Aug 07, 2025, 2:10 AM UTC

paulryanrogers wrote: post #149

socalgal2 wrote: post #94

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…

Is Flutter as accessible as HTML out of the box? Or even compared to Win32 or MacOS APIs?

Not out of the box and not even with effort.

Re: Rethinking DOM from first principles

#164

Post by skydhash » Thu, Aug 07, 2025, 2:11 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.

State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.

Re: Rethinking DOM from first principles

#165

Post by bawolff » Thu, Aug 07, 2025, 2:27 AM UTC

no_wizard wrote: post #101

ale wrote: post #49

Earlier quoted context omitted.

While the web has grown complex in line with increasingly complex applications, the platform is also undeniably bloated, precisely because every new feature (like HTML in Canvas proposal) has to be shoehorned into an already very fragmented puzzle. Backwards compatibility has become an idealistic badge of honor rather than a technical feat. I believe the article does a good job at getting into the technical parts tha…

It’s frustrating to me that we don’t have more directives. I’m simply spitballing however, here’s some examples: We have but why not add other doc types as time goes on? Instead of shoehorning features you could have a which would opt a web page into the ability to use newer features like newer elements or cleaner APIs There is also the “use strict” directive in JS (which any script tag with type=“module” runs in now…

But umm, why would you want that?

Javascript has "use strict" to disable the parts that fundamentally cause problems even if you don't use them.

What exactly is in html you want to disable here? There are features that maybe dont make sense but they are largely self-contained. Unlike in js you can simply not use them and its fine.

Re: Rethinking DOM from first principles

#166

Post by yyyk » Thu, Aug 07, 2025, 2:30 AM UTC

AshleysBrain wrote: post #48

It's easy to say "XYZ is dead, time to replace it with something better". Another example is the Win32 APIs are hideous (look up everything SetWindowPos does) and need replacing. In the real world though, backwards compatibility reigns supreme. Even if you do go and make a better thing, nobody will use it until it can do the vast majority of what the old thing did. Even then, switching is costly, so a huge chunk of p…

>Perhaps a new API with a compatibility layer on top is a good approach

The opposite would make more sense. Have a transpiler or something to the 'old' API (very natural, given it can grow with the new API and you don't have to implement the entire 'old' API), while new apps can slowly transition the 'new' API.

Re: Rethinking DOM from first principles

#167

Post by bobthepanda » Thu, Aug 07, 2025, 2:30 AM UTC

cosmic_cheese wrote: post #151

paulryanrogers wrote: post #150

Earlier quoted context omitted.

> ...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, maintena…

I mean, experimental APIs do get built this way, and some get adopted and some do not.

As it is, the vast majority of consumers want platform parity because nobody wants to feel left out of features on a second-class platform missing an API.

Re: Rethinking DOM from first principles

#168

Post by bawolff » Thu, Aug 07, 2025, 2:36 AM UTC

c-smile wrote: post #124

DOM per se, as a tree of elements, is not that bad. CSS is also not that bad in general. Their API is probably the problem. Not modular so makes the mess. Options to modularize them: DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for we may have separate "textarea" interface: element.tagName ... and the rest of DOM-as-a-tree methods ... element.textarea // specific interfac…

Why does it matter? Its not like im doing a for..in loop over Element objects.

Re: Rethinking DOM from first principles

#169

Post by postalrat » Thu, Aug 07, 2025, 2:36 AM UTC

wpm wrote: post #136

postalrat wrote: post #130

Earlier quoted context omitted.

And how about blind people, bots, accessibility in general? I don't remember java and flash handling different screen resolutions like desktop, tablets, and phones.

Yes, because the author of the comment didn’t explicitly carve out a moment to comment that Java/Flash were not great for accessibility, it must mean that in their hypothetical world where web applications that needed rich interaction and client side processing where based on Java/Flash type runtimes, it would have stayed shit for accessibility. I’m sure the person you were referring to doesn’t want to make the web s…

To them the web probably isn't much more than doomscrolling video content.

Re: Rethinking DOM from first principles

#170

Post by quotemstr » Thu, Aug 07, 2025, 2:39 AM UTC

cosmic_cheese wrote: post #141

strogonoff wrote: post #29

People often lament how DOM, HTML and CSS are becoming more and more complicated: the difficulty with simple and/or common tasks like vertical centering or virtualization, 600+ CSS properties, so many JavaScript methods, leaky abstractions, { contain: size }. I agree on many issues, but equally I struggle to imagine how it could realistically be not complex. If it was a result of a single very well thought through vi…

Much of this complexity comes down to primitives being too primitive for the use case of web apps. They’re fine for documents, but for web apps it’s like trying to build a building from grains of sand instead of concrete blocks. Rube Goldberg machines are unavoidable when you’re doing that. The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that req…

> a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS.

It already does literally that. Have you heard about ? These common widget libraries seldom last, and that's because people want to differentiate on style in ways that go beyond a CSS skin.