Live data from Hacker News

Rethinking DOM from first principles

acko.net

121–130 of 234 posts

Re: Rethinking DOM from first principles

#121

Earlier quoted context omitted.

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

I thought the JVM had permissions restrictions in the days of Java applets?

I suppose it had, but as a large codebase written in a memory-unsafe language with unrestricted system access, in an era where browser plugins weren't sandboxed by design, it was a cat and mouse game.

Re: Rethinking DOM from first principles

#122
https://news.ycombinator.com/item?id=34304655

Alan Kay on web browsers, document viewers, Smalltalk, NeWS and HyperCard (2021) (donhopkins.medium.com)

234 points by gjvc on Jan 8, 2023 | hide | past | favorite | 272 comments

https://donhopkins.medium.com/alan-kay-on-should-web-browser...

Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook

Alan Kay Wrote: Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).

It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).

[...]

Re: Rethinking DOM from first principles

#123
post #84

Earlier quoted context omitted.

Well yeah but no self-respecting developer has done this for 15 - 20 years... it's kind of a red flag these days!

I really wish this was true. Sadly the caniemail website - https://www.caniemail.com/ - says that Gmail still doesn't support CSS grid or flex, which leaves nested tables for layout as the only viable solution for HTML emails (which, however many times you plead with your marketing colleagues, is still their preferred way for contacting/stalking customers).

[dead]

Re: Rethinking DOM from first principles

#124
DOM per se, as a tree of elements, is not that bad. CSS is also not that bad in general.

Their API is probably the problem. Not modular so makes the mess.

Options to modularize them:

DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for we may have separate "textarea" interface:

   element.tagName
   ... and the rest of DOM-as-a-tree methods ...
   element.textarea //  specific interface of its behavior
   element.textarea.select(startEnd) // interface method
   element.textarea.selectionStart // interface prop
   element.textarea.selectionEnd // interface prop
   element.textarea.rows // interface prop
   element.textarea.columns // interface prop
   ...
CSS, that huge flat table is a nightmare, not just because of its size, but because of extensibility problems right now and in the future. Example, all CSS grid related properties should rather go to their own namespace:

   section {
     color: red;
     // ... and other basic CSS 2.1 props

     display: grid(
       rows: ...;
       columns: ...;
       align-items: center;
       justify-items: start
     );
   }
So different layouts ( like display:flex(), display:waterfall() ) may have their own rows, columns, etc.

As sooner we will do that - the better. API is on the brink of collapsing / combinatorial explosion, indeed.

Re: Rethinking DOM from first principles

#125
post #45
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 think it's a reasonable take after 15 years of seeing CSS/HTML/JS being abused for everything and more (when all you have is a hammer…), with the result being that many simple static pages are nowadays monstrous JS apps. My conviction is that, had those technologies stayed simple and focused on delivering the "Document" use-case, turning everything into an app would be a much bigger bridge to cross.

That's essentially where the web was at before the HTML5 days: you could already go as fancy as you wanted, at the cost of pushing your users into a java/flash applet (and through longer loading times, high CPU/Memory requirements, …), and that clearly wasn't the norm.

Re: Rethinking DOM from first principles

#126
post #115
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…

so do you stringify all your state?

Yes, but not in the sense of dumping serialized JSON into HTML. It ends up being represented by custom HTML attributes and their values. For example, if you need to keep track if the user clicked on some button, you might represent it as follows:

  
or

  
The content of the attribute becomes "1" after the first click and keeps increasing. The job of the corresponding JS code would be purely to keep track of clicks, so it would be very simple. Meanwhile, the value could be used for a variety of different tasks (including in CSS) and the exact same library could be applied to any element without any modification or writing "glue code".

Re: Rethinking DOM from first principles

#127

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.

might be enough.

Re: Rethinking DOM from first principles

#128
post #117

Earlier quoted context omitted.

You had a great comment I had saved last time this topic came up: https://news.ycombinator.com/item?id=41981458 It's true, what people think of as native on the web are merely incidental from its history, not some ironclad law of how to make interfaces.

Text selection is such a great example precisely because it is incredibly useful to have in many unexpected situations (and a great many more that should be expected), but UI designers as a rule do not think about these situations! It is so bad that one of the most impressive operating system features to be added in recent years is the ability to select and copy arbitrary text from app UIs, using either accessibility…

+ even when websites decide to be a pain and block text selection/copying, you can fix that with extensions.

Re: Rethinking DOM from first principles

#129

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…

> Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input. It's far from the only thing it has issues with; I've found obviously broken UI patterns within a couple clicks of opening Earth's map view: - right click doesn't appear to work anywhere (except input boxes), even on elements that have direct equivalents in other Google sites (like the account switcher),…

Agree with all of this

> right click doesn't appear to work anywhere

I hate this and it's the default for a canvas app since the app would have to implement doing something on right click where as in the browser it's the default. Unfortunately, an HTML app can disable right click too :(

In fact, I hate that issue on all native apps. Things I want to select/copy/lookup are not selectable/copyable/lookup-able. As an example, Sublime Merge, a native app, quite often I want to copy a path but there is no option to do so. Every place that displays a path would need custom code (or a shared control) to make the path copyable. HTML doesn't generally have this issue as it's opt-out not opt-in for being copyable.

I'm not a fan of Flutter or other canvas bases sites. Emoji didn't work for like 3 years in google docs after their canvas change. It works now but not always.

It's worse too in that it doesn't matter if flutter eventually fixes these issues. Every app needs to be update. That's not true with HTML where the browser updates to support "insert password into input type=password" and it just works. Even better, an extension (1 password) can insert the password but it can't on a canvas based app.

Re: Rethinking DOM from first principles

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

And how about blind people, bots, accessibility in general? I don't remember java and flash handling different screen resolutions like desktop, tablets, and phones.
Post reply on HN