dom VS webcomponents

My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there. Behavior of the page can be made visible! There's so much allure to me to hypermedia that's able to declare itself well.

This could radically enhance user agency, if users/extensions can rewire the page on the fly, without having to delve into the (bundled, minified) JS layers.

There's also a chance the just-merged (!) moveBefore() capability means that frameworks will recreate HTML elements less, which is a modern regression that has severely hampered extensions/user agency. https://github.com/whatwg/dom/pull/1307

in plain htmx, you can target an area that doesn't disrupt a playing video (e.g. the comments box appending to the comments) or you can use a morphing algorithm that disrupts the DOM less.

i have my own morphing algorithm (and a corresponding htmx plugin that allows you to use it) called idiomorph:

https://github.com/bigskysoftware/idiomorph/

i've also been working with the chrome team to get a feature added they are calling "atomic moves":

https://github.com/whatwg/dom/issues/1255

this would allow us to move elements around in the DOM without losing things like play state or focus or whatever

very excited for this last idea, I think it will be a huge boon for the web in general, not just for htmx

What I said in my previous comment is observably true. Try making a demo where it isn't.

> A DOM node is a living mutable thing, but the JavaScript object representing that node is not.

The JavaScript object is mutable. The first example in the article shows this.

> That is also why a node list is not an array.

Modern APIs on the web return platform arrays (eg JavaScript arrays). https://webidl.spec.whatwg.org/#js-sequence - here's where the WebIDL spec specifies how to convert a sequence to a JavaScript array.

I'm fully aware of NodeList. There's a reason the spec calls them "old-style" https://dom.spec.whatwg.org/#old-style-collections

> I can understand how this is confusing if you have never operated without a framework, but otherwise it’s really straightforward

Sighhhhhh. I've been a web developer for over 20 years, and spent a decade on the Chrome team working on web platform features. Most of my career has been on the low-level parts of the platform.

Could it be possible that people are disagreeing with you, not because they're stupid, but because you're in the wrong? Please try to be open minded. Try creating some demos that test your opinions.

Domenic Denicola (the man who ruined promises) probably will as well.

https://github.com/whatwg/dom/issues/67

I'm pretty sure it is, since I get "TypeError: nodes[i].parentNode.href is undefined" and "TypeError: $mainmenu.parent(...).get(...) is undefined" errors on both Pale Moon and LibreWolf. Which is part of Shadow/DOM, and originated from google (https://hacks.mozilla.org/2015/06/the-state-of-web-components/). Not sure when this particular thing was introduced, since it's a "living standard"/experimental feature (https://dom.spec.whatwg.org/).

JSX chose to align names to the DOM spec [0]. Same for htmlFor and friends.

[0] https://dom.spec.whatwg.org/#ref-for-dom-element-classname%E...

You can see why I say this here: https://dom.spec.whatwg.org

The product logos in this article's cover image include different languages and technologies some of which are still relevant for web development today: HTML, CSS, JavaScript / ES / TypeScript (and the DOM), SVG, PDF, PHP, SQL (mySQL, MariaDB), mongoDB, Node.js (the most successful server-side implementation of JavaScript so far).

Thanks for the shout-out! I think I mention this in the talk, but note that YMMV. I designed that benchmark as a kind of "worst-case scenario" where shadow DOM / scoped styles really show a benefit. Depending on your CSS rules, DOM size, and amount of thrashing, the perf benefit could be small to large.

Also, it's still possible to shoot yourself in the foot, especially if you have a large/complex stylesheet repeated across multiple shadow roots. (Not because of the repetition – that's optimized in browsers [1] – but rather because of the number of DOM nodes affected.)

That said, I still think the perf benefits of shadow DOM have been undersung. And Declarative Shadow DOM makes it way more useful.

[1]: https://github.com/whatwg/dom/issues/831#issuecomment-585489...

It's not standard yet. Behavior is implementation-defined and under-specified. A lot of people have used a thing like this[1], but this[2] is on a standards track. In the documentation for the first one, it describes a default "file scope", but really no definition of what a file is. It seems to be referring to a source file pre-build/bundle, but it really just doesn't say. That would belong in the documentation for some framework, not web platform stuff anyway.

The idea of locally scoped styles is reasonably popular. Like vue single-file-components, and n+1 different implementations of CSS modules. What it really needs though, is standardization. Things like [2] and the upcoming @scope will provide this.

[1]: https://github.com/css-modules/css-modules/blob/master/docs/...

[2]: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Refer to example 4 in the CSS Scoping specification:

> It will not select #three (no slot attribute) nor #four (only direct children of a shadow host can be assigned to a slot).

— https://drafts.csswg.org/css-scoping/#example-7cc70c2d

I’m talking about the #four case.

Alternatively, refer to the issue that was opened in the web components issue tracker here:

> > you can only select a direct item within the slot

> That is by design. See #331 for details.

> We don't have a plan to support an arbitrary selector for ::slotted.

— https://github.com/WICG/webcomponents/issues/594#issuecommen...

> “Web components” aren’t really a thing

This is an empty nitpick. The people writing the specs call them web components, the people implementing them call them web components, the people writing them call them web components. There is nothing wrong with calling them web components.

> I assume that you’re talking about custom elements with shadow roots here.

You don’t have to assume anything. I explicitly said that it constructed a shadow DOM.

This error occurs when trying to register a custom element with a name that's already been used. This error is common in micro frontends such as using module fedreration where multiple apps share a single index file. There is a proposal to address this called Scoped Custom Element Registries but there's no ETA so you will need to use a polyfill.

There is a proposal for JavaScript-based HTML templates: https://github.com/WICG/webcomponents/issues/1069

This, in conjunction with HTML modules would provide a mechanism for custom elements that are both client-side framework SSR-friendly, reduce the dependency on JavaScript, and improve the performance of our custom elements that don't require any JavaScript. Also, like custom elements using the Declarative Shadow DOM, these custom elements can be upgraded once the client is available for more advanced user interactions.

To avoid forward-incompatibility (be future-proof) you might want to name your event handler with a dash or other non-ASCII character in its attribute name, and maybe an uppercase character in its property name. When custom attributes are a thing, then maybe this will also allow having such an attribute globally available on all elements. Not sure it's a good idea, if you ask me I think I'd just use a simple name and hope HTML won't add a conflicting one in the future.

A case for vanilla JSX (https://vanillajsx.com/) by sdegutis There is a great debate ongoing in the WICG Web Components GitHub repository that might actually benefit from native JSX (https://github.com/WICG/webcomponents/issues/1069).