6 ms·

> they can render before JavaScript. React components cannot do this — full stop Not a full stop; SSR means they could render before client-side JS. The examp

> they can render before JavaScript. React components cannot do this — full stop Not a full stop; SSR means they could render before client-side JS. The example is a bit too simple to make the author's point IMO. A web component that handles changes to state would be a better comparison, and make for a better argument.

algem 3y ago
How would an "Html Web Component" handle state change? I was a bit lost on the benefits given the example of wrapping an img tag. Sure you could group and reuse common elements but you would still need javascript to do anything interactive. Even in the example given the alt text of the image is typically dynamic now because of localization so even then content is missing with javascript.
- hyperhello 3y ago
  That’s what JavaScript is supposed to be for: state change. Not rendering the page.
goeiedaggoeie 3y ago
This is the main issue for me with webcomponents, they are not SSR friendly.
- kaba0 3y ago
  Do you want SSR for SEO, or for fast first interaction? Because if the latter, then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups.
  - nicoburns 3y ago
    > then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups. Arguably they might be less optimisable than regular web frameworks, as they make it difficult to coordinate between different components on the page.
  - goeiedaggoeie 3y ago
    This is a good point, but I would counter, perceived speed of rendering from a user perspective is more important than time to interact with the app/site (a reasonable time to interact is however very important. Good load order and only loading in the content and JS above the fold initially helps a ton. JS frameworks are huge and I am still saddened that proper tree shaking and optimization got left by the way side in how the modern web has evolved. I worked with google closure in advanced modes and the closure components for a few years and the compiler was absolutely astounding (and the components designed with the compiler in mind) in code splitting, tree shaking and minimization.
    - kaba0 3y ago
      Oh, google closure was absolutely ahead of its time!
- jmull 3y ago
  Consider the approach this article suggests. You want to have the tags and content appear in the web component (not rendered by JS) which makes it easily and immediately available to crawlers.
- toasted-subs 3y ago
  You can pre-generate them on the client though.
inglor 3y ago
Good point, and conversely, web components can't since they must be registered in JavaScript before the side loads. Hydration solutions exist but are usually worse and come with surprising tradeoffs and harm composabilitiy.

algem 3y ago

How would an "Html Web Component" handle state change? I was a bit lost on the benefits given the example of wrapping an img tag. Sure you could group and reuse common elements but you would still need javascript to do anything interactive. Even in the example given the alt text of the image is typically dynamic now because of localization so even then content is missing with javascript.

hyperhello 3y ago
That’s what JavaScript is supposed to be for: state change. Not rendering the page.

goeiedaggoeie 3y ago

This is the main issue for me with webcomponents, they are not SSR friendly.

kaba0 3y ago
Do you want SSR for SEO, or for fast first interaction? Because if the latter, then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups.
- nicoburns 3y ago
  > then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups. Arguably they might be less optimisable than regular web frameworks, as they make it difficult to coordinate between different components on the page.
- goeiedaggoeie 3y ago
  This is a good point, but I would counter, perceived speed of rendering from a user perspective is more important than time to interact with the app/site (a reasonable time to interact is however very important. Good load order and only loading in the content and JS above the fold initially helps a ton. JS frameworks are huge and I am still saddened that proper tree shaking and optimization got left by the way side in how the modern web has evolved. I worked with google closure in advanced modes and the closure components for a few years and the compiler was absolutely astounding (and the components designed with the compiler in mind) in code splitting, tree shaking and minimization.
  - kaba0 3y ago
    Oh, google closure was absolutely ahead of its time!
jmull 3y ago
Consider the approach this article suggests. You want to have the tags and content appear in the web component (not rendered by JS) which makes it easily and immediately available to crawlers.
toasted-subs 3y ago
You can pre-generate them on the client though.

inglor 3y ago

Good point, and conversely, web components can't since they must be registered in JavaScript before the side loads. Hydration solutions exist but are usually worse and come with surprising tradeoffs and harm composabilitiy.