elm-get VS catalyst

Another interesting usecase, inspired by elm-package, is that tooling could be able to detect whether or not the public API of a custom element has changed, based on a snapshot of the current custom-elements.json file to decide the impact of an update, and potentially prevent breaking API change in patch or minor versions.

Reminds me of GitHub catalyst web component framework, which has targets & actions. https://github.com/github/catalyst

Working on the next Web UI (TypeScript + Catalyst).

Catalyst (opt-in via CLI flag)

They actually use a web component system, with a library called Catalyst used to make things a bit easier. They aren't simply doing raw DOM manipulation in Vanilla JavaScript, they're using components and what is essentially a fairly lightweight framework.

Personally, I'd really like to see the unmolested, with-dependencies versions[1].

This version is VERY easy to ship and adopt. But in my mind, these components hide how the sausage is made! Many were built with a library (Catalyst[2]), but the tools were obfuscated out in these end products.

There's a huge amount to be said for these web components. We need more models like this. But I also think there's an opportunity lost here, to teach, to inform, to help others learn how to build components, using the tech Github actually used to develop them.

[1] https://news.ycombinator.com/item?id=26439167

[2] https://github.com/github/catalyst

GitHub Catalyst is a library that makes it easier to develop Web Components.

The only real escape is using something like /r/webcomponents. I did some playing around with Github's new Catalyst framework over the holidays, quite enjoyed it. But you'd be one of the only people on the planet using it. Stick with whatever works for you.