Live data from Hacker News

Rethinking DOM from first principles

acko.net

41–50 of 234 posts

Re: Rethinking DOM from first principles

#41

What needs to happen is that HTML needs to go back to being a mark-up language, and the web needs to stop trying to deliver an application-level implementation for every single website. And we need to stop relying on JS so much.

I wrote this last week: > We spent a decade rebuilding the browser by hijacking routing, manually syncing state, rebuilding forms and transitions in JavaScript to match native app expectations. Now the browser has caught up. It's time to stop the hacks and build on the web again, but properly. We've been "holding the browser wrong" for the past 10 years.

None of what you wrote changed in the past 10 years. You still need to do all of that for app-like behaviour.

Unless you're arguing that we should stop cramming app-like behaviour into a system that doesn't support it. Then I'm with you.

Re: Rethinking DOM from first principles

#42

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…

> I struggle to imagine how it could realistically be not complex.

Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM, stdlib, bytecode, RPC, UI framework and standard library of controls, ... And "Web for web pages" which was a solved problem pre-HTML5 days.

Java and Flash (although very problematic from a security point of view) were probably better bases on which to build "Web for applications" than HTML5+/CSS3+/JS/WASM will ever be, but it was intolerable for Google/Microsoft/Mozilla to hand the keys to Oracle/Adobe for that. It's all politics, and it's all worse and more complicated and more inefficient as a result.

Re: Rethinking DOM from first principles

#43

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…

> Browser makers have refused to do that for clear security reasons. Because only javascript should be allowed to screw up that badly.

some of the worst dom api were designed with java compatibilty in mind

Re: Rethinking DOM from first principles

#44
post #12

Earlier quoted context omitted.

That's because you're looking at it from the perspective of what the developers of those news websites want, rather than what the users of those news websites want. The users want to get a document , not an app. That's what the web was made for, documents.

The users want to read an article, I'm not sure the average user really cares if it's delivered as a document or an app

Those apps were the article is hidden between ads and newsletter/subscription pop-ups?

The apps are mire likely used to hinder ad blockers than benefit the reader.

What feature of an article needs an app?

Re: Rethinking DOM from first principles

#45
post #42

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…

> I struggle to imagine how it could realistically be not complex. Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM, stdlib, bytecode, RPC, UI framework and standard library of controls, ... And "Web for web pages" which was a solved problem pre-HTML5 days. Java and Flash (although very problematic from a security point of view) were probably better bases on which to build…

Nobody would be using webpages version and everybody would be using app version.

Re: Rethinking DOM from first principles

#47
post #42

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…

> I struggle to imagine how it could realistically be not complex. Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM, stdlib, bytecode, RPC, UI framework and standard library of controls, ... And "Web for web pages" which was a solved problem pre-HTML5 days. Java and Flash (although very problematic from a security point of view) were probably better bases on which to build…

[dead]

Re: Rethinking DOM from first principles

#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 people just won't. Now you have two systems to maintain and arguably an even bigger mess. See Win32 vs. WinRT vs. Windows App SDK or however many else there are now.

So if you're serious about improving big mature platforms, you need a very good plan for how you will handle the transition. Perhaps a new API with a compatibility layer on top is a good approach, but the compatibility layer has to have exactly 100% fidelity, and you can never get rid of it. At the scale of these platforms, that is extremely hard. Even at the end of the day, with a huge compatibility layer like that, have you really made a better and less bloated system? This is why we tend to just muddle along - as much as we all like to dream, it's probably actually the best approach.

Re: Rethinking DOM from first principles

#49

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…

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 that are in fact not so remarkably robust, despite the web's organic growth. Even a bonsai tree needs to be pruned every once in a while. And while there will never be One Correct Way the way we engineer interfaces have converged a lot since the days of Flash meaning we can at least move the conversation forward in the Mostly Agreed Upon Way.

Re: Rethinking DOM from first principles

#50
I think for a system that can basically do EVERYTHING, HTML is quite well designed. And I think keeping backwards compatibility for SO long is a big achievement and a good thing.

I also think that if we could roll back time and had the knowledge of today, instead of fixed elements with user-agent styling and hard-coded restrictions, I would've crafted a system of arbitrary nodes that can have modifiers stacked on them.

So instead of

you could use . This would minimize the very different but basically same CSS properties as well and trim out A LOT of HTML tags. Think instead of wrapping a in an .

That's basically how React and Vue started out with the component system, but I'm thinking more of a GameObject & Component system like with Unity.

Post reply on HN