Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking DOM from first principles

acko.net

Post reply on HN
Print view View original

91–100 of 234 posts

Re: Rethinking DOM from first principles

#91

Post by icedchai »

benoau wrote: post #83
corytheboyd wrote: post #79

Earlier quoted context omitted.

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…

Flex is great but tables are also a natural solution for anything grid-based, which of course layouts almost always are. The whole internet used to do stuff like this before the structural flow of content became important: header sidebar content

Bring back the 90's. ;) The memories of spacer gifs...

Re: Rethinking DOM from first principles

#92

Post by phailhaus »

romaniv wrote: post #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…

Conflating presentation and data seems like a classically Bad Idea. Changes to presentation break your business logic.

Re: Rethinking DOM from first principles

#93

Post by andoando »

ezst wrote: post #42
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…

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

I struggle to see the reason why web pages and apps are even two different things.

The browser is really just a cross-platform platform for building applications.

Re: Rethinking DOM from first principles

#94

Post by socalgal2 »

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 the user's dictionary but your page can not as looking through a user's dictionary would be a privacy issue.

That said, if you want a non-DOM framework, surprisingly Google already provides it. It's called Flutter and it has the option to use a canvas, no DOM. You can see a large complex example at

https://earth.google.com

Go there and type in NYC. You'll see text and images popup over the earth, etc. You'll see a toolbar and menus and a status bar etc... Click settings. The stuff that appears is all canvas. Click the Data Layers icon. The stuff that appears as all canvas. I think they finally made the search input box an input element for the reasons above but the rest is canvas.

Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.

Re: Rethinking DOM from first principles

#95

Post by divan »

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…

Flutter is amazing exactly because it was a response to the problem of creating modern cross-platform apps for the modern zoo of hardware. The text typesetting engine from the 80s is clearly not a good foundation for it.

It's probably safe to say that the majority of the dev workforce in the last 2 decades started their career with learning HTML/JS/CSS stack, and it's understandable why they like it. It doesn't make this stack any better for creating apps, no matter how many abstractions on top we place.

Re: Rethinking DOM from first principles

#96

Post by flohofwoe »

hungryhobbit wrote: post #85

All those words, and yet not once did he even mention the entire reason everything is the way it is: to preserve backwards compatibility. It's like writing an entire diatribe about how it sucks that people can insult you online, and how that should change ... and not even mentioning the benefits of freedom of speech.

Backward compatibility can (most likely) be achieved with a dom.js polyfill library which sits on top of that hypothetical new middle-layer thingie.

Re: Rethinking DOM from first principles

#97

Post by zamadatix »

hungryhobbit wrote: post #85

All those words, and yet not once did he even mention the entire reason everything is the way it is: to preserve backwards compatibility. It's like writing an entire diatribe about how it sucks that people can insult you online, and how that should change ... and not even mentioning the benefits of freedom of speech.

Backwards compatibility is given in HTML by the doctype. I think you might also really be talking to forwards compatibility in addition - "what I would write in an HTML 4 document will (almost) always work the same in an HTML 5 document".

I don't think what the author is talking about is necessarily against either. HTML5 can continue its evolutions while "HTML6" (or something completely separate) exists alongside the traditional DOM, like the example they reference or like WASM exists alongside JS. From this perspective, the article is about why it's a worthwhile time to make the new thing rather than why the new thing won't also have baggage in 20 years or why we should just throw everything current out the window as part of supporting the new thing.

Re: Rethinking DOM from first principles

#98

Post by achierius »

graemep wrote: post #90
ezst wrote: post #42

Earlier quoted context omitted.

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

We had multiple implementations of Java, but if still failed for that reason. Even if the concerns had been completely addressed MS did not only want to stop Oracle taking control, it wanted to establish control itself. Was Java any worse from a security point of view than what we have now?

Yes, significantly. The JVM just flat out does not provide a sandbox. Remember the bad old days of clicking on a suspicious link and getting pwnd? That's what we'd have if it weren't for modern JavaScript engines

Re: Rethinking DOM from first principles

#99

Post by Izkata »

benoau wrote: post #83
corytheboyd wrote: post #79

Earlier quoted context omitted.

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…

Flex is great but tables are also a natural solution for anything grid-based, which of course layouts almost always are. The whole internet used to do stuff like this before the structural flow of content became important: header sidebar content

GP is also wrong anyway, CSS Flex is the wrong thing for creating layouts like this. We now have CSS Grid, which is the actual replacement for table-based layouts (which were used more recently than people like to admit because of Flex not working for two-dimensional layouts).

Re: Rethinking DOM from first principles

#100

Post by taeric »

romaniv wrote: post #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…

Agreed. The idea that moving state out of the document is a touch frustrating to me. Seemed to me that the entire point of a tree of data was to store the state as data?
Post reply on HN