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

161–170 of 189 posts

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

#161

Post by _gabe_ »

MrJohz wrote: post #99
_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…

As I understand it, there's a couple of issues with naively rerendering DOM elements like this. Firstly, the DOM is stateful, even in relatively simple cases, which means destroying and recreating a DOM node can lose information. The classic example is a text input: if you have a component with a text input, and you want to rerender that component, you need to make sure that the contents of the text input, the cursor…

Thanks for the info! This all makes sense to me intuitively, but I know I've been bitten in the butt several times by implementing clever caching schemes or something that end up slowing the app down more than I thought it would speed it up. It seems like it would be simple enough to set up a test case and benchmark this (you wrote a simple for loop above that should exhibit this behavior). I'm curious how much, if any, react actually ends up saving cycles when a programmer does the same code naively in react and naively in the browser. I think it would make for some interesting benchmarks at least :)

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

#162

Post by err4nt »

cogman10 wrote: post #16
err4nt wrote: post #8

Earlier quoted context omitted.

Even though I've never used Angular, and do not build web apps at all, we have put custom HTML elements to great use at work. It's also not about locking down styling, but it's a neat way to package up _functionality_ and behaviour that otherwise would be just defined ad-hoc in JavaScript, and to provide a dead simple way to (re)use that functionality in a declarative way from HTML.

Right, and that is a separate tech from web components. React, for example, does not use web components yet does exactly what you are describing. The problem web components is solving is just the strong encapsulation. Closing the escape hatches as it were.

HTML is supported natively in the browser, and custom HTML elements and their properties work at the same level as all other HTML elements as far as JavaScript, DOM, and dev tools are concerned.

React, while it may provide similar functionality to the programmer, is not natively understood, and while it can run in browsers, the 'components' in React are not handled in the same way in the browser as native HTML elements, JavaScript and its APIs don't know about them as HTML elements, DOM isn't aware of them (only their parts), and dev tools can't offer much insight because the app that's running is an unpredictable black-box to the browser.

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

#163

Post by superkuh »

dmazzoni wrote: post #104
superkuh wrote: post #3

Earlier quoted context omitted.

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.

There's nothing inherent no, just that javascript webpages, if some CDN doesn't load fast enough, or the dev uses some bleeding edge function not in all browsers, etc, will not end up having the text in the page. Whereas actually having the text in the page always has the text in the page.

JS sites almost always fail very badly when it fails (a relatively common event). Text sites cannot fail even when they fail.

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

#164

Post by webstrand »

kerkeslager wrote: post #114
webstrand wrote: post #93

Earlier quoted context omitted.

Without the shadow dom, though, what really is the difference from just using ` ` elements? You can't use slots, you're vulnerable to bad `querySelector`s, events aren't isolated, and you get none of the performance benefits. I've tried to find a workable solution using style inheritance, but it doesn't work everywhere. On code sandbox sites like codepen.io, the stylesheet is generated for you and sometimes updated i…

> You'd have to watch with a MutationObserver and then propagate the change to every instance of a custom element on the page. This solution works in that you can create a mixin that does this and use it in your custom elements. But if you profile it I think you'll discover it's painfully slow. It's not noticeable if you're using a few custom elements here and there, but if you're, for example, making a table of cust…

Yeah, that's exactly my experience. I built a framework for quickly prototyping with web components before I discovered the CSS-isolation defect. Sadly it's pretty much killed that idea as unworkable.

https://codepen.io/webstrand/pen/jOzYVpL> is as far as I got. The FOUS is pretty annoying, too, before the templates get properly registered. But I could live with that.

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

#165

Post by kerkeslager »

s17n wrote: post #138
kerkeslager wrote: post #113

Earlier quoted context omitted.

> The shadow DOM can inherit styles if you specify the styles that you want to inherit. Ah yes, I've heard about this "mixing CSS into your HTML". The entire point of CSS is that you can write selectors that can affect anything, import it in the header, and you're done. If you're telling me I have to import a new CSS file (or repeat myself and import the same CSS file) inside of every custom element I create, obvious…

> I'm telling you that's a terrible, awful idea, because it breaks the fundamental way CSS is supposed to work. The "way CSS is supposed to work" was always a bad idea and is totally unworkable for large projects / teams. Throwing it out and simply inlining all your styles is absolutely the right call.

Eh, there's some validity to that, but the worst of both worlds is to have both a CSS file and then a bunch of inline styles, which is what people here are proposing.

Inline styles make a lot of sense if you're using webcomponents pervasively, but there's a high up-front cost to doing that because you'll have to either a) define web components for everything you might want to style, including existing elements like

, or b) repeat yourself a lot.

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

#167

Post by thayne »

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…

My question is why don't more frameworks use it, especially the more popular ones.

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

#168

Post by WorldMaker »

btreecat wrote: post #18
nektro wrote: post #11

good article except for the firefox shade

I thought so too, and tried to dig into the specifics. I ended up here: https://hacks.mozilla.org/2014/12/mozilla-and-web-components... And left very unsatisfied that this is the current answer, only because I'd like to better understand how the use of JS modules over time has played out wrt html imports.

Things like HTML (and JSON) imports in ES modules, among other things, have been waiting on some safety signalling mechanics currently named "Import Attributes". Import Attributes are currently in Stage 3 [0].

The basic security story is that browsers never care about file extensions, they care about MIME types. A developer might add an import to a third-party HTML or JSON file somewhere and expect one "safe" behavior, but the third-party could just return a MIME type of "text/javascript" and inject an entire script and the browser is supposed to respect that MIME type.

To keep things safe, browsers want a way to signal that an import is supposed to JSON (or HTML or CSS) rather than JS and error if it gets back something "wrong" from a server request. That's one of the proposed uses for Import Attributes to suggest expected MIME types for non-JS modules in ES module imports.

Unfortunately, there are other proposed uses for Import Attributes (things like including hashes for integrity checks) and so there have been quite a few revisions (and multiple names) for Import Attributes trying to best support as many of the proposed uses as possible, and that has slowed progress on it a lot more than some people would wish.

[0] https://github.com/tc39/proposal-import-attributes

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

#169

Post by kerkeslager »

LorenzA wrote: post #143
kerkeslager wrote: post #121

Earlier quoted context omitted.

No, because then the user of the custom element has to put slot attributes on the things they put in the tabs. Consider this: ...arbitrary HTML that should work intuitively, i.e. be styled like the rest of the document. Note the lack of slot attributes on these tab elements. That's because we want this to behave like normal HTML where you can nest without having to worry about how tab-area was implemented. Why should…

Most of the time you have the tab and the panel to display the content of the tab a super simple demo implementation of something like this https://web.dev/components-howto-tabs/ In regards of slots, they are a nice way to allow a user of you webcomponent to overwrite/replace parts of your component with something else. This is most of the time a more advanced feature and I find it quite nice to build headless compon…

> Most of the time you have the tab and the panel to display the content of the tab a super simple demo implementation of something like this https://web.dev/components-howto-tabs/

That's exactly what I'm saying is bad. Why does the user of the howto-tabs have to type "slot='panel'" when that information is already communicated by the fact that it's a "howto-panel" inside a "howto-tabs"? This is a useless leaking of implementation details.

And that page just keeps going and going. Sure, some of that is because they're implementing a few neat features, but most of it is because slots are way overcomplicated for something that's actually easier to do without them.

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

#170

Post by beanjuiceII »

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 looks like someone's trying to make a GUI in java, what is the need/deal with these annotations etc?
Post reply on HN