5 ms·

The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the i

by zelly 4y ago

The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like <my-component my-attribute="[1,2,3]"/>). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't scale. W3C standardized Web Components before React existed and took off, unfortunately. I expect the next standard to just be React itself (or a barebones version that the library can build on top of), patent licenses permitting. I'm pretty sure as a C++ precompile, it would be unstoppable and end the debate for good.

semiquaver 4y ago
Every real world use of Web Components that I’ve seen uses <template> elements and/or imperative DOM methods to implement rerendering. These are blazing fast and exactly what React uses. It’s possible to build a slow app using Web Components, but that’s true of every library, including React.
- Izkata 4y ago
  Same here; I suspect they've mixed up defining the component (where some examples do use innerHTML) and using the component (which don't).
brundolf 4y ago
> Web Components is it's slower than React or other vDOM implementations > To re-render, you have to manipulate the innerHTML--usually replacing the string every update "Usually" is relative, I guess, but nothing's stopping you from using the imperative DOM APIs to update the component's contents; I daresay this would be the typical thing to do. These APIs will be just as performant as anything else out there. What you're really giving up, then, is the reactive programming model. Web Components are just a way of modularizing things; they have nothing to say about how you update the DOM (for better and worse). You are right (I think) that there's no good way around converting attributes to and from strings, though the performance overhead there should be minuscule in most cases. The bigger problems with that are a) some data (like functions) can't be serialized at all, and b) it leaves a lot of room for passing invalid values
- zelly 4y ago
  If you're using a framework like lit-html as the author recommends, it will replace the string every update. Most people will prefer that way since it's more ergonomic and similar to React. You could do imperative DOM updates, but that'd be like going back in time to jQuery.
  - brundolf 4y ago
    Right, all I'm saying is this is nothing intrinsic to the Web Components standard like the parent comment suggested. It's just one particular way you might use them.
  - claviska 4y ago
    This is false. It does not replace the entire string, but uses a template literal to identify which changes need to be made before selectively updating the DOM. This video is a few years old, but the core concepts remain the same. https://m.youtube.com/watch?v=Io6JjgckHbg https://m.youtube.com/watch?v=Io6JjgckHbg
    - robertlagrant 4y ago
      Wow, that's a pretty compelling video. I guess they all are, but I like the use of modern web standards.
  - jaredcwhite 4y ago
    This simply isn't true. Tagged template literals are not string concatenation. Also any "thin layer" of tooling on top of vanilla web components (like Lit) is entirely capable of passing complex objects as props. String-only "props" are only the case for literal HTML attributes in your source HTML—and even then you can embed JSON in an attribute and get a real parsed object within the component.
    - dmitriid 4y ago
      > Tagged template literals are not string concatenation They are not concatenation by themselves. But for them to be useful, you will end up doing a lot of it because there's nothing else to do with strings than parse (often with regexps [1]) and concatenate [2] the strings. And then you dump the concatenated string into the DOM using `.innerHtml` [3] There's no magic. [1] https://github.com/lit/lit/blob/main/packages/lit-html/src/lit-html.ts#L384 https://github.com/lit/lit/blob/main/packages/lit-html/src/l... [2] https://github.com/lit/lit/blob/main/packages/lit-html/src/lit-html.ts#L877 https://github.com/lit/lit/blob/main/packages/lit-html/src/l... and https://github.com/lit/lit/blob/main/packages/lit-html/src/lit-html.ts#L893 https://github.com/lit/lit/blob/main/packages/lit-html/src/l... and so on. [3] https://github.com/lit/lit/blob/main/packages/lit-html/src/lit-html.ts#L1095 https://github.com/lit/lit/blob/main/packages/lit-html/src/l...
sibit 4y ago
> To pass a prop to a component in a modular way, you have to pass a string attribute Is this actually how people pass props with Web Components? I've only used web components for a few years but I've always created a new instance of the class and I pass props using the constructor like: `${new ExampleComponent(props)}` Then in the constructor it's just this.state = {...this.state, ...props}
mhoad 4y ago
I’m not sure what you’re referring to here honestly but React is substantially behind web components in terms of every performance metric I can think of. Boot up, runtime, micro benchmarks and at scale.

by zelly 4y ago

semiquaver 4y ago

Every real world use of Web Components that I’ve seen uses <template> elements and/or imperative DOM methods to implement rerendering. These are blazing fast and exactly what React uses. It’s possible to build a slow app using Web Components, but that’s true of every library, including React.

Izkata 4y ago
Same here; I suspect they've mixed up defining the component (where some examples do use innerHTML) and using the component (which don't).

brundolf 4y ago

> Web Components is it's slower than React or other vDOM implementations > To re-render, you have to manipulate the innerHTML--usually replacing the string every update "Usually" is relative, I guess, but nothing's stopping you from using the imperative DOM APIs to update the component's contents; I daresay this would be the typical thing to do. These APIs will be just as performant as anything else out there. What you're really giving up, then, is the reactive programming model. Web Components are just a way of modularizing things; they have nothing to say about how you update the DOM (for better and worse). You are right (I think) that there's no good way around converting attributes to and from strings, though the performance overhead there should be minuscule in most cases. The bigger problems with that are a) some data (like functions) can't be serialized at all, and b) it leaves a lot of room for passing invalid values

zelly 4y ago
If you're using a framework like lit-html as the author recommends, it will replace the string every update. Most people will prefer that way since it's more ergonomic and similar to React. You could do imperative DOM updates, but that'd be like going back in time to jQuery.
- brundolf 4y ago
  Right, all I'm saying is this is nothing intrinsic to the Web Components standard like the parent comment suggested. It's just one particular way you might use them.
- claviska 4y ago
  This is false. It does not replace the entire string, but uses a template literal to identify which changes need to be made before selectively updating the DOM. This video is a few years old, but the core concepts remain the same. https://m.youtube.com/watch?v=Io6JjgckHbg https://m.youtube.com/watch?v=Io6JjgckHbg
  - robertlagrant 4y ago
    Wow, that's a pretty compelling video. I guess they all are, but I like the use of modern web standards.
- jaredcwhite 4y ago
  This simply isn't true. Tagged template literals are not string concatenation. Also any "thin layer" of tooling on top of vanilla web components (like Lit) is entirely capable of passing complex objects as props. String-only "props" are only the case for literal HTML attributes in your source HTML—and even then you can embed JSON in an attribute and get a real parsed object within the component.
  - dmitriid 4y ago
    > Tagged template literals are not string concatenation They are not concatenation by themselves. But for them to be useful, you will end up doing a lot of it because there's nothing else to do with strings than parse (often with regexps [1]) and concatenate [2] the strings. And then you dump the concatenated string into the DOM using `.innerHtml` [3] There's no magic. [1] https://github.com/lit/lit/blob/main/packages/lit-html/src/lit-html.ts#L384 https://github.com/lit/lit/blob/main/packages/lit-html/src/l... [2] https://github.com/lit/lit/blob/main/packages/lit-html/src/lit-html.ts#L877 https://github.com/lit/lit/blob/main/packages/lit-html/src/l... and https://github.com/lit/lit/blob/main/packages/lit-html/src/lit-html.ts#L893 https://github.com/lit/lit/blob/main/packages/lit-html/src/l... and so on. [3] https://github.com/lit/lit/blob/main/packages/lit-html/src/lit-html.ts#L1095 https://github.com/lit/lit/blob/main/packages/lit-html/src/l...

sibit 4y ago

> To pass a prop to a component in a modular way, you have to pass a string attribute Is this actually how people pass props with Web Components? I've only used web components for a few years but I've always created a new instance of the class and I pass props using the constructor like: `${new ExampleComponent(props)}` Then in the constructor it's just this.state = {...this.state, ...props}

mhoad 4y ago

I’m not sure what you’re referring to here honestly but React is substantially behind web components in terms of every performance metric I can think of. Boot up, runtime, micro benchmarks and at scale.