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

61–70 of 234 posts

Re: Rethinking DOM from first principles

#61

Post by strogonoff »

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

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

I would argue that a good layout engine for pages could see good use. See Gemini/Gopher—people like minimalism, but having to use a separate browser makes it probably too niche.

Contrary to what was stated in the suggestion, it’s hardly a solved problem—improvements are being made at a steady pace (grids or { text-wrap: pretty } come to mind)—but it is interesting to imagine, especially if there were extra compelling reasons for engineers to restrict themselves to purer hypertext document API if possible (for example, it could be much more stable, while the app part could be unlocked to evolve more quickly but would be more demanding to developers keeping their webapps up-to-date; search engines could prioritize it; there could be hosting services specializing in it; and so on).

One counter-argument is that you can’t neatly separate the two and engineers will definitely want to use both; one way around it I can see is if hypertext document functionality was possible to use from within the webapp somehow, but I haven’t given it that much thought obviously.

Re: Rethinking DOM from first principles

#62

Post by strogonoff »

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

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!

Even if using { display: grid }, or a combination of flex rules, hardly seems like an ideal solution, considering there does exist { text-align: center } (which, incidentally, doesn’t only align the text!), I do agree with the general point. Today it is reasonably easy to make quite complex grid-driven layouts; not easy—often, if not always, making a complex thing easy requires also making it restrictive and opinionated—but perhaps easy enough considering the end result.

Re: Rethinking DOM from first principles

#63

Post by austin-cheney »

troupo wrote: post #58
austin-cheney wrote: post #17

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…

> I have no idea why, but tree models scare the shit out of college educated developers. Very few people are "scared" of tree models. The problem of working with the DOM is that it's: - 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things - Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you…

This is exactly what I am talking about. All these excuses, especially about vanity, are masking behaviors.

DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow.

Chrome has always been much slower. Back then I was getting closer to a max of 50 million ops/second perf testing the DOM. Now Chrome is about half that fast, but their string interpolation of query strings is about 10x faster.

The only real performance problem is the JS developer doing stupid shit.

Re: Rethinking DOM from first principles

#64

Post by DemocracyFTW2 »

> CSS is at least two different things mashed together: a system for styling rich text based on inheritance... and a layout system for block and inline elements, nested recursively but without inheritance, only containment. They use the same syntax and APIs, but don't really cascade the same way. Combining this under one style-umbrella was a mistake.

This might in fact be a valuable insight, I never thought of it.

Re: Rethinking DOM from first principles

#65

Post by skeezyboy »

porridgeraisin wrote: post #33
skeezyboy wrote: post #22

Earlier quoted context omitted.

or maybe just stop trying to force the round peg in a square hole. an application is surely not a document. they open documents. its conceptual, but it would make your life so much easier if you stopped trying to make a fully fledged platform out of what was essentially a rich text document viewer. java has since come along and given you pretty much write once, run anywhere and close to instant deployment with its ap…

Web as a deployment platform has too many advantages for it to be ignored for distributing _anything_. We don't have to force a round peg into the square hole . Let's make a new round hole but keep using the amazing deployment platform.

itds be easier to just make an amazing deployment platform and code native, than the inverse.

edit: if you can program

Re: Rethinking DOM from first principles

#66

Post by zelphirkalt »

lmm wrote: post #7
deafpolygon wrote: post #3

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…

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

Re: Rethinking DOM from first principles

#67

Post by fiedzia »

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

> surely we can't keep adding to css and the dom api's for 20 more years?

We can. Just every now and then some new way of working becomes popular, and at some point combining them with older ones will become undefined or unsupported.

Re: Rethinking DOM from first principles

#68

Post by lmm »

zelphirkalt wrote: post #66
lmm wrote: post #7

Earlier quoted context omitted.

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…

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

Re: Rethinking DOM from first principles

#69

Post by fiedzia »

skeezyboy wrote: post #31
b_e_n_t_o_n wrote: post #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…

> I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? In all seriousness, isnt this what Java is for? Why would you need to treat a web browser like a virtual machine?

> Why would you need to treat a web browser like a virtual machine?

There are many reasons. Performance, ability to bring concepts from other domains, ability to do things browser has no api for, ability to provide controlled experience and behaviour that goes beyond common browser usage.

Re: Rethinking DOM from first principles

#70

Post by troupo »

austin-cheney wrote: post #63
troupo wrote: post #58

Earlier quoted context omitted.

> I have no idea why, but tree models scare the shit out of college educated developers. Very few people are "scared" of tree models. The problem of working with the DOM is that it's: - 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things - Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you…

This is exactly what I am talking about. All these excuses, especially about vanity, are masking behaviors. DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow. Chrome has always been much slower.…

> All these excuses, especially about vanity, are masking behaviors.

1. These are not excuses, these are facts of life

2. No idea where you got vanity from

> DOM access is not quite as fast now as it was 10 years ago. I was getting just under a billion operations per second

Who said anything about DOM access?

> The only real performance problem is the JS developer doing stupid shit.

Ah yes. I didn't know that "animating a simple rectangle requires 60% CPU" is "developers doing stupid shit" and not DOM being slow because you could do meaningless "DOM access" billions time a second.

Please re-read what I wrote and make a good faith attempt to understand it. Overcome your bias and foregone conclusions.

Post reply on HN