Live data from Hacker News

Rethinking DOM from first principles

acko.net

191–200 of 234 posts

Re: Rethinking DOM from first principles

#191

I think for a system that can basically do EVERYTHING, HTML is quite well designed. And I think keeping backwards compatibility for SO long is a big achievement and a good thing. I also think that if we could roll back time and had the knowledge of today, instead of fixed elements with user-agent styling and hard-coded restrictions, I would've crafted a system of arbitrary nodes that can have modifiers stacked on the…

You can create any arbitrary tag for an element and it will be treated like a span until you define its appearance with CSS.

    Features {
      display: block;
      padding-left: 1.5em;
      list-style-type: disc;
    }

    Feature {
      display: list-item;
    }
Technically, you're supposed to add a dash to a custom element to avoid namespace issues with potentially new elements, but that's probably an easy search and replace if it ever happens.

This comes in very handy with XML.

Re: Rethinking DOM from first principles

#192
post #128

Earlier quoted context omitted.

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

Extension not necessary: In Chrome, open DevTools, Shift+Ctrl+P > Disable JavaScript

CSS can prevent selection.

Re: Rethinking DOM from first principles

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

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

Yep, and accessibility will be a nightmare.

Just as it was with Java and Flash.

Re: Rethinking DOM from first principles

#194

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.

"Web apps" should have been standard desktop apps with a network connection. You don't need a browser to use network protocols (and protocols died when HTTP stopped sending hypertext and started to send JSONs) or call APIs. Your OS manages the network stack. We can complain how much we want, but the stream of shit, web-shit included, cannot be stopped or reversed. Brace yourself for more.

Desktop apps run the risk of installing malware.

Re: Rethinking DOM from first principles

#195

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 often handcode UI layouts and animations in C on embedded devices. I also use HTML and CSS a lot.

Sometimes I prefer the raw simplicity of writing your own layout code. You then basically just need X/Y coordinates, anchor points and dimensions of the screen and the elements on them. The rest can be done using simple arithmetic. The good thing about this is that you can do 95% of what people use CSS for, while using a handful of consistent methods. Wbile this to the uninitiated requires some introduction into how to think in a coordinate system, the simplicity can be refreshing.

Meanwhile in CSS you have a organically grown complexity of features where sometimes things that should be simple are hard, often because the elements that should be styled have default attributes with subtle differences which people aren't aware of. Only the minority could tell you the differences between display: inline, block, inline-block, contents, flex, grid, table, rable-column-group, etc. But elements may have them set per default.

I get that it is hard to simplify CSS for reasons of backwards compatibility, but sometimes I wish that instead of adding on top someone had had a long hard think about how to solve the problems elegantly and with consistency instead.

Re: Rethinking DOM from first principles

#196

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.

"Web apps" should have been standard desktop apps with a network connection. You don't need a browser to use network protocols (and protocols died when HTTP stopped sending hypertext and started to send JSONs) or call APIs. Your OS manages the network stack. We can complain how much we want, but the stream of shit, web-shit included, cannot be stopped or reversed. Brace yourself for more.

> "Web apps" should have been standard desktop apps with a network connection.

This is the way I lean too. So much of what web apps do is just reinventing the wheel of desktop GUI toolkits, only worse, because each one does it in its own way, rather than all having a consistent look and feel.

Re: Rethinking DOM from first principles

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

> when you so much as change an element border (which may trigger a full re-layout of the entire page) This is easily avoided: use 'outline' instead of 'border', or just keep the border width fixed and change the border color to/from transparent.

> This is easily avoided: use 'outline' instead of 'border'

Yup. And DOM is full of footguns like this. "Oh, you can't do this primitive thing no UI kit has a problem with, you have to use this workaround".

Re: Rethinking DOM from first principles

#198

Earlier quoted context omitted.

itds be easier to just make an amazing deployment platform and code native, than the inverse. edit: if you can program

If it was, it would reflect in reality. But the web wins the "where shall we deploy this" fight every single time. For good reason. You mentioned java, People preferred literally electron over java.

Reality isn't always good.

Re: Rethinking DOM from first principles

#199

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…

Much of this complexity comes down to primitives being too primitive for the use case of web apps. They’re fine for documents, but for web apps it’s like trying to build a building from grains of sand instead of concrete blocks. Rube Goldberg machines are unavoidable when you’re doing that. The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that req…

> The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS.

Well, I'd prefer if it provided widgets that can't be skinned. :-) The theming should be the user's choice, not the app designer's.

> That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.

I don't really care so much about the web dev experience as the web user experience. My experience as a user is greatly degraded by a bunch of web devs full of bright ideas about how to make their apps look, rather than using predefined widgets whose look is determined by me.

> Much of this complexity comes down to primitives being too primitive for the use case of web apps.

I totally agree with this, although I disagree about what the better alternative is. In my view it is partly this issue that's led to the disappointing profusion of "skinning". In desktop app toolkits you use a tree view, or a button, or a dropdown, or whatever. That widget's "identity" is based around functionality and its look and feel are not controllable by you as the app author. Instead, they're determined by the user's platform (color/font settings, window manager, etc.). That's a better model for users.

Re: Rethinking DOM from first principles

#200

This is satire, right? I mean, it has to be. The author critiques a ~50-year-old set of tech that has been developed piecemeal over those ~50 years to cope with a vast array of different goals and priorities. And proposes their own toy tech as a replacement, with apparently no sense of irony. HTML was never designed for web apps, but it powers billions of them. CSS was never designed for complex dynamic UIs, but it d…

> every single part of all of this tech was debated for weeks by a large room full of very, very, smart people

I bet that room never smelled of sunk cost fallacy

Post reply on HN