7 ms·

At first I was gung ho about web components. I was so excited I used Mozilla's X-Tag for one project and Polymer in another project. I am now no longer in favor

At first I was gung ho about web components. I was so excited I used Mozilla's X-Tag for one project and Polymer in another project. I am now no longer in favor of using them and it makes me sad, actually. Web components are simply too heavy. They add latency to download (yeah you can combine them but I've never found tooling (including Vulcanize) that worked very well). Also the shadow dom's separation makes styling more difficult across multiple components requiring awkward shadow dom hacks in the CSS and / or duplicating / adding more CSS to components themselves. Same with using JavaScript and third party libraries not expecting to use the ShadowDom though this isn't so bad. When I'm working on something that needs to be optimized for low bandwidth / high latency I go as lightweight as possible and I concat as much stuff together as I can. I want web components to work so badly but they're way too slow for me to use anytime soon.

mbrock 11y ago
"Too heavy" seems like it should be qualified—maybe you mean they are "too heavy to use for widget-level components in a web app with the current implementations"? That's a weaker claim, and leads to the question of what they might be good for right now. I imagine for example Stripe's payment widget could be a pretty nice use case? In other words, higher-level widgets that are substantially encapsulated already, and are already often loaded as remote resources. But I've only looked a little at the W3 specs and haven't tried using them in reality.
- BinaryIdiot 11y ago
  > "Too heavy" seems like it should be qualified—maybe you mean they are "too heavy to use for widget-level components in a web app with the current implementations"? Current implementations yes but when browsers have 100% integration? I want to say yes but would love to say no. My biggest issues (latency, trying to concat and minify down and duplicative CSS) are not really addressed anywhere but until all browsers have the full implementation I can't say for sure I'll admit. > I imagine for example Stripe's payment widget could be a pretty nice use case? In other words, higher-level widgets that are substantially encapsulated already, and are already often loaded as remote resources. That seems like a great use case. I'd prefer, and probably most others, to host my own components versus externally referencing them but in some cases where you can't really get around it (I'm not familiar with Stripe's payment widget but Google Maps is certainly like this) I could see that being a good use case. Honestly that in and of itself may justify its existence but I'm just not convinced of its use fullness outside of that just yet.
  - solidr53 11y ago
    Polymer dude here. Some points: - What's wrong with vulcanize (combines all your components into one single html file)? - Polymer now offers Shared styles, so that you don't have to duplicate your css. And you can use BEM or what ever you like. - Get ready for HTTP2 in a few years.
    - BinaryIdiot 11y ago
      > What's wrong with vulcanize (combines all your components into one single html file)? Most of the issues I ran into were relating to inconsistent pathing. It was difficult to get every type of thing that could use a path (image tags, css, html inclusions, etc) working in a way that worked at both the path of the component and the newly created path when combined. Perhaps this has changed since the last I used Vulcanize but it was very painful at the time. I also had a hell of a time getting the google maps, and a few other google components, to Vulcanize with the rest of my components but I honestly can't remember the issues now. > Polymer now offers Shared styles, so that you don't have to duplicate your css That's Polymer specific though; is there a way to do that with native web components? I could be missing something but it looks specific to Polymer. Regardless I'm glad this is being addressed to a degree but the solution seemed somewhat unintuitive as it's not using CSS semantics for driving the style. Essentially the majority of projects I work on have developers and designers on them. The designers are usually pretty good with CSS, Illustrator and Photoshop so anything outside of CSS requires quite a bit of learning for them so that's a hill I have to battle with techniques such as these. > Get ready for HTTP2 in a few years. Just like I'm not going to be able to use ES6 for many years I'm not holding my breath here :)
ehsanu1 11y ago
http2 may help you with that. Your tooling could also potentially inline the components too, you don't have to make an http request for each one. That fact that Vulcanize didn't work too well for you for whatever reason seems like something that shouldn't be terribly difficult to fix.
- BinaryIdiot 11y ago
  > That fact that Vulcanize didn't work too well for you for whatever reason seems like something that shouldn't be terribly difficult to fix. Maybe? I'm not sure. The vast majority of issues I had with Vulcanize stemmed from pathing changes. So say you're working on a component that exists at /components/mycomponent/mycomponent.html When you're referencing JavaScript, images, CSS, etc you typically assume you're at / but it doesn't work like that for everything. So you either have to setup a configurations so you have a universal prefix to use for everything or do everything relative to root (which at least in the environments I deployed into not really doable as the root could change). So the vulcanizer needs to understand and reroute everything within your component and since there is no way to override the way the browser fetches content you're left with trying to figure out everything to include and doing it via ajax (if you wanted to be automated about it). I'm not saying it's impossible but it seems difficult to do to the point where I don't know that that's the best path for web development to go down. I honestly can't remember some of the other issues I've run into. Mostly JavaScript errors from third party components and even other Polymer components but it's been about 6 months or so since I've used it. I'm sure Vulcanize has gotten better by now and I know Polymer has.
  - Touche 11y ago
    HTML Imports are going away. I'm not sure the state of Polymer but my guess is that they will be removed eventually, so I wouldn't depend on a tool like Vulcanize being improved; it's a dead feature. Instead use a normal JavaScript module loader to load components and concat them the usual way. Don't use imports.
    - spankalee 11y ago
mozumder 11y ago
The other terrible side effect of web components is that it gives the standards group an excuse to never update HTML anymore. "Why do we need HTML6 when you can make anything you want with big, heavy Javascript-based web component that takes expert programmers to make?" Indeed. Just say no to web components. Say yes to upgrading HTML specs directly.
- nostrademons 11y ago
  That's the exact opposite of the reason why browser vendors are implementing web components. It's so that they can get direct, real-world feedback from actual users of a feature before baking it into standards and making it impossible to remove from the web. The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec. We used to write web specs speculatively, without having feedback from real-world use, and it was a disaster. Take a look at the list of W3C standards: https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Standards https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Stan... How many of them do you actually use? Remember when everything was XML, XPATH, XSLT, the semantic web, and we were going to replace HTML with XHTML?
  - mozumder 11y ago
    The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec. That's nice in theory, but what's happening in reality is that no component is going to be standardized, and HTML remains stagnant for another 15 years.
    - nostrademons 11y ago
      It's a little hard to make that argument when web components themselves aren't standardized yet, and are fully supported natively in only one of the major browsers. There's pretty ample evidence that common webdeveloper behavior does make it into the spec, eg. JQuery => querySelectorAll, Javascript animations => CSS transitions & animations, long-polling => websockets, common layouts => <header>/<footer>/<main>/<nav> elements, dropdowns => <details>/<summary> elements, the addition of date/datetime/color/number/range/tel input types, etc. If you're still coding HTML like you did in 2000, you are now very obsolete.
TheOsiris 11y ago
isn't the lack of tooling primarily due to the fact that it is very early? I would expect all of that to improve in the future
spankalee 11y ago
Web Components are defined in script, they add no more download costs than any other script or styles. Shadow DOM's style scoping is very intentional, and brings sanity to styling. Cross-scope styling is possible via CSS custom properties in a much more principled way than letting styles leak all over the entire document.
- wwweston 11y ago
  "letting styles leak all over the entire document" CSS selectors allow for a pretty wide breadth of targets -- they can be as narrowly specific or as broadly general ("leaky") as the author likes. What's the exact problem that another layer/mechanism of scoping solves that being thoughtful about your selectors doesn't?
  - cdata 11y ago
    ShadowDOM removes the need for a component user and a component author to collaborate in order for styles to be encapsulated. This, in turn, enables easier distribution and usage of generalized components.
    - pixie_ 11y ago
      Exactly, how many times do you want to use a component but find it near impossible because it's written with a framework, or uses CSS styles that conflict with your own, or is written for use with a different version of the very framework you're using... this is why we keep re-inventing the same dumb web components over and over again.
  - spankalee 11y ago
    It's basically impossible to implement lower bounds for descendent selectors without scoping. You can kind of fake it with build steps and some luck, but it will always have holes and problems with dynamically updated DOM. Faking lower bounds also keeps the browser from knowing that it doesn't have to invalidate the isolated scopes when properties above them changes.
  - 11y ago
everlost 11y ago
I had the exact same thoughts when I first read about web components, or rather HTML imports in particular. The extra requests and latency introduced are not worth the benefits of having pluggable components. I can already imagine people writing server side code to include these "web components" inline into the static markup sent to browser, which somewhat defeats the purpose of having these components be dynamically interpreted by the browser. Or maybe the correct way of using web components would be to create component "rollups" on server side, to reduce the latency effect of the extra requests. Or the browser might start caching common components between page requests. Maybe the current web component spec is just the first step to get the reusable web started...
- nostrademons 11y ago
  HTTP2. In the HTTP2 world, extra requests don't add any additional latency. The browser multiplexes them over a single connection. I think I'd heard that it even uses a common compression dictionary for all requests, which means that boilerplate code that's duplicated between components will get compressed away.
  - lenish 11y ago
    >In the HTTP2 world, extra requests don't add any additional latency. They don't add any additional TCP connection latency, sure. I think it's a bit unrealistic to claim there won't be any congestion of the multiplexed stream which causes additional latency. >I think I'd heard that it even uses a common compression dictionary for all requests, which means that boilerplate code that's duplicated between components will get compressed away. I may be misremembering, but I thought that was just for request headers?
    - alwillis 11y ago
      >I may be misremembering, but I thought that was just for request headers? That's correct: https://http2.github.io/http2-spec/compression.html https://http2.github.io/http2-spec/compression.html.
  - 11y ago
rictic 11y ago
Please file vulcanize bugs or give feedback here on what didn't work for you. Every componentization system will require concatting to get good performance on today's web (http2 push is close but quite here yet).

mbrock 11y ago

"Too heavy" seems like it should be qualified—maybe you mean they are "too heavy to use for widget-level components in a web app with the current implementations"? That's a weaker claim, and leads to the question of what they might be good for right now. I imagine for example Stripe's payment widget could be a pretty nice use case? In other words, higher-level widgets that are substantially encapsulated already, and are already often loaded as remote resources. But I've only looked a little at the W3 specs and haven't tried using them in reality.

BinaryIdiot 11y ago
> "Too heavy" seems like it should be qualified—maybe you mean they are "too heavy to use for widget-level components in a web app with the current implementations"? Current implementations yes but when browsers have 100% integration? I want to say yes but would love to say no. My biggest issues (latency, trying to concat and minify down and duplicative CSS) are not really addressed anywhere but until all browsers have the full implementation I can't say for sure I'll admit. > I imagine for example Stripe's payment widget could be a pretty nice use case? In other words, higher-level widgets that are substantially encapsulated already, and are already often loaded as remote resources. That seems like a great use case. I'd prefer, and probably most others, to host my own components versus externally referencing them but in some cases where you can't really get around it (I'm not familiar with Stripe's payment widget but Google Maps is certainly like this) I could see that being a good use case. Honestly that in and of itself may justify its existence but I'm just not convinced of its use fullness outside of that just yet.
- solidr53 11y ago
  Polymer dude here. Some points: - What's wrong with vulcanize (combines all your components into one single html file)? - Polymer now offers Shared styles, so that you don't have to duplicate your css. And you can use BEM or what ever you like. - Get ready for HTTP2 in a few years.
  - BinaryIdiot 11y ago
    > What's wrong with vulcanize (combines all your components into one single html file)? Most of the issues I ran into were relating to inconsistent pathing. It was difficult to get every type of thing that could use a path (image tags, css, html inclusions, etc) working in a way that worked at both the path of the component and the newly created path when combined. Perhaps this has changed since the last I used Vulcanize but it was very painful at the time. I also had a hell of a time getting the google maps, and a few other google components, to Vulcanize with the rest of my components but I honestly can't remember the issues now. > Polymer now offers Shared styles, so that you don't have to duplicate your css That's Polymer specific though; is there a way to do that with native web components? I could be missing something but it looks specific to Polymer. Regardless I'm glad this is being addressed to a degree but the solution seemed somewhat unintuitive as it's not using CSS semantics for driving the style. Essentially the majority of projects I work on have developers and designers on them. The designers are usually pretty good with CSS, Illustrator and Photoshop so anything outside of CSS requires quite a bit of learning for them so that's a hill I have to battle with techniques such as these. > Get ready for HTTP2 in a few years. Just like I'm not going to be able to use ES6 for many years I'm not holding my breath here :)

ehsanu1 11y ago

http2 may help you with that. Your tooling could also potentially inline the components too, you don't have to make an http request for each one. That fact that Vulcanize didn't work too well for you for whatever reason seems like something that shouldn't be terribly difficult to fix.

BinaryIdiot 11y ago
> That fact that Vulcanize didn't work too well for you for whatever reason seems like something that shouldn't be terribly difficult to fix. Maybe? I'm not sure. The vast majority of issues I had with Vulcanize stemmed from pathing changes. So say you're working on a component that exists at /components/mycomponent/mycomponent.html When you're referencing JavaScript, images, CSS, etc you typically assume you're at / but it doesn't work like that for everything. So you either have to setup a configurations so you have a universal prefix to use for everything or do everything relative to root (which at least in the environments I deployed into not really doable as the root could change). So the vulcanizer needs to understand and reroute everything within your component and since there is no way to override the way the browser fetches content you're left with trying to figure out everything to include and doing it via ajax (if you wanted to be automated about it). I'm not saying it's impossible but it seems difficult to do to the point where I don't know that that's the best path for web development to go down. I honestly can't remember some of the other issues I've run into. Mostly JavaScript errors from third party components and even other Polymer components but it's been about 6 months or so since I've used it. I'm sure Vulcanize has gotten better by now and I know Polymer has.
- Touche 11y ago
  HTML Imports are going away. I'm not sure the state of Polymer but my guess is that they will be removed eventually, so I wouldn't depend on a tool like Vulcanize being improved; it's a dead feature. Instead use a normal JavaScript module loader to load components and concat them the usual way. Don't use imports.
  - spankalee 11y ago

mozumder 11y ago

The other terrible side effect of web components is that it gives the standards group an excuse to never update HTML anymore. "Why do we need HTML6 when you can make anything you want with big, heavy Javascript-based web component that takes expert programmers to make?" Indeed. Just say no to web components. Say yes to upgrading HTML specs directly.

nostrademons 11y ago
That's the exact opposite of the reason why browser vendors are implementing web components. It's so that they can get direct, real-world feedback from actual users of a feature before baking it into standards and making it impossible to remove from the web. The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec. We used to write web specs speculatively, without having feedback from real-world use, and it was a disaster. Take a look at the list of W3C standards: https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Standards https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Stan... How many of them do you actually use? Remember when everything was XML, XPATH, XSLT, the semantic web, and we were going to replace HTML with XHTML?
- mozumder 11y ago
  The intent has always been that the most frequently used webcomponents will end up getting baked into the browser, and then into the HTML spec. That's nice in theory, but what's happening in reality is that no component is going to be standardized, and HTML remains stagnant for another 15 years.
  - nostrademons 11y ago
    It's a little hard to make that argument when web components themselves aren't standardized yet, and are fully supported natively in only one of the major browsers. There's pretty ample evidence that common webdeveloper behavior does make it into the spec, eg. JQuery => querySelectorAll, Javascript animations => CSS transitions & animations, long-polling => websockets, common layouts => <header>/<footer>/<main>/<nav> elements, dropdowns => <details>/<summary> elements, the addition of date/datetime/color/number/range/tel input types, etc. If you're still coding HTML like you did in 2000, you are now very obsolete.

TheOsiris 11y ago

isn't the lack of tooling primarily due to the fact that it is very early? I would expect all of that to improve in the future

spankalee 11y ago

Web Components are defined in script, they add no more download costs than any other script or styles. Shadow DOM's style scoping is very intentional, and brings sanity to styling. Cross-scope styling is possible via CSS custom properties in a much more principled way than letting styles leak all over the entire document.

wwweston 11y ago
"letting styles leak all over the entire document" CSS selectors allow for a pretty wide breadth of targets -- they can be as narrowly specific or as broadly general ("leaky") as the author likes. What's the exact problem that another layer/mechanism of scoping solves that being thoughtful about your selectors doesn't?
- cdata 11y ago
  ShadowDOM removes the need for a component user and a component author to collaborate in order for styles to be encapsulated. This, in turn, enables easier distribution and usage of generalized components.
  - pixie_ 11y ago
    Exactly, how many times do you want to use a component but find it near impossible because it's written with a framework, or uses CSS styles that conflict with your own, or is written for use with a different version of the very framework you're using... this is why we keep re-inventing the same dumb web components over and over again.
- spankalee 11y ago
  It's basically impossible to implement lower bounds for descendent selectors without scoping. You can kind of fake it with build steps and some luck, but it will always have holes and problems with dynamically updated DOM. Faking lower bounds also keeps the browser from knowing that it doesn't have to invalidate the isolated scopes when properties above them changes.
- 11y ago

everlost 11y ago

I had the exact same thoughts when I first read about web components, or rather HTML imports in particular. The extra requests and latency introduced are not worth the benefits of having pluggable components. I can already imagine people writing server side code to include these "web components" inline into the static markup sent to browser, which somewhat defeats the purpose of having these components be dynamically interpreted by the browser. Or maybe the correct way of using web components would be to create component "rollups" on server side, to reduce the latency effect of the extra requests. Or the browser might start caching common components between page requests. Maybe the current web component spec is just the first step to get the reusable web started...

nostrademons 11y ago
HTTP2. In the HTTP2 world, extra requests don't add any additional latency. The browser multiplexes them over a single connection. I think I'd heard that it even uses a common compression dictionary for all requests, which means that boilerplate code that's duplicated between components will get compressed away.
- lenish 11y ago
  >In the HTTP2 world, extra requests don't add any additional latency. They don't add any additional TCP connection latency, sure. I think it's a bit unrealistic to claim there won't be any congestion of the multiplexed stream which causes additional latency. >I think I'd heard that it even uses a common compression dictionary for all requests, which means that boilerplate code that's duplicated between components will get compressed away. I may be misremembering, but I thought that was just for request headers?
  - alwillis 11y ago
    >I may be misremembering, but I thought that was just for request headers? That's correct: https://http2.github.io/http2-spec/compression.html https://http2.github.io/http2-spec/compression.html.
- 11y ago

rictic 11y ago

Please file vulcanize bugs or give feedback here on what didn't work for you. Every componentization system will require concatting to get good performance on today's web (http2 push is close but quite here yet).