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

If Web Components are so great, why am I not using them?

daverupert.com

Post reply on HN
Print view View original

101–110 of 189 posts

Re: If Web Components are so great, why am I not using them?

#101

Post by pjmlp »

racedude wrote: post #63
afavour wrote: post #29

IMO the main reason more people aren’t using Web Components is because React doesn’t support them. Preact does it just fine so I have to assume it’s possible but simply not in the interests of the React team. React feels like the enterprise lock-in of 2020s development: if you use it you’re using it top to bottom and it’s very difficult to mix and match with other frameworks. It’s a shame.

Where do you see React doesn’t support web components?.. also many frameworks have wrappers around web components specifically for frameworks like Vue and React for things like passing other values than strings.

In Angular and Vue, their component model nowadays can be mapped into web components directly, it is only a matter of configuration.

React pretends they don't exist.

Re: If Web Components are so great, why am I not using them?

#102

Post by mock-possum »

herpdyderp wrote: post #23

I've been using web components now for years and I will do everything I can to never write frontends in anything else. I totally agree with point 2 though: the Polymer phase was very weird, but, as mentioned, https://lit.dev is great and, imo, the perfect abstraction.

Lit is so good. It’s just enough extra on top of native web components - to be useful, but without feeling like it stacks a bunch of extra bullshit. I really wish more teams were into it.

Re: If Web Components are so great, why am I not using them?

#103

Post by MrJohz »

lelanthran wrote: post #96
8n4vidtmkvmk wrote: post #88

Earlier quoted context omitted.

I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. And this is indeed slow AF. If you batched everything into a DocumentFragment or similar before attaching it to the DOM then it'd be fast. I don't know how you do that ergonomically though.

> I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. Is it really immediately? I thought that was a myth. I thought that, given toplevel function `foo()` which calls `bar()` which calls `baz()` which makes 25 modifications to the DOM, the DOM is only rerendered once when foo returns i.e. when control retu…

Yes and no.

The browser will, as much as it can, catch together DOM changes and perform them all at once. So if `baz` looks like this:

    for (let i=0; i
Then the browser will only recalculate the size of `elem` once, as you point out.

But if we read the state of the DOM, then the browser still needs to do all the layout calculations before it can do that read, so we break that batching effect. This is the infamous layout thrashing problem. So this would be an example of bad code:

    for (let i=0; i
Now, every time we read `offsetHeight`, the browser sees that it has a scheduled DOM modification to apply, so it has to apply that first, before it can return a correct value.

This is the reason that libraries like fastdom (https://github.com/wilsonpage/fastdom) exist - they help ensure that, in a given tick, all the reads happen first, followed by all the writes.

That said, I suspect even if you add a write followed by a read to your `while(1)` experiment, it still won't actually render anything, because painting is a separate phase of the rendering process, which always happens asynchronously. But that might not be true, and I'm on mobile and can't test it myself.

Re: If Web Components are so great, why am I not using them?

#104

Post by dmazzoni »

superkuh wrote: post #3
8chanAnon wrote: post #2

I have no idea what Web Components are or why I should care. Is that the problem?

One part of web components is custom HTML elements which basically means HTML elements that mean nothing until javascript execution gives them meaning. You differentiate them from the normal HTML element naming by using hyphens in the names. When I go to a website and all I see if a bunch of blank gray boxes that means they're using web components. It encourages developers to not put the text or images in the HTML an…

FWIW, all the major screen readers fully support JavaScript. There's nothing inherently inaccessible about a website that uses JavaScript. In fact, the screen readers don't actually interpret the JavaScript at all - they just react to the page dynamically changing, it doesn't matter how it's accomplished.

Re: If Web Components are so great, why am I not using them?

#105

Post by dmazzoni »

Web components have had accessibility gaps since the beginning. I spent years working on specs and implementations to close the gap, It's insanely frustrating just how slow standardization work can be.

I'm partially relieved that web components never became that popular, because that would have made accessibility on the web worse.

Re: If Web Components are so great, why am I not using them?

#106

Post by dexwiz »

8n4vidtmkvmk wrote: post #88
_gabe_ wrote: post #86

Earlier quoted context omitted.

I've always wondered why this notion is so popular (is it just because of what react does)? Wouldn't the native browser be expected to handle a DOM re-render much more efficiently than an entire managed JS framework running on the native browser and emulating the DOM? Maybe in 2013 browsers really really sucked at re-renders, but I have to wonder if the myriads of WebKit, Blink, Gecko developers are so inept at their…

I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. And this is indeed slow AF. If you batched everything into a DocumentFragment or similar before attaching it to the DOM then it'd be fast. I don't know how you do that ergonomically though.

This is not true. The browser will only repaint when the event loop is empty. A bunch of synchronous DOM updates will result in one rerender.

Re: If Web Components are so great, why am I not using them?

#107

Post by thayne »

no_wizard wrote: post #48
dxchester wrote: post #20

The main reason is that they're too low-level to use directly. They do a lot, but stop just short of being useful without something of a framework on top. I tried hard to use them directly, but found that it was untenable without sensible template interpolation, and without helpers for event binding. Here's my shot at the smallest possible "framework" atop Web Components that make them workable (and even enjoyable) a…

Template Instantiation is suppose to be the answer at least in part, but it’s been held up since 2017[0] The bigger problem is that the web platform stakeholders (IE the committees that industry influence and the browser makers) simply didn’t listen at all to what regular developers have been saying about what they want from the web platform w/r/t better built in platform provided primitives. It’s seems to me like we…

Supposedly more declaritive APIs and data binding are coming eventually. But who knows how long we will have to wait for that.

Re: If Web Components are so great, why am I not using them?

#108

Post by lelanthran »

MrJohz wrote: post #103
lelanthran wrote: post #96

Earlier quoted context omitted.

> I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. Is it really immediately? I thought that was a myth. I thought that, given toplevel function `foo()` which calls `bar()` which calls `baz()` which makes 25 modifications to the DOM, the DOM is only rerendered once when foo returns i.e. when control retu…

Yes and no. The browser will, as much as it can, catch together DOM changes and perform them all at once. So if `baz` looks like this: for (let i=0; i Then the browser will only recalculate the size of `elem` once, as you point out. But if we read the state of the DOM, then the browser still needs to do all the layout calculations before it can do that read, so we break that batching effect. This is the infamous layo…

> Now, every time we read `offsetHeight`, the browser sees that it has a scheduled DOM modification to apply, so it has to apply that first, before it can return a correct value.

That makes perfect sense, except that I don't understand how using a shadow DOM helps in this specific case (A DOM write followed immediately by a DOM read).

Won't the shadow DOM have to perform the same calculations if you modify it and then immediately use a calculated value for the next modification?

I'm trying to understand how exactly a shadow DOM can perform the calculations after modifications faster than the real DOM can.

Re: If Web Components are so great, why am I not using them?

#109

Post by MrJohz »

dexwiz wrote: post #106
8n4vidtmkvmk wrote: post #88

Earlier quoted context omitted.

I think the reason that the browser is so slow is that every time you mutate something, an attribute or add or remove an element, the browser rerenders immediately. And this is indeed slow AF. If you batched everything into a DocumentFragment or similar before attaching it to the DOM then it'd be fast. I don't know how you do that ergonomically though.

This is not true. The browser will only repaint when the event loop is empty. A bunch of synchronous DOM updates will result in one rerender.

It's partially true. Layout and repaint are two separate rendering phases. Repaint happens asynchronously, as you point out. But layout (i.e. calculating heights, widths, etc of each box) is more complicated. If the browser can get away with it, it will batch potential layout changes until directly before the repaint - if you do ten DOM updates in a single tick, you'll get one layout calculation (followed by one repaint).

But if you mix updates and reads, the browser needs to recalculate the layout before the read occurs, otherwise the read may not be correct. For example, if you change the font size of an element and then read the element height, the browser will need to rerun layout calculation between those two points to make sure that the change in font size hasn't updated the element height in the meantime. If these reads and writes are all synchronous, then this forces the layout calculations to happen synchronously as well.

So if you do ten DOM updates interspersed with ten DOM reads in a single tick, you'll now get ten layout calculations (followed by one repaint).

This is called layout thrashing, and it's something that can typically be solved by using a modern framework, or by using a tool like fastdom which helps with batching reads and writes so that all reads always happen before all writes in a given tick.

Re: If Web Components are so great, why am I not using them?

#110

Post by sbergot »

ilaksh wrote: post #89

There doesn't need to be a practical reason for something to not be popular. Popularity and merit are not the same thing. Web components aren't popular because they haven't become popular yet. There is a lack of sufficient network effect moving in that direction. Once they start becoming popular, the issues with them (which are relatively minor) will be resolved quickly and improvements added. Why are most of our cit…

The design of cars has evolved a lot, mainly because of security regulations. Cities is another topic. They change slowly because of the required investment but in europe at least there is definitely a trend toward walkable blocks which changes a lot of urbanisation guidelines.

I agree with your first sentence: things are unpopular by default. However I disagree with your assumption: web components won't become magically popular overtime without a good reason for them to be used over all the other options. Your "flavor-of-the-month" take ignores the fact that react is now 10 years old and is boring tech. It is still one of the most widely used frontend framework.

Post reply on HN