Hacker News new | ask | show | jobs
by lordgroff 1253 days ago
It obviously hasn't happened, but I hope that web components eventually make serious inroads. A UI library for React, Vue, Svelte, Solid, whatever... Imagine being able to have a component library that works with any of them (or none of them).

Since I really like mithril and there's one UI library, I've been playing with Shoelace and Crayons and they're pretty nice to work with, but I remain a bit puzzled why there's so few players in the space.

6 comments

Stencil and consequently Ionic are all Web Component based.

Svelte fully supports compiling to Web Components with 100% test coverage.

Vue fully supports Web Components as well, the only issue I've run into there is with CustomEvent.detail not being copied into the Vue event payload properly.

Web Components are widely used on the web, just under the covers sometimes.

VueJS actually fails some advanced tests for WebComponents: https://custom-elements-everywhere.com/

So, VueJS docs are actually incorrect when they say it scores 100%. The actual score is 91%.

I had reported this 8 months ago.

For people too lazy to look into what the issues are: lack of support for CAPScase, camelCase, and PascalCase DOM events. Only lowercase and kebab-case work.
Why is this getting downvoted? Did I miss something? I only found those 6 errors (each occurs in two tests, so 3 types)
Svelte will remove compiling to web components into a plugin.

In general, none of the major frameworks, and very few of the new frameworks use web components as a foundation for their functionality for many extensively described reasons that wc proponents literally couldn't care less about.

> A UI library for React, Vue, Svelte, Solid, whatever... Imagine being able to have a component library that works with any of them (or none of them).

That seems to be a worthy goal, but I don't see that being usable in prod projects, at least not in the near future.

The closest I've seen is something like PrimeFaces, which has components for Angular, React and Vue, which is the majority of projects I've seen out there: https://www.primefaces.org (I've also used the Java JSF variety, it was... sometimes problematic)

If you need something that works the same (or as close as you can get) across multiple front end frameworks/libraries, while still having most of the components you could possibly want, I don't think there are many other options out there.

For example:

- Angular calendar: https://www.primefaces.org/primeng/calendar

- React calendar: https://www.primefaces.org/primereact/calendar/

- Vue calendar: https://www.primefaces.org/primevue/calendar

Still the same issue though. What about Svelte? What about solid? What about mithril?

I know this might seem like a "who cares" sort of thing since the industry has standardized on the three listed, but I find all three overkill for a lot of things and, for example, keep my small projects in Mithril. But then I'm hit with either using Construct UI (which is honestly ok, this is all internal stuff), or having to make all the components myself.

What makes it such an impossibility for production? Even if, as in the case of Ionic, they provide web components but also wrap them up for React, Vue and Angular.

> I know this might seem like a "who cares" sort of thing since the industry has standardized on the three listed

It is that sort of thing and it breaks my heart that this is the case.

And yet, supporting solutions that would work with any front end solution and do so well without death by committee is some ways off, if not outright impossible.

It's very much the same way how I love Firefox but when >95% of your userbase is on Chrome, you need to pay additional attention to testing and compatibility against it.

It's also very much how many of the SaaS solutions or even self-hostable tools and such might have integrations for most of the popular languages/frameworks/libraries out there, yet keep the niche ones unsupported due to a lack of market share.

So for now, I'll just take what I can get, in lieu of better options.

Microsoft has a library called FluentUI: https://learn.microsoft.com/en-us/fluent-ui/web-components/
Esri’s Calcite Component library is another.

https://github.com/Esri/calcite-components

> A UI library for React, Vue, Svelte, Solid, whatever... Imagine being able to have a component library that works with any of them (or none of them).

You don't need web components for that. You need https://open-ui.org (started, of all people, by Microsoft). Unfortunately Google et al are too busy sinking hundreds of millions of dollars and countless man-hours into web components (with no final goal in mind and increasingly arcane and complex workarounds for their deficiencies) to be interested in this.

> but I remain a bit puzzled why there's so few players in the space.

In which space?

In UI libs for the web? There are thousands, all busy re-implementing the same dozen-or-so primitive controls.

In UI libs for web components? Because they are a badly designed tech that still requires you to reinvent the same dozen-or-so primitive controls and combat the issues of styling, a11y, no SSR etc. that they bring.

Can you explain how open-ui solves the problem? I went on the website, and to be fair I didn't really get it, but say for <breadcrumb /> component they give a proposal of what the HTML would look like in their proposed solution with nav, ok, li elements. How does this replace the idea of having a breadcrumb web component which is a higher level abstraction?
> Can you explain how open-ui solves the problem?

It doesn't solve the problem, but would solve the problem if it was started 10 or 20 years ago.

This is what needed in the browser: an actual properly specified comprehensive set of controls. Web Components are not it, as they continue re-inventing the wheel with the same components that libraries where defining since the dawn of the web: buttons, avatars, tabs etc. All of them different, all of them incomplete, all of them inaccessible etc.

> but say for <breadcrumb /> component they give a proposal of what the HTML would look like in their proposed solution with nav, ok, li elements. How does this replace the idea of having a breadcrumb web component which is a higher level abstraction?

Because if you go to any UI library for the web, it's one of the components almost everyone defines. As you can see in the research for each component. What does having it as a web component give you? Nothing. It gives you fifteen hundred different incompatible re-implementations [1]

Having a higher level abstraction you don't need to re-implement it, you don't have to to manually provide additional things (like accessibility hints etc.)

In general, if everyone attempts to implement the same elements in the browser, it makes sense to have them as a part of the platform, doesn't it?

[1] https://shoelace.style/components/breadcrumb, https://web-components.carbondesignsystem.com/?path=/story/c..., https://vivid.vonage.com/?path=/story/alpha-components-bread..., https://sap.github.io/ui5-webcomponents/playground/component..., https://ionicframework.com/docs/api/breadcrumbs ...

Ooooh I see. So the idea is to add all the extra (standardized) components to the browser itself! Yes, that is a worthy goal indeed.
And here I am, just using vanilla JS to add functionality to default HTML. Recently did a few simple fetch and render functions and it worked fine. I guess if you go with large data structs it might be a different ball game I guess.
Kor UI is an open source UI library, if you want to check: https://kor-ui.com/introduction/welcome