5 ms·

> 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 eve

> 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 5y 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 5y 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 5y 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 5y ago
    Wow, that's a pretty compelling video. I guess they all are, but I like the use of modern web standards.
- jaredcwhite 5y 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 5y 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...
    - dtagames 5y ago
      I use Lit every day and I have no idea what you're talking about. Any property can be a full JS object. When the property is changed, it is re-rendered in your component. I have never touched innerHtml and my Lit apps pass and render all kinds of stuff into html`` tagged templates. It's really pure magic because you can freely mix regular old HTML and regular attributes with dynamic data and data binding. There's more than one way to write anything which gives you great flexibility. I adore tagged templates, and they work for CSS and SVG, too.
      - dmitriid 5y ago
        > I use Lit every day and I have no idea what you're talking about. I'm talking about how lit is implemented internally and that's why I provided links to relevant parts of lit's code. People having no idea how things work is the bane of our industry. And that's why we have objectively false statements like "regular old HTML and regular attributes with dynamic data and data binding". Lit is almost as far from "regular old HTML" as React's JSX is: lit is a HTML-like DSL that even has constraints on how you use tagged literals themselves. E.g. `<${tagName}></${tagName}>` is a valid tagged literal and it's invalid in lit.[1] > they work for CSS and SVG, too. If lit lets you mix SVG with custom elements, they don't really use custom elements. See discussion https://twitter.com/Rich_Harris/status/1198339672361119745?s=20&t=c3_4ndeU0WbdsWIC8OAAKw https://twitter.com/Rich_Harris/status/1198339672361119745?s... [1] https://lit.dev/docs/templates/expressions/#invalid-locations https://lit.dev/docs/templates/expressions/#invalid-location...
deleted 5y ago
[deleted]
megous 5y ago
You can use DOM node properties instead of attributes, when working with custom elements from JS. No seraialization/deserialization to/from string there.

zelly 5y 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 5y 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 5y 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 5y ago
  Wow, that's a pretty compelling video. I guess they all are, but I like the use of modern web standards.
jaredcwhite 5y 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 5y 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...
  - dtagames 5y ago
    I use Lit every day and I have no idea what you're talking about. Any property can be a full JS object. When the property is changed, it is re-rendered in your component. I have never touched innerHtml and my Lit apps pass and render all kinds of stuff into html`` tagged templates. It's really pure magic because you can freely mix regular old HTML and regular attributes with dynamic data and data binding. There's more than one way to write anything which gives you great flexibility. I adore tagged templates, and they work for CSS and SVG, too.
    - dmitriid 5y ago
      > I use Lit every day and I have no idea what you're talking about. I'm talking about how lit is implemented internally and that's why I provided links to relevant parts of lit's code. People having no idea how things work is the bane of our industry. And that's why we have objectively false statements like "regular old HTML and regular attributes with dynamic data and data binding". Lit is almost as far from "regular old HTML" as React's JSX is: lit is a HTML-like DSL that even has constraints on how you use tagged literals themselves. E.g. `<${tagName}></${tagName}>` is a valid tagged literal and it's invalid in lit.[1] > they work for CSS and SVG, too. If lit lets you mix SVG with custom elements, they don't really use custom elements. See discussion https://twitter.com/Rich_Harris/status/1198339672361119745?s=20&t=c3_4ndeU0WbdsWIC8OAAKw https://twitter.com/Rich_Harris/status/1198339672361119745?s... [1] https://lit.dev/docs/templates/expressions/#invalid-locations https://lit.dev/docs/templates/expressions/#invalid-location...

deleted 5y ago

[deleted]

megous 5y ago

You can use DOM node properties instead of attributes, when working with custom elements from JS. No seraialization/deserialization to/from string there.