Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML with Superpowers: An Introduction to Web Components

htmlwithsuperpowers.netlify.app

Post reply on HN
Print view View original

91–100 of 130 posts

Re: HTML with Superpowers: An Introduction to Web Components

#91

Post by dmitriid »

azangru wrote: post #78
dmitriid wrote: post #62

Earlier quoted context omitted.

> Examine html source of such sites as Just because someone uses a technology, doesn't mean it's good. I could point to plenty of sites still using first versions of Angular. Is it workable? Yes. Is it good? Also, I'd skip youtube as an example. No idea what incentives they had internally to re-write everything in web components, but they (and the web) paid dearly for it: - Youtube was re-written in v0 of Custom Comp…

> Just because someone uses a technology, doesn't mean it's good. At least it shows that the technology is both scalable and battle-tested. > I could point to plenty of sites still using first versions of Angular. Is it workable? Yes. Is it good? It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later. Meanwhile, web components are the browser standard, which means…

> At least it shows that the technology is both scalable and battle-tested.

So are all other technologies used on the web sites. It still doesn't make it good.

You keep pretending that if something is used somewhere means it's good.

> It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later.

So what? Neither of these technologies have the laundry list of issues that web components have. And jQuery is still used on significantly more sites than React and Web Components combined. I'd bet on survival of jQuery more than on survival of Web Components.

> Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay.

Unfortunately, yes. They are here to stay: a badly designed, barely working technology that needs increasingly complex and arcane hacks to make up for its deficiencies, sucking up human resources and making browser engines incomprehensibly complex. Oh, and they also infect other standards that have to cater to them now. E.g. Scoped CSS covers 80-90% of use cases WCs are used for, but now it has to be butchered to accommodate Shadow DOM.

But yeah. It's here to stay.

As Rich Harris, the author of Svelte said, "it's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1]

There's a reason why very few, if any, of the major frameworks, and very few of up-and-coming web frameworks use web components as the foundation. Well, not one reason, but multiple extensively documented, discussed and debated reasons. However, WC proponents couldn't care less about these reasons because "but look, it's in the browser now".

So. What.

marquee was in the browser. Custom elements v0 was in the browser. Many things were, or indeed still are, in the browser. Doesn't make them good technology. We're here 12 years after they were introduced and they still have the issues that a non-wc library by even a first year CS student wouldn't have on the first try:

- form participation, "solved" by throwing more JS at the problem

- a11y boundaries, will through more JS at the problem when AOM arrives perhaps 10 years from now

- incorporating SVGs, will never be solved. That is, doing will never be possible. Not an issue for literally any non-wc framework.

- SSR is barely solved by DSD if at all

- etc. etc.

And 12 years later people are actually exploring ideas without components as those are pure overhead: https://dev.to/this-is-learning/components-are-pure-overhead...

[1] https://twitter.com/Rich_Harris/status/1513668040784814084

Re: HTML with Superpowers: An Introduction to Web Components

#92

Post by lordgroff »

dmitriid wrote: post #90
lordgroff wrote: post #81

Earlier quoted context omitted.

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 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. A…

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.

Re: HTML with Superpowers: An Introduction to Web Components

#93

Post by asurty »

pjmlp wrote: post #87
asurty wrote: post #8

Earlier quoted context omitted.

IMO they are complimentary to react. Frameworks like react/angular/backbone/vue solve the problem of creating a single page application with a nice architecture and sharing code between components within the SPA. Web components solve the problem of sharing code between any application. There are opportunities to share code (eg/ data binding) and I believe that is the case (they use the same underlying browser APIs wh…

With exception of React, all those frameworks have options to generate WebComponents for their component model.

That is cool, didn't realize that! I wonder why React lags behind ( ? )

Re: HTML with Superpowers: An Introduction to Web Components

#94

Post by pjmlp »

asurty wrote: post #93
pjmlp wrote: post #87

Earlier quoted context omitted.

With exception of React, all those frameworks have options to generate WebComponents for their component model.

That is cool, didn't realize that! I wonder why React lags behind ( ? )

I think it is a culture issue, as far as I understand the underlying issue, the React community is not so impressed with having to deal with Web Components.

Re: HTML with Superpowers: An Introduction to Web Components

#95

Post by microflash »

qwtel wrote: post #22

Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable. It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to t…

I've been working with webcomponents for a while. I agree that ergonomics are horrible (particularly when it comes to state management and style inheritance) but it is still better than being in a continuous churn of UI frameworks.

Unfortunately, it is the same churn that has vastly improved the ergonomics for many UI frameworks while we're stuck with the terrible workflows for authoring web components.

Re: HTML with Superpowers: An Introduction to Web Components

#96

Post by dmitriid »

microflash wrote: post #95
qwtel wrote: post #22

Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable. It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to t…

I've been working with webcomponents for a while. I agree that ergonomics are horrible (particularly when it comes to state management and style inheritance) but it is still better than being in a continuous churn of UI frameworks. Unfortunately, it is the same churn that has vastly improved the ergonomics for many UI frameworks while we're stuck with the terrible workflows for authoring web components.

> but it is still better than being in a continuous churn of UI frameworks.

Is there a continuous churn?

React is 10 years this year. Vue is 9 years. Angular which feels positively ancient is 7 years (if we only count Angular 2.x).

Yes, there are newcomers like Svelte and Solid, but it's hardly a churn. Besides, they explore valuable corners that are left untouched and unexplored by other frameworks. Things like granular reactivity and removing components as a unit of UI in its entirety.

Meanwhile the "non-churn" in web components has already resulted in two deprecated standards (custom elements v0, html imports), and is rapidly churning out dozens of new standards requiring more and more javascript to paper over their egregious design (form participation, constructible stylesheets, declarative shadow dom...)

Re: HTML with Superpowers: An Introduction to Web Components

#97

Post by dmitriid »

pjmlp wrote: post #94
asurty wrote: post #93

Earlier quoted context omitted.

That is cool, didn't realize that! I wonder why React lags behind ( ? )

I think it is a culture issue, as far as I understand the underlying issue, the React community is not so impressed with having to deal with Web Components.

Realistically, there's almost no community that is impressed with having to deal with Web Components.

In this discussion I keep reiterating: there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them. And even that is rife with problems.

Re: HTML with Superpowers: An Introduction to Web Components

#98

Post by microflash »

dmitriid wrote: post #96
microflash wrote: post #95

Earlier quoted context omitted.

I've been working with webcomponents for a while. I agree that ergonomics are horrible (particularly when it comes to state management and style inheritance) but it is still better than being in a continuous churn of UI frameworks. Unfortunately, it is the same churn that has vastly improved the ergonomics for many UI frameworks while we're stuck with the terrible workflows for authoring web components.

> but it is still better than being in a continuous churn of UI frameworks. Is there a continuous churn? React is 10 years this year. Vue is 9 years. Angular which feels positively ancient is 7 years (if we only count Angular 2.x). Yes, there are newcomers like Svelte and Solid, but it's hardly a churn. Besides, they explore valuable corners that are left untouched and unexplored by other frameworks. Things like gran…

There's definitely a churn in the frameworks like React, Angular, Vue, etc. New APIs, breaking changes, etc are certainly a thing every year. But as always, this is both downside and upside: you get great features and valuable advances at the cost of such rapid changes.

The good news is that the tooling around the Web components is evolving even when the standard itself may moving at glacial pace.

Re: HTML with Superpowers: An Introduction to Web Components

#99

Post by pjmlp »

dmitriid wrote: post #97
pjmlp wrote: post #94

Earlier quoted context omitted.

I think it is a culture issue, as far as I understand the underlying issue, the React community is not so impressed with having to deal with Web Components.

Realistically, there's almost no community that is impressed with having to deal with Web Components. In this discussion I keep reiterating: there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them. And even that is rife with problems.

If we ignore the fact that everyone else supports them, regardless if they are their foundation or not.

https://custom-elements-everywhere.com/

Re: HTML with Superpowers: An Introduction to Web Components

#100

Post by psygn89 »

Existenceblinks wrote: post #83
qwtel wrote: post #22

Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable. It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to t…

In almost a decade I never understand why anyone would use Shadow DOM. What's the point of scoped style solution here. Why can't I just™ styff ? .. admittedly I never scope style because I never have to add 3rd party components with style in it.

One of the key goals in components is the ability to use it anywhere. Shadow DOM helps with that but also feels like a big thorn in the side for a lot of designers and developers to operate within. It makes more sense to design components this way when you're starting fresh and creating a library to be used anywhere. Controversially, I'd say it's often easier to just write CSS rules that fixes these conflicts and that the Shadow DOM is not really worth bending over for if you're designing within a controlled environment like your own product.
Post reply on HN