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

111–120 of 130 posts

Re: HTML with Superpowers: An Introduction to Web Components

#111

Post by TeMPOraL »

psygn89 wrote: post #100
Existenceblinks wrote: post #83

Earlier quoted context omitted.

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 tha…

From the POV of a user, I consider Shadow DOM a menace, as it creates areas of the DOM that cannot be reached by CSS from outside - defeating my ability to fix UI blunders and bad design with a tailored userstyle.

Re: HTML with Superpowers: An Introduction to Web Components

#112

Post by chiefalchemist »

bobthepanda wrote: post #110
chiefalchemist wrote: post #66

Earlier quoted context omitted.

Yes. To my point and yours, SB's hero or product card can have exactly the same underlying markup as McDee's. Where those brands, and brands, are able to part is the CSS. The irony is, marketing agencies that do web design work for multiple clients should be looking to leverage web component bricks. The majority I've seen, are not; at least not yet.

Eh, brands are internally consistent but rarely consistent with each other to the point where that would be less trouble than it’s worth. If you tell a client they’re not compatible with you, they’ll just find someone else to hire.

They're not deciding. The FE dev team is. Look at Bootstrap or Tailwind. Those tools have been adopted by many teams across many companies. A solid library of web components isn't going to be all that different. Who wants to reinvent the wheel then you can pull one off the shelf and get going?

There is not a single soul in marketing at any company - small or big - that's going to see, "Before you deploy I want to see the markup..." :)

Re: HTML with Superpowers: An Introduction to Web Components

#113

Post by spiralx »

TeMPOraL wrote: post #111
psygn89 wrote: post #100

Earlier quoted context omitted.

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 tha…

From the POV of a user , I consider Shadow DOM a menace, as it creates areas of the DOM that cannot be reached by CSS from outside - defeating my ability to fix UI blunders and bad design with a tailored userstyle.

I hadn't considered that at all because they're so little used, but it would be an issue if they became so. I'm using Stylus for user styles nowadays which provides an option to allow you to target the CSS within an IFRAME using

    html[stylus-iframe$="twitter.com"] h1 { display:none }
and I guess they could provide a similar sort of hack to select the Shadow DOM of an element to apply CSS e.g.

    .comment:shadow .title { font-size: 1.1rem; }
Seems pretty likely to be be a performance hog to do that though.

Re: HTML with Superpowers: An Introduction to Web Components

#114

Post by TeMPOraL »

spiralx wrote: post #113
TeMPOraL wrote: post #111

Earlier quoted context omitted.

From the POV of a user , I consider Shadow DOM a menace, as it creates areas of the DOM that cannot be reached by CSS from outside - defeating my ability to fix UI blunders and bad design with a tailored userstyle.

I hadn't considered that at all because they're so little used, but it would be an issue if they became so. I'm using Stylus for user styles nowadays which provides an option to allow you to target the CSS within an IFRAME using html[stylus-iframe$="twitter.com"] h1 { display:none } and I guess they could provide a similar sort of hack to select the Shadow DOM of an element to apply CSS e.g. .comment:shadow .title {…

Yeah, I don't see Shadow DOM often, but there are couple sites I use that employ it - most notably Gerrit. Since I use it almost every work day, I wanted to fix a bunch of UX annoyances it has. Those fixes would've normally been trivial, but Gerrit UI has everything wrapped in multiple levels of Shadow DOM, making those fixes near-impossible instead to do in Stylus alone.

Re: HTML with Superpowers: An Introduction to Web Components

#115

Post by spiralx »

TeMPOraL wrote: post #114
spiralx wrote: post #113

Earlier quoted context omitted.

I hadn't considered that at all because they're so little used, but it would be an issue if they became so. I'm using Stylus for user styles nowadays which provides an option to allow you to target the CSS within an IFRAME using html[stylus-iframe$="twitter.com"] h1 { display:none } and I guess they could provide a similar sort of hack to select the Shadow DOM of an element to apply CSS e.g. .comment:shadow .title {…

Yeah, I don't see Shadow DOM often, but there are couple sites I use that employ it - most notably Gerrit . Since I use it almost every work day, I wanted to fix a bunch of UX annoyances it has. Those fixes would've normally been trivial, but Gerrit UI has everything wrapped in multiple levels of Shadow DOM, making those fixes near-impossible instead to do in Stylus alone.

Some combination of Tampermonkey, MutationObserver and IntersectionObserver almost always gets there in the end, but despite having a default user script template with this exact skeleton it's a lot more of a pain in the arse to achieve what a simple CSS selector and some properties does in a few lines...

Re: HTML with Superpowers: An Introduction to Web Components

#116

Post by jongjong »

dmitriid wrote: post #76
replygirl wrote: post #72

Earlier quoted context omitted.

it's not that much to invent. have frameworks really made it so easy that we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects? gp says there's a performance objective, sometimes it's worth building a solution that only does what you need edit: no one is saying a purpose-built framework needs to do everything that a mass-market framework ecosystem does. it's disingenu…

> we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects I mean, you can do all that. And either spend your time writing tons of boilerplate code, or reinventing half of those frameworks and libraries anyway. And still having to deal with issues like having to remember that they don't participate in forms (more JS to each component), that a11y can suddenly be broken (wh…

I wouldn't say that you need to reinvent any framework. I was able to build a simple application using HTMLElement directly. I just had to define a handful of utility functions to do things like escape HTML tags for user-generated content... The main critique I can think of is that Web Components provide many ways to do things; for example, you can create elements using vanilla JS or using template strings (or even a combination of both)... When it comes to event handlers; you can also define them using vanilla JS or inline inside the tags as part of the template string (or both). There is no single standard way to do anything so that was the real challenge but this can easily be solved through project-based coding style guidelines. There aren't that many gotchas.

Re: HTML with Superpowers: An Introduction to Web Components

#117

Post by pjmlp »

dmitriid wrote: post #107
pjmlp wrote: post #99

Earlier quoted context omitted.

If we ignore the fact that everyone else supports them, regardless if they are their foundation or not. https://custom-elements-everywhere.com/

> everyone else supports them That's what I said: At best they can consume/embed them and perhaps compile to them. > regardless if they are their foundation or not. And the fact that they are not forming the foundation of these frameworks should be examined and fixed, not ignnored. However, wc proponents ignore this entirely.

Maybe because those frameworks don't want to be rewritten from scratch?

It is like asking why so many graphics engines get written, instead of using raw OpenGL/Vulkan calls and extension spaghetti all over the place.

Re: HTML with Superpowers: An Introduction to Web Components

#118

Post by dmitriid »

pjmlp wrote: post #117
dmitriid wrote: post #107

Earlier quoted context omitted.

> everyone else supports them That's what I said: At best they can consume/embed them and perhaps compile to them. > regardless if they are their foundation or not. And the fact that they are not forming the foundation of these frameworks should be examined and fixed, not ignnored. However, wc proponents ignore this entirely.

Maybe because those frameworks don't want to be rewritten from scratch? It is like asking why so many graphics engines get written, instead of using raw OpenGL/Vulkan calls and extension spaghetti all over the place.

> Maybe because those frameworks don't want to be rewritten from scratch?

The absolute vast majority of new frameworks don't use web components as the foundation.

Perhaps instead of burying their heads in the sand people pushing web components would should finally start asking why?

Re: HTML with Superpowers: An Introduction to Web Components

#119

Post by dmitriid »

jongjong wrote: post #116
dmitriid wrote: post #76

Earlier quoted context omitted.

> we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects I mean, you can do all that. And either spend your time writing tons of boilerplate code, or reinventing half of those frameworks and libraries anyway. And still having to deal with issues like having to remember that they don't participate in forms (more JS to each component), that a11y can suddenly be broken (wh…

I wouldn't say that you need to reinvent any framework. I was able to build a simple application using HTMLElement directly. I just had to define a handful of utility functions to do things like escape HTML tags for user-generated content... The main critique I can think of is that Web Components provide many ways to do things; for example, you can create elements using vanilla JS or using template strings (or even a…

> I wouldn't say that you need to reinvent any framework.

You do, when you need at least slightly more complex.

> The main critique I can think of is that Web Components provide many ways to do things

Nope. The main critique is that Web Components is 2010s tech solidified in the platform when the rest of the world has moved on and is now exploring fine-grained reactivity and trying to remove components as a unit of work/ui. That they are 12 years in the making and still have issues that no framework has (see links here: https://news.ycombinator.com/item?id=34346269). That their design now poisons the rest of the platform that needs to add countless new workarounds for their shortcomings, and seemingly unrelated standards (like scoped CSS) now have to take them into consideration...

Well, there is not just one main critique, there are many main critiques

> There aren't that many gotchas.

Just because you haven't run into them it doesn't mean there aren't any gotchas. And there are plenty.

Re: HTML with Superpowers: An Introduction to Web Components

#120

Post by pjmlp »

dmitriid wrote: post #118
pjmlp wrote: post #117

Earlier quoted context omitted.

Maybe because those frameworks don't want to be rewritten from scratch? It is like asking why so many graphics engines get written, instead of using raw OpenGL/Vulkan calls and extension spaghetti all over the place.

> Maybe because those frameworks don't want to be rewritten from scratch? The absolute vast majority of new frameworks don't use web components as the foundation. Perhaps instead of burying their heads in the sand people pushing web components would should finally start asking why?

Usually I use https://angular.io/guide/elements, https://vuejs.org/guide/extras/web-components.html#using-cus... or https://lit.dev/

I only need to ask why, when I have to deal with React based stuff.

Post reply on HN