Live data from Hacker News

Rethinking DOM from first principles

acko.net

141–150 of 234 posts

Re: Rethinking DOM from first principles

#141

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 require little to no JavaScript and can be skinned entirely with CSS. That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.

Re: Rethinking DOM from first principles

#142

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…

I recall making that point with Eich here on HN. His counter was that no one could know where it was going. And even today I think it's hard to get agreement on what the fundamentals should be. Web Components are slowly getting there I suppose.

Still, it's quite sad how long we had to wait for stylable checkboxes.

Re: Rethinking DOM from first principles

#143
post #102

Earlier quoted context omitted.

Yes, a terrible one. That's what the article is about.

What I mean is, I dont see why browsers even exist. There should be a singlular framework for creating desktop apps.

There is. It's called a "browser"

Re: Rethinking DOM from first principles

#145

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…

The problem is that DOM is absolutely inadequate for describing page layout, and even less so for Web applications. Incremental changes to DOM were meant to make it more suitable for this goal, but having inherently bad foundation didn't exactly help. I believe that some sort of a constraints language would've been a lot better at describing page layout. And stuff like Web applications simply shouldn't exist. These s…

So instead of writing an app once I can write it ten times once for each native platform.

I AM SOLD

Re: Rethinking DOM from first principles

#146
post #102

Earlier quoted context omitted.

Yes, a terrible one. That's what the article is about.

What I mean is, I dont see why browsers even exist. There should be a singlular framework for creating desktop apps.

Ah. One difference is a normal desktop can access a lot more or even all of your system. Otherwise cross platform UI toolkits exist: GTK, Qt, Swing, SWT, etc. They could be great but they aren't, not because it can't be done well just no one has managed to do it well. They could technically be sandboxed but they aren't, or not well. Java applets tried long ago and a lot of systems got owned.

You'd never design from the start the bonkers HTML/CSS, box model, and other junk we are stuck with, but browsers have a number of good aspects that you'd probably end up with in a complete redesign.

The problem is multifaceted. UI toolkits are very hard to do well (I have a lot of opinions on this, and my own crossplatform toolkit), even on a single platform. Just that alone is huge. There are basically no overall great UI toolkits, even if some have good parts. Even a theoretical great UI toolkit will have quite a task to achieve parity with what browser UIs can do.

If we could get past that (spoiler: we can't, no way in hell) then we'd also have to be willing to ditch all the legacy browser stuff to switch billions of users and devices to something new AND we'd still have many other big problems to deal with: getting the committee/everyone to agree without ruining it, security, privacy, etc.

We've accepted we can't really fix it, so the only thing we can do is keep extending it. That's how we got here.

Re: Rethinking DOM from first principles

#147

Google gets to decide what the DOM is and you just get to live with it

They’re possibly the most significant web-app developer, so if things were really that broken you’d think they’d be the first to fix it.

Also, didn’t they effectively invent rendering in canvas (for sheets) about 10 years ago? If they did that, but they still didn’t abandon the DOM, they might have their reasons.

Re: Rethinking DOM from first principles

#148

Earlier quoted context omitted.

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…

I recall making that point with Eich here on HN. His counter was that no one could know where it was going. And even today I think it's hard to get agreement on what the fundamentals should be. Web Components are slowly getting there I suppose. Still, it's quite sad how long we had to wait for stylable checkboxes.

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 still extremely primitive relative to something like AppKit or win32.

Re: Rethinking DOM from first principles

#149

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?

Re: Rethinking DOM from first principles

#150

Earlier quoted context omitted.

I recall making that point with Eich here on HN. His counter was that no one could know where it was going. And even today I think it's hard to get agreement on what the fundamentals should be. Web Components are slowly getting there I suppose. Still, it's quite sad how long we had to wait for stylable checkboxes.

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.

Post reply on HN