Hacker News new | ask | show | jobs
by jjcm 1988 days ago
I would say that this corollary would only be possible once webcomponents have form support in all browsers. In my opinion this is the last major hurdle before there is a native alternative for reusable components in the browser. Firefox is working on it[1] but there's no current roadmap for the work for Safari (though the initial form element proposal was well received by their team).

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1552313

2 comments

I don't think it will replace React, honestly.

WebComponents can do just a fraction of what React/Vue do, and it's just the least interesting parts. The encapsulation is great, of course, but it was already possible to have "reusable components" back in the jQuery days and before.

All the WebComponents usage I've seen professionally lately were wrapping React/Vue or using some other lightweight framework that does something similar.

Not saying WCs are bad tech: just saying I think there are some great ideas in Vue/React that still don't have a native API. Would LOVE to see a new version of WebComponents adopting some of those ideas (only the good ones though haha)!

We need a better term for front-end-js-frameworks than to keep typing react/vue, or variations of it like react/vue/angular, react/vue/svelte, react/vue/angular/svelte,
The term is Reactive but I wanted to be more specific.
The Shadow DOM spec always seemed like a good idea poorly implemented to me.

As well as the form issue, what made webcomponents untenable for me was that you can't use slots without opting the whole component into CSS encapsulation.

Great if you want to distribute components without fear of the consumer's CSS messing with your styles, absolutely useless if you want to extract common patterns in your own app because now you have to duplicate the relevant CSS in every component.