3 ms·

"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 implementation

by 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 :)

by mbrock 11y ago

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 :)