Live data from Hacker News

Rethinking DOM from first principles

acko.net

1–10 of 234 posts

Re: Rethinking DOM from first principles

#4
Good article. It kind of makes me question how long we can go down this path though. Like surely we can't keep adding to css and the dom api's for 20 more years? How much bloat will we accumulate before we start over?

I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? Something akin to what's discussed in the article - a simple but robust layout system built with a flexbox-like API and let us bind shaders to elements. We don't need css if we have shaders. And I don't think adding more and more features to current api's is gonna solve problems long term.

Re: Rethinking DOM from first principles

#5

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.

Re: Rethinking DOM from first principles

#7

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.

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 as web components on top of a basic core web runtime. Then we could have a small standard for the core web that was practical to implement - just a very minimal layout engine and a JS interpreter - and everything else could be in the "component library" rather than something browser makers had to implement by hand. And then pages that want to use their own components or some other third-party components - which is most pages these days - could skip all that cruft)

Re: Rethinking DOM from first principles

#8

Good article. It kind of makes me question how long we can go down this path though. Like surely we can't keep adding to css and the dom api's for 20 more years? How much bloat will we accumulate before we start over? I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? Something akin to what's discussed in the article - a simple but robust layout system built…

I don't know exact what system you have in mind, but writing a performant shader is hard. Requiring that designers attach arbitrary shader code to HTML elements is an easy way to absolutely tank the performance of the web.

Flexbox also isn't great at all for many, many use cases - its performance absolutely tanks outside of the use case it was designed for, specifically a 1D flow of blocks along an axis. If you want a grid layout, choose the grid layout algorithm.

Any system here must accommodate extremely heterogeneous requirements, so it will inevitably become "bloat". One alternative future you could envision is based on WASM and WebGPU, where each site is essentially an app that pulls in whatever libraries and frameworks it needs to do its work, but that's also pretty far off, since there is not sufficient standardization of the protocols used by WASM UI frameworks.

Re: Rethinking DOM from first principles

#9
post #7

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.

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…

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.

Re: Rethinking DOM from first principles

#10
post #7

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.

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…

I get this viewpoint from a software architecture level, but that is also effectively the death of the open web. When every website is an opaque app, even often requiring a client-side optimizing compiler that builds an arbitrary binary in order to load (WASM), we can say goodbye to things like search engines and typically also hyperlinks. The rise of social media has already balkanized the web a lot, where almost all content is locked behind a login screen.

This could be what we want, but I can't help but think about what we've lost.

Post reply on HN