The main limitation of web components for me is that all data needs to be passed to the component attributes as strings. Wish we could pass objects and arrays without JSON.stringify-ing them.
If Web Components are so great, why am I not using them?
111–120 of 189 posts
Re: If Web Components are so great, why am I not using them?
#112Frankly, web components aren't great. I am using them, because I've landed in a few projects where adding a JS build step is too heavyweight for very minimal JS needs. But here are my gripes: 1. Templates are way too complicated to be useful. I have no idea what they were thinking here. 2. The shadow DOM not inheriting styles means I effectively can't use the shadow DOM for anything useful. My ideal use case would be…
it sounds like the thing you are looking for are slots and they are supported in shadow DOM with the HTMLSlotElement
Re: If Web Components are so great, why am I not using them?
#113Frankly, web components aren't great. I am using them, because I've landed in a few projects where adding a JS build step is too heavyweight for very minimal JS needs. But here are my gripes: 1. Templates are way too complicated to be useful. I have no idea what they were thinking here. 2. The shadow DOM not inheriting styles means I effectively can't use the shadow DOM for anything useful. My ideal use case would be…
The shadow DOM can inherit styles if you specify the styles that you want to inherit. Additionally, web components work just fine without the shadow DOM, it's optional, but for a great many custom elements you don't want them inheriting all the styles, because that can break the custom element.
> 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, obviously I thought of that. I'm telling you that's a terrible, awful idea, because it breaks the fundamental way CSS is supposed to work.
Consider: if I'm distributing a library of web components, which of my users' CSS files that I know nothing about do I include? Did you read the example I already gave? The solution you're offering doesn't solve the problem I've described.
> Additionally, web components work just fine without the shadow DOM, it's optional,
You should read the post you're responding to in order to find out why that also causes problems.
> but for a great many custom elements you don't want them inheriting all the styles, because that can break the custom element.
...just like all of the rest of CSS. We have strategies for dealing with that. The only strategy you've suggested for doing the opposite is a completely useless non-solution.
Re: If Web Components are so great, why am I not using them?
#114Earlier quoted context omitted.
The shadow DOM can inherit styles if you specify the styles that you want to inherit. Additionally, web components work just fine without the shadow DOM, it's optional, but for a great many custom elements you don't want them inheriting all the styles, because that can break the custom element.
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 custom elements, the page will load slowly.
Re: If Web Components are so great, why am I not using them?
#115I heard about web components a lot for years and was looking forward for an opportunity to try them. But for some reason, this is the first time I learn that it's completely reliant on JS.
My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way. Instead, turns out it's doubling down on JS to create elements, and was actually targeted towards these framework in the first place.
Re: If Web Components are so great, why am I not using them?
#116[dead]
Re: If Web Components are so great, why am I not using them?
#117Because React is good enough. I think that's mostly why. Here's legacy React's like_button.js, without JSX, from their old documentation: 'use strict'; const e = React.createElement; class LikeButton extends React.Component { constructor(props) { super(props); this.state = { liked: false }; } render() { if (this.state.liked) { return 'You liked this.'; } return e( 'button', { onClick: () => this.setState({ liked: tru…
The latter doesn’t have any dependencies or a build step though right? That’s a big win that can be easily overlooked. But it depends what you’re optimising for…
I use web components in a small project where I don't want a build step (it's plain HTML and I just use web components for re-usability instead of copy+pasting mark-up).
Re: If Web Components are so great, why am I not using them?
#118Earlier quoted context omitted.
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 the…
The shadow DOM doesn't help at all here, that's mainly about scope and isolation. The (in fairness confusingly named) virtual DOM helps by splitting up writes and reads.
The goal when updating the DOM is to do all the reads in one batch, followed by all the writes in a second batch, so that they never interleave, and so that the browser can be as asynchronous as possible. A virtual DOM is just one way of batching those writes together.
It works in two phases: first, you work through the component tree, and freely read anything you want from the DOM, but rather than make any updates, you instead build a new data structure (the VDOM), which is just an internal representation of what you want the DOM to look like at some point in the future. Then, you reconcile this VDOM structure with the real DOM by looking to see which attributes need to be updated and updating them. By doing this in two phases, you ensure that all the reads happen before all the writes.
There are other ways of doing this. SolidJS, for example, just applies all DOM mutations asynchronously (or at least, partially asynchronously, I think using microtasks), which avoids the need for a virtual DOM. I assume Svelte has some similar setup, but I'm less familiar with that framework. That's not to say that virtual DOM implementations aren't still useful, just that they are one solution with a specific set of tradeoffs - other solutions to layout thrashing exist. (And VDOMs have other benefits being just avoiding layout thrashing.)
So to answer your question: the virtual DOM helps because it separates reads and writes from each other. Reads happen on the real DOM, writes happen on the virtual DOM, and it's only at the end of a given tick that the virtual DOM is reconciled with the real DOM, and the real DOM is updated.
Re: If Web Components are so great, why am I not using them?
#119The 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…
You could use `jsx` / `tsx`. Maybe it's worth for you to look at
https://github.com/cyco/WebFun/
Example for a `tsx` component:
https://github.com/cyco/WebFun/blob/master/src/ui/components...
Pure TypeScript / scss components.
Re: If Web Components are so great, why am I not using them?
#120I'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.
Would love to peruse a couple example repos for learning if you can share some public links.
Not parent, but I wrote some components based on lit-js, they're here: https://git.sr.ht/~mariusor/oni/tree/master/item/src/js. The top level call would be oni-main-actor.render()
However I am a total noob so it might not be entirely idiomatic. An example for the end result is at https://releases.bruta.link