Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "Why Everyone Hates Web Components" video.

  1. 23:00 The cause of this difference is "due historical reasons" as with everything in life. In fact, the "disabled" alone is not a flag but it's an SGML (of all things!) shorthand notation for value "disabled" if exactly one attribute allows value "disabled" (yes, SGML is truly this brain-damaged). Technically it's shorthand for writing disabled="disabled" which is also why you have to use the latter syntax if you write XHTML instead (XHTML being implemented in XML, it obviously doesn't support SGML shorthands).
    3
  2. 1:15:00 I think this is a great illustration of the current situation and the web components definitely belong to the left side of the spectrum just as you put it. However, we need some new standards to live around ShadCN level or even slight closer to "component I wrte in my codebase" level but we don't have anything yet. And it's still unclear to me if there can be any non-framework agnostic solution here. Whatever solution is chosen, I hope it can fully interact with DOM. If you have any kind of virtual DOM solution where a piece of JS code overwrites the actual standard defined DOM from virtual DOM, that's definitely a model that cannot co-exist with standards compliant code. We would need a solution where you can have some server side rendered components co-existing with code that uses native JS code to work with the DOM without both sides stepping on the toes of the other side.
    1
  3. It seems to me that web components (WC) are great if you're trying to re-implement something like `<input type=datetime>` but it's a poor fit for server side rendering (SSR). Unfortunately, many JS authors try to use web components for SSR. Browsers really would need to support SSR better but the current state of WC is not designed for that.
    1
  4. 1:17:05 I think the fact that web components do not behave similar to native components (e.g. cloning) is the issue here and that part should be fixed in the web standards. It doesn't matter if the difference is hurting framework's internal implementation or native JS code you're trying to write by yourself. If this is caused by specs, then the specs would need to be improved to fix this and make web components to work when a fragment of DOM is cloned, or at least immediately throw instead of silently failing to clone parts of the fragment. Changing some old APIs to throw in case web components are passed in is an acceptable solution if the API has design that truly cannot support web components. Hopefully the error message would prod towards the newer API for the same use case that does support web components. Every API that has to be broken must have newer counterpart that has minimal changes to make it compatible with web components.
    1