hyperHTML VS dom

The main limiting factor, like someone else said, is that you can't load external JavaScript files from your local file system without serving them. Your best bet would probably be to try and find a CDN source for some minimal Web Components library like Lit or HyperHTML and just write everything in a single HTML file.

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

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

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

And to run ECMAScript or WASM... well thankfully you can just reuse an interpreter for it, there are plenty of them... upon which you're going to implement all of this.

I tested with lit-html, "reorder" whose DOM op should be "moved", but it didn't animate. And currently there is no such thing as DOM reorder (https://github.com/whatwg/dom/issues/891)

That's correct. Tests 23 & 25 require a specific error type that has since been changed in that circumstance: https://github.com/whatwg/dom/issues/319#ref-commit-94dd371

Test 35 requires root elements to not match :first-child, and the spec was changed to specify that they should match: https://bugzilla.mozilla.org/show_bug.cgi?id=1300374

I got a little curious on the statuses of these standards and went on a bit of searching.

> CSS contain (CSS Containment Module Level 2) - First published in 2019, still Editor's Draft[1]. Not supported by Safari/WebKit.

> CSS offset-path (Motion Path Module Level 1) - First published in 2015, still Editor's Draft[2]. Not supported by Safari/WebKit.

> CSS overflow-anchor (CSS Scroll Anchoring Module Level 1) - First published in 2020, still Editor's Draft[3]. Not supported by Safari/WebKit.

> Resolution media queries (dppx) - W3C Recommendation since 2012[4]. Not supported by Safari/WebKit.

> :focus-visible (Selectors Level 4) - First published in 2011, still Editor's Draft[5]. Not supported by Safari/WebKit.

- Touch Events - W3C Recommendation since 2013[6]. Supported on iOS 3.2 (2010). I assume the author meant Pointer Events[7] which became W3C recommendation since 2019, and supported on 13.2 (2019).

> BroadcastChannel - WHATWG Living Standard[8]. Blocked by privacy concern on WebKit side since 2020[9]. Initial support landed in WebKit trunk as of 2021-07.[10]

> beforeprint/afterprint - WHATWG Living Standard[11]. Supported by Safari/WebKit since 2019 (iOS 13).

> Regex Lookbehind - ECMAScript 2018[12]. Not supported by Safari/WebKit.

> scrollIntoView (CSSOM View Module) - First introduced in CSSOM View Module since 2011, still Editor's Draft[13]. Not supported by Safari/WebKit.

> Screen Orientation API - First committed in wc3/screen-orientation in 2012, still a W3C Working Draft[14]. Not supported by Safari/WebKit.

> Date and time input types - WHATWG Living Standard[15], partial support by Safari/WebKit since 2012 (iOS 5) but no week/min/max.

> Service Workers - W3C Candidate Recommendation since 2019[16]. Supported by Safari/WebKit since 2018 (iOS 14.5).

- AbortSignal - WHATWG Living Standard[17]. Supported by Safari/WebKit since 2018 (iOS 11.3)

- Intersection Observer - First published in 2017, still W3C Working Draft[18]. Supported by Safari/WebKit since 2019 (iOS 12.2).

- Client-side form validation - WHATWG Living Standard[19]. Supported by Safari/WebKit since 2017 (iOS 10.3).

[1]: https://drafts.csswg.org/css-contain/#contain-property

[2]: https://drafts.fxtf.org/motion/#offset-path-property

[3]: https://drafts.csswg.org/css-scroll-anchoring/#exclusion-api

[4]: https://www.w3.org/TR/css3-mediaqueries/#resolution

[5]: https://drafts.csswg.org/selectors-4/#the-focus-visible-pseu...

[6]: https://www.w3.org/TR/touch-events/

[7]: https://www.w3.org/TR/pointerevents/

[8]: https://html.spec.whatwg.org/multipage/web-messaging.html#br...

[9]: https://github.com/whatwg/html/issues/5803

[10]: https://bugs.webkit.org/show_bug.cgi?id=227924

[11]: https://html.spec.whatwg.org/multipage/timers-and-user-promp...

[12]: https://262.ecma-international.org/9.0/

[13]: https://drafts.csswg.org/cssom-view/#dom-element-scrollintov...

[14]: https://www.w3.org/TR/screen-orientation/

[15]: https://html.spec.whatwg.org/multipage/input.html#date-state...

[16]: https://www.w3.org/TR/service-workers/

[17]: https://dom.spec.whatwg.org/#abortsignal

[18]: https://www.w3.org/TR/intersection-observer/

[19]: https://html.spec.whatwg.org/multipage/forms.html#client-sid...