Web Components are all generally be "stand-alone"

[Westbrook]

Upon review of the available element options, I think I have a better grasp of what the "original" intent for the words "stand-alone" is: single element repositories. This is pretty evident from the existing listings and their all being featured by their GitHub repo. In light of this, I present this PR to open a broader conversation into what represents a "stand-alone" element, and whether this list should be expanded on by way of single element NPM installs.

In that very few of the previously included elements are "vanilla" or "dependency-free", I've made a speculative addition of "Button Elements" and listed a handful of said elements that can be installed from NPM and used stand-alone without additional "cherry-picking". Like other elements herein, they rely on dependencies like lit-element and/or sibling packages in a greater project, but being web components do not require that they are "called" by a parent framework and therefore "framework-agnostic".

Thanks in advance for considering this PR. I can certainly understand if our definitions of "stand-alone" diverge, and would hope you take the opportunity to further outline your thoughts on a definition there to guide future PRs and issues if they do. If you're interested in my definition, I'd be happy to submit further PRs with similar expansions to the listings featured here.

Cheers!

[davatron5000]

Thanks for bringing this up. I'll try to summarize how I differentiate.

1. I want to promote elements that people can start using with only a <script> tag and possibly a stylesheet. And are advertised as such. The ability npm install is great, but would prefer it to work without that technical hurdle.
2. If it is something you npm install try to browse through the package.json and look at dependencies. If I see lit-element or stencil, I tend to bail even though I like those quite a lot.
3. I'd like the elements on this list to be more "General Use" and not encumbered by a specific framework or design system.
4. I'd like to focus more on the usefulness than on the documentarian-of-everything-out-there-ness. The list becomes less useful to me if there's 30,000 variations on a button component.

If some elements exist here that violate this approach, that's unintentional. I tried. But I'm also allowing myself some room for subjectivity as to what I think people would find useful or "awesome".

[justinfagnani]

If I see lit-element or stencil, I tend to bail even though I like those quite a lot.

What is the purpose of that? I've used lit-element to implement a few standalone elements, that are not part of a design system, nor tied to any framework. It's still damn useful to use helpers to implement rendering and property/attribute synchronization.

[web-padawan]

Actually, if you stick to vanilla, that should be explicitly clarified.

I was wondering whether this list would be a proper place for <api-viewer> because it is built with LitElement.

[davatron5000]

What is the purpose of that?

@justinfagnani My thinking here is that library or framework dependencies take away from the "standalone" nature. If the door is open too wide and someone sees this list and starts pasting scripts or npm installing things; then they'll likely end up with stencil, lit, vaadin and whatever else on their page.

There's some je ne sais quoi to it.

Like I see your <chess-board> (#5) has a lit-element dep. Rad. I like lit-element. I also like that you can use it with the ?module flag on unpkg.

<script type="module" src="https://unpkg.com/chessboard-element?module"></script>

That's very standalone to me.

But then spinning up a demo, I see that lit imports 25 different JS files. That's not super standalone.

Actually, if you stick to vanilla, that should be explicitly clarified.

@web-padawan I think this thread is about trying to define whether or not we're sticking to strictly vanilla or not.

Edit: Didn't meant to hit submit. But really I'm open. If lit makes this more useful, then awesome.

[justinfagnani]

@davatron5000 IMO, the dependencies of an element shouldn't matter to it's "standalone" nature. Plenty of relatively standalone widgets in the classic style had dependencies, you just had to add their scripts to the page. Modules make this quite a bit more tractable. And there's really nothing wrong with having lit, stencil, and vaadin, on the same page.

One thing we're definitely not trying to do is create web component silos where users only pick an element if it uses a particular helper under the hood. That would blunt the interop benefit of web components almost completely.

The other point you raise is basically just about bundling. The chessboard demo loads directly from unpkg.com with no build basically because it can. It could easily run Rollup and include the bundle with the site. Would the change the "standalone" nature of the element? It's API, usability, and independence of any specific framework would remain the same. And regardless of dependencies, a component could self-organize into many modules itself. That shouldn't impact it's standalone nature either.

I see you merged the katex elements... and those load a very large katex dependency. How is that different?

[davatron5000]

And there's really nothing wrong with having lit, stencil, and vaadin, on the same page.

Do I need to bring Alex Russell into this conversation? 😂

I see you merged the katex elements... and those load a very large katex dependency. How is that different?

For katex, I felt like if you were loading a thing to render math formulas, you'd probably expect the math formula-renderer thing to be there.

One thing we're definitely not trying to do is create web component silos where users only pick an element if it uses a particular helper under the hood.

Y'all obviously have a better understanding of the WC ecosystem than I do. I'm mostly looking at it from a "how can i use something today without installing all of npm in the process?" perspective. If removing the No-Lit/Stencil requirement satisfies that and it still maintains the spirit, then I'm down. If there's a way to communicate this loose "standalone" / "no strings attached" concept, then I'm open to verbiage for that as well.

[ManzDev]

Maybe change to table format instead list format (and include a column with method)?

For example:

Custom element	Uses
<lite-youtube>
<chess-board>	LitElement

I consider it interesting to know that information, but I would not rule out a custom element because of its technology.

[web-padawan]

how can i use something today without installing all of npm in the process?

Sounds like we could agree on a standalone as "available through CDN":

• https://unpkg.com CDN with ?module
• https://www.pika.dev/cdn

This still needs some effort from the element authors, e.g. to ensure the dependencies (if any) provide ES module version that can be handled by those CDN providers.

Then it would make sense to list CDN in the table as mentioned above. We could also add bundle size badge there so people can take that into account.

@davatron5000 WDYT?