Live data from Hacker News

Rethinking DOM from first principles

acko.net

71–80 of 234 posts

Re: Rethinking DOM from first principles

#71

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'd vote for something along the lines of QML or Slint for defining UIs; business logic should be purely done in WASM.

Re: Rethinking DOM from first principles

#72
Glad the title was changed because this article isn't about HTML at all. Instead it seems to be about corporate/for-profit needs for their web applications that happen to touch HTML in some parts. All about throwing away the good parts of HTML to make laying out applications easier and prettier.

To this I say: go away and leave HTML alone if you want to build some application from first principles. The web's first principle is that HTML should have text. Hyper TEXT MARK-UP language.

Re: Rethinking DOM from first principles

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

You'd still have all the same backwards compatibility problems with the "Web for applications" stdlib and UI framework as we do now.

Re: Rethinking DOM from first principles

#74

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…

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.

Svelte seems to do this just fine. It's much simpler to work with, doesn't introduce too much proprietary code, and is both lightweight and incredibly fast.

Re: Rethinking DOM from first principles

#75
post #59

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…

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.

Re: Rethinking DOM from first principles

#76
post #68

Earlier quoted context omitted.

> Given that even newspaper websites are now built as applications, we should accept that [...] So because some websites do shitty things, we should all throw out the standard way of displaying information on the web? Guide me through that line of reasoning. Why are newspaper websites, out of all the websites, the ones which should determine how we do things?

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

Re: Rethinking DOM from first principles

#77

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 should be applications that use native UI toolkits while relying on Internet for moving data, not presentation.

Users are usually unhappy with Web applications because of the way browsers restrict useful functionality and programmers struggle with workarounds and bloat of browsers to accomplish simple things.

Re: Rethinking DOM from first principles

#78

I'm tempted to take the opposite stance to the author. The web as a platform is wildly successful, and it's interesting to think about why. Surely the "loose" standards encouraged neat hacks that at some point were encoded as best practices and then standardized. Maybe that would tempt us to want to "cut the cruft" but a) people probably thought that many times previously and b) backwards compatibility is probably mo…

To say that web as platform is wildly successful would be an understatement. It's so successful that probably like 95% people doing webdev don't even care about these discussions or have opinions about it.

I think that scale of "silent" users compared to proactive devs would be the most surprising number. Like for anyone who is "Rethinking DOM from first principles" there is probably like 10000s of randos editing ecommerce html templates, exporting results into tables and dataviz or making small uis for some internal system.

Re: Rethinking DOM from first principles

#79
post #75
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.

This sounds crazy to me, the flex system is exactly this but also semantically correct. You can’t possibly be telling me that table hacks of yore are easier than this, a clearly designed system for the actual problem you want to solve https://css-tricks.com/wp-content/uploads/2022/02/css-flexbo...

I’m not at all a frontend person, I just think flex is one of the best systems I have ever used. It usually gets the job done in a way that I expected to work (and that bar is pretty low lol)

Re: Rethinking DOM from first principles

#80
Devs have learned not to keep state in the document, because it's inadequate for it.

Web devs have moved the state out of the document into JS variables and have been piling bloated, short-lived crap on top of those variables ever since.

If you actually keep state in the document things become rather simple. Scripts themselves become stateless and do not require direct dependencies on one another. Data can be queried across the page with CSS selectors. Many visual transformations on data can be handled in CSS as well. There is a well-developed system of events to handle interactions, which removes the need to handle user changes, AJAX and WebSockets separately. You gain the ability to dynamically examine and modify the state of your "application" simply by pressing F12 and changing things in the elements tab.

While it's definitely possible to imagine better ways of dealing with documents, layouts and so on, seeing how JS frameworks handle state makes me fear any "improvements" on this front.

Post reply on HN