You might want to check out https://cssdb.org/#nesting-rules native nested CSS rules have hit stage 1!

I checked the spec earlier and it’s impossible to make it backwards compatible with Sass without some slight edits, at least according to their GH issue on it. It’s worth watching though I suspect <style type=“text/scss”> or something like it will be added before we see broad adoption! :)

Possibly. I think the extra `&`s are something that could wash out with one-time tooling, and that the desire for `@nest .parent &` would bump the conversion rate, but it's always fun to watch the comings and going of standards.

One thing that is particularly important to take into account when comparing web components to framework is that they can and should work together. If indeed "web components" replace your "framework" it will most likely be because a new framework that takes advantage of web components and all that the web is now replaces your old framework. Already libraries that combine popular concepts like hooks from React with web components (https://github.com/matthewp/haunted) are pointing the way to a more powerful future for both site that need just that little extra something via a stand alone web component or a whole family of components wedded to a framework into a rich application. That being said, don't get confused by people on either side being overly defensive of their place in the web ecosystem things are they are now will change. Techniques will grow and merge and there will be something else that is "the thing" before too long. Web components will likely be as much a part of that as the elements who's shoulders they stand on (e.g. <select/> and <video/>). That's the power of the web.

True. One more thing about web-components is that they are a standard. Vue, React, JQuery are not.

Even from the beginning of Polymer and it's use of HTML Imports there were tools for bundling them and they worked great! It's even easier to find the right tool for you now that ES Modules deliver the power of web components with the help of your favorite Rollup or Webpack configs and plugins...

https://open-wc.org/building/

You can server side render a `video` element just the same way you would a `custom-element`. We've been doing it for years and there's no reason to think anything about that has changed. If you're looking to deep SSR which is arguable as far as benefit, check out approaches like https://github.com/ionic-team/stencil-ssr-starter

I think the difference is that the browser already contains the shadow dom needed to render the video tag. But for a custom tag it would need to fetch, parse and execute your component code before it can begin to render.

That's an interesting read. I'm thinking on whether the real question is what is the declarative difference between the video tag, which by normal application lets everyone feel find about that content hidden by the shadow DOM vs the APIs we're developing for our custom elements. There seems to be an important piece of learning, not just for SSR, but for custom element development in general, that I think we can build off of.

Types are cool, TypeScript is cool, and types with JSDocs are cool, https://dev.to/dakmor/type-safe-web-components-with-jsdoc-4i... and what's more, they're all cool with web components.

I'm confused, I scrolled down and still saw this:

    return html`
      <h1>${this.format(this.title)}</h1>
      <div
        class="dot"
        style=${`left: ${this.bar.x}px; top: ${this.bar.y}`}
        title=${this.bar.title}
      ></div>
    `;

That is not type checked. I can change any of the HTML tags in there, any of the attributes on the HTML tags, I can make the template ill-formed HTML, and nothing in my editor or build system will check that.

    const el = /** @type {TitleBar} */ (document.querySelector('title-bar'));

Why would I do that instead of this, if I'm using TypeScript?

    const el: TitleBar = document.querySelector('title-bar');

Moreover, this is an unsafe type coercion, we have no witness that the return value is a TitleBar. document.querySelector returns an HTMLElement, and if you were using strict TypeScript types this assignment would not type check.

There exists plugin for VSCode which checks for attributes inside template literal https://marketplace.visualstudio.com/items?itemName=runem.li...

That looks extremely useful though it's definitely in the "early adopter" phase of utility. It looks like this extension and the underlying TypeScript plugin that allows typechecking are being developed by a single person, and I think a team or individual would have to make a judgment call on whether to depend on it.

You might be interested in https://github.com/bennypowers/stripe-elements Stripe v3 with Shadow DOM.

Thanks I had actually seen this while looking into a workaround for us. However I thought that LitHTML elements only worked with other LitHTML elements since you need the correct bundler for it. StencilJS projects don't have any bundling system.

LitHTML and LitElement don't need a specific bundler, they work with whatever tools (or not) you'd like. You might want to get them another look!

Be sure to checkout lit-html and LitElement (https://lit-html.polymer-project.org & https://lit-element.polymer-project.org)...what you've written about here already exists!

Also give StencilJS a look. It's a compiler instead of a framework or library. The end result is pure vanilla components https://stenciljs.com/