The only way to get out of the current front end hell IMO is if we get client side import:

https://github.com/whatwg/html/issues/2791

I'm aghast at the comments in that thread. They are truly asleep at the wheel.

No wonder the front end is such a disaster with those mindsets running the show.

> I'm aghast at the comments in that thread. They are truly asleep at the wheel.

And the wheel that they're at is the one in a clown car. Which is driving off a cliff.

Just having a custom element `<my-include-html remote-src='...'>`[1] is enough to forgo 50% of the reason for using a front-end framework with a build-step.

[1] One that executes scripts, allows `<style>` tags, etc.

I mean <script type="module"></script> can do ECMAScript module imports.

That's a solved problem. You can create a custom element for that with some 5 lines of code. Or use one ready: https://github.com/justinfagnani/html-include-element

And that’s exactly what some people don’t want!

Some people will never be happy

Would this be different from using HTMX to load an HTML partial on page load?

Something like:

  <div hx-trigger="load" hx-get="/header.html"></div>

I looked at your docs:

- renders very weird on my iPhone iPhone 15 Pro Max in Safari 18.0. Consider responsive design for smaller screen sizes to restyle the sidebar and set a body max-width instead of a width. You might not expect your users to develop on phones, but you might have a hard time with adoption if the docs are mobile hostile.

- the “explore components” button at the bottom of the home page seems to link to nowhere

- site claims “Learn from well-structured, accessible component implementations” as an advantage but I didn’t find any links to the implementation from the docs

- site claims “No dependencies to manage or update” but isn’t astra-ui a dependency? It has a changelog (https://www.astra-ui.com/changes/). Likewise “Full control over the code and styling” I don’t understand how I can both have full control but also be taking a dependency on implementations provided by a library.

I’m curious why you’ve decided to release this library? I’ve come to view open-sourcing internal software as useful to the company for a few specific reasons but to generally be a time-sink without much return unless it’s accomplishing a goal. Component libraries need to fight for general ecosystem adoption or there’s no audience and you might as well not publish at all.

Really appreciate the write up here!

Maybe rough around the edges is an understatement haha, we are actively working to make the docs here better.

So a few things, these are very primitive components that can easily be updated and restyled.

There’s a given that there will be a dependency when using a library, right? The thing is with this you don’t even need to npm install if you don’t want to. Just plug and play.

As far as why… there isn’t much out there in terms of a web component driven component library and I think we’ve done some great stuff with ours. That plus we have customers embedding our components into their platform and it’s always helpful to see the source code.

I hear you on the docs quality though we will work on that.

Why aren't web components there/more popular yet? They seem like a fantastic solution

The cynic in me wants to say it’s because they aren’t VC backed so there’s no main catalyst driving them.

I don’t think a lot of people know about them, or if they do they have just heard about it in passing and have never actually used them.

Whatever the reason is they have a marketing problem that’s for sure.

Ah, well that's encouraging, if the tech itself is good, it means I can start using them more.

New developers follow social proof often instead of learning from first principles.

Web Components are seriously cool and worth looking at.

Social proof does tend to follow employment opportunities. If you're a new dev you don't have the luxury to make principled choices in technology, you're more worried about housing and food security and maybe paying back student loans. Asking new developers to trend-set the industry would be deeply unfair. If we want them to learn from first principles then entry level jobs should have first principles opportunities available.

I meant social proof like prejudice against technologies that employ but don’t seem popular and cool.

Another confusion might be expecting an employer to educate you. That’s part of it but not the requirement.

Self-directed learning is critical to go with any formal learning.

First principles are needing to be taught where or before people are learning things like react. But they don’t, and get pulled into a world of complexity.

Excellent, thank you!

Web Components have some nice features, some bad features, and no killer feature. Developers have mostly chosen to ignore them for other approaches (React, Vue) where there are better ergonomics and stronger network effects.

ShadowDOM should be a killer feature for people that wants to make web scrappers life a bit more difficult.

just do a quick scan in this thread, many say it's the one thing that makes web components not work for them. It's the opposite of what a killer feature means

What users/devs like and what CEO/PMs want (stop bot scrapping) are different things.

It was a joke tho, I use custom elements heavily but never with ShadowDOM. It is indeed a PITA.

> They seem like a fantastic solution

for which problem? They don't replace the need for a framework nor do they make writing in one easier. They don't make dev ex better. What is the actual use case? If they were highly useful, they would be used.

Creating self-contained components that don't rely on loading extra management code, in a standard way.

Maybe they aren't useful because the modern trend of web development is to not care about speed or size as much.

Implementation has been a big part https://news.ycombinator.com/item?id=36976670 (one of many discussions if you search for previous Hacker News articles)

Especially earlier on, web components were implemented without incorporating some of the major feedback from developers. What resulted was a low-level tool with some really awkward warts and APIs that was more-or-less unusable. (hence, one of the reasons why when web components discussions come up, lit is always mentioned since it needs that extra layer to paper over some of the warts)

TL;DR: it replaces some of the bad parts of Angular/React/etc. with its own set of bad parts that become more obvious only once you get deeper in.

Why would I used them over something like a Vue component?

They are framework-agnostic, meaning you're not locked into Vue, React, Angular, or any specific framework. They work natively in the browser, which makes them reusable everywhere, now and in the future.

> They are framework-agnostic

This is a selling point only if your job is producing component libraries. Otherwise, if you're an application developer, you'll be using a framework anyway.

Not entirely true. Making UI parts of your app using web components can future proof and prevent getting stuck on a framework.

I just rewrote my company's frontend ad code in webcomponents