19 ms·

The Power of Web Components

170 points by lainon 8y ago

option_greek 8y ago
It's weird that the default behavior when appending a template is to not clone it requiring an additional clone call >>template.content.cloneNode(true)
- lucideer 8y ago
  That's the default behaviour when appending a DocumentFragment or a Node, and has been since 1997. The template is just a container for the DocumentFragment, the template content still behaves like any other DocumentFragment always would have, so changing behaviour would be pretty crazy.
Flenser 8y ago
Web components may give power to developers but they take it away from users. Any page made with web components is hostile to user styling. I'm surprised Mozilla would support them.
- potch 8y ago
  Hello! Author here. I'm a fan of web components for widgets and embeddable third-party interfaces. I'm not as much a fan of them to wrap a site's primary content, for both accessibility and user styling reasons.
  - Flenser 8y ago
    Hi! I'm not a fan of them for web apps that use excessive whitespace between repeating components[1]. Previously you could just edit the global stylesheet in dev tools but now that only changes the current component. Edit: I get the widget / embedable use case but fear that it won't just be used for that. [1] e.g. Chrome's new material design bookmarks manager that shows far less bookmarks per page than the old design.
  - wilsmex 8y ago
    Great write up. Can a web component author create one in such a way that the inner shadow dom styles ARE editable/styleable by the outer or person implementing the custom component?
    - megous 8y ago
      Yeah, I have the similar need. I want to use <slot> mechanism, so I need shadow DOM, but I'd like to re-use styles, so that they don't need to be copied to each instance of the component. Aside from complicating things, it seems wasteful. It should be possible to use styles from the document's CSS to style the innards of a web component. I'm still learning, and I'm still missing solution to this. I know about var(--custom-prop), but that's limited, and still doesn't help with the waste of useless duplication of styles.
      - spirodonfl 8y ago
        What I've done is kinda standardized the solution. I've made all my elements listen for a template tag in the html page that contains <link> tags to the stylesheets I use globally. <template id="x-global-styles"> <link rel="stylesheet" href="some/sheet.css" /> </template> Kinda like that. You can use prefetch in the main header to get all your styles in one shot, before page load, if you want. Then I make my element, if the template is found, pump the innards of the template into itself so all my styles are available. I use it in conjuction with tailwind so I can write atomic classes and include my atomic css with every element I desire. From what I can tell, for the most part, my styles don't get reloaded every time. I could be wrong. They seem to get prefetched, if I use a prefetch, or loaded once, then cached. It seems that no matter how many elements I have on the page there are no external calls to get the stylesheet every time. One and done. Correct me if I'm wrong here. It's just something I fiddled around with.
        megous 8y ago
        Very interesting! Thank you. I didn't realize you can use <link> inside web component. But it makes sense! I read some more, and I reaized that it's probably meant to be that every component has its own small piece of CSS independent of the rest, so that you can use :host, and all the other trickery and so that least amount of CSS per component needs to be parsed and processed. So I ended up writing a small pre-processor, that converts sass files into a js file with a variables containing styles for each component (like BUTTON_CSS, DIALOG_CSS, SPLIT_LAYOUT_CSS). I just hope that there's some optimization in the browser, such that when the same <style> content is used in multiple instances of the component, it is parsed/processed only once and the results cached for the other instances.
- peterhunt 8y ago
  Weren’t user stylesheets removed from [1] / never present in most browsers? [1] https://src.chromium.org/viewvc/chrome?revision=234007&view=revision https://src.chromium.org/viewvc/chrome?revision=234007&view=...
  - Flenser 8y ago
    I use GreaseMonkey/TamperMonkey, but WebComponent even make modifying a page using dev tools hard. Edit: e.g for printing or to make reading / using easier.
  - srgpqt 8y ago
    They are still in Firefox, but hidden from the user.
    - lowercased 8y ago
      there seems to be something in mac safari for 'stylesheet' loading under 'advanced' preferences. if the browsers don't give people tools to edit/manage from within the browsers, even the average tech-savvy user won't bother with these, which is a bit of a shame.
- blacksmith_tb 8y ago
  It seems like the * CSS selector would still apply to these new elements? And in js things like el.children? I wonder if user styles via something like Stylus[1] could style them also? Now that I think about it, it seems like some of the worst (and most likely) applications will be advertising (to try and avoid blockers). 1: https://addons.mozilla.org/en-US/firefox/addon/styl-us/ https://addons.mozilla.org/en-US/firefox/addon/styl-us/
- ravenstine 8y ago
  How many users apply their own style sheets? I remember this was popular among a relatively few people, and now I don't know anyone who uses things like Stylish or Greasemonkey/Tampermonkey anymore.
  - wwweston 8y ago
    User applied stylesheets are fairly uncommon, but then again, so is using a screen reader. Both are essentially a kind of accessibility tech, and when it comes to accessibility questions, the chief concern isn't necessarily whether everyone uses it. It's probably worth noting that reader-mode -- another accessibility tech -- does seem to be fairly popular.
    - someone7x 8y ago
      > and when it comes to accessibility questions, the chief concern isn't necessarily whether everyone uses it. I wish more developers had your perspective. My Dad uses Windows' high contrast mode. It's less that "literal dozens" use this feature and more that this feature transforms all that desktop-shaped-material into a computer for the vision impaired. Isn't the biggest performance enhancement the transition from not-working to working? I view accessibility as the ultimate performance enhancement for a given slice of users.
      - TeMPOraL 8y ago
        Some companies care. Most don't. Unless a feature is used by double-digit percentage of users, it'll be axed. It's a sad reality of today, and no, I don't buy the arguments about saving development time, not when said by the same people who also say they want to deliver value to users (as opposed to extract value from them). Because somehow, feature cancellation always seems to touch the features that enable users to unbreak things or optimize their experience.
        zeroname 8y ago
        Delivering value to only 0.1% of users is equal to taking away value from the other 99.9% of users. You're not strictly saving development time, you're reallocating it to better utility. Now, if those 0.1% of users have some sort of legitimate accessibility issue, we can talk about it. If they just have highly idiosyncratic preferences about their user experience, the axe it shall be.
- megous 8y ago
  OTOH for me (another freakish web user who does unusual things with the web), web components may make it easier to scrape the website. Developers will be passing data into a component in some way, JSON atrtribute, or a nicely defined data in a property, so it will be easier to scrape and understand via devtools DOM insepctor. Insteaed of a soup of deeply nested divs, there will be nicer and more meaningful structure of web components.
  - jazzyjackson 8y ago
    The move to single page apps have definitely surfaced a lot of JSON-speaking api endpoints that make scraping for data a thing of the past. A great thing for the web, I think, whether or not the site owners are aware!
- megous 8y ago
  You can still probably override attachShadow to ignore the argument, and make shadowRoot always open and then use that to modify the <style> inside shadowRoot. More complicated, but probably doable (with greasemonkey).
- rictic 8y ago
  The last time I looked into it, user agents may support the '>>>' combinator for cases like user styling, where the user should trump the page content.
- simplify 8y ago
  If web components will be built-in, I imagine it's possible for browsers to provide a way to style them in user-land.
ravenstine 8y ago
I really hope that web components take off, because I'm getting pretty tired of having to learn different ways of building components every damned year. Most components don't need blazing-fast rendering engines, the templating engine of the now, or even two-way bindings out of the box, and thus I'd like to use components that can live on their own but also be easily wrapped into whatever framework I'm using. I'd like frameworks to be a lot closer to scaffolds, or actually be frameworks, as opposed to what most of them are now which is reimplementations of application units. The web components standard can help make it possible for tools to become interoperable between frameworks(okay, and view libraries), that would be wonderful.
- nevir 8y ago
  Web components work very well in isolation, and/or within a homogenous web component framework/library. However, it is still pretty challenging to pass data throughout web components (in a way that allows you to build a complete application). HTML attributes are not great for data transfer (string serialization for everything). JS properties are a bit opaque (not represented by markup). And everyone ends up wanting some sort of property binding system, which may be unrealistic to standardize. I think there will always be a place for some amount of framework/library support necessary for application builders.
  - ravenstine 8y ago
    Oh I definitely agree. I'm not at all proposing that components make frameworks obsolete. It's just that I would like a future where the Web Component standard becomes the first answer to the frontend development question before moving on to more specialized solutions. Existing frameworks and Web Components would go hand in hand.
  - tdumitrescu 8y ago
    Yeah, the way we use web components at Mixpanel involves sticking to the vanilla APIs for lifecycle management, but we still need libraries to handle inter-component communication, state and rendering (see my discussion at https://engineering.mixpanel.com/2018/06/12/making-web-components-work/ https://engineering.mixpanel.com/2018/06/12/making-web-compo... and https://github.com/mixpanel/panel https://github.com/mixpanel/panel). I do hope some of these concerns eventually get addressed in the standards though.
kyledrake 8y ago
This is a bit off topic, but I really wish the idea of including HTML imports (https://developer.mozilla.org/en-US/docs/Web/Web_Components/HTML_Imports https://developer.mozilla.org/en-US/docs/Web/Web_Components/...) was taken seriously. There's a lot of people that just want to make a simple HTML site with templates for things like the navigation menu, without a bunch of nasty JavaScript goop that can't be search indexed easily, and the ability to include simple templates using HTML would have been an huge resource for those people and for search engines. I think it really shows how much of a bubble the web often lives in now. We used to be able to just make a solid web site with simple HTML and a text editor. I shouldn't need to be an extremely hardcore JS programmer or use a crazy static site generator or overengineered LAMP backend to do basic things like reusing HTML and other things that could be largely accomplished with just HTML itself.
- vosper 8y ago
  > We used to be able to just make a solid web site with simple HTML and a text editor. I shouldn't need to be an extremely hardcore JS programmer or use a crazy static site generator or overengineered LAMP backend to do basic things like reusing HTML and other things that could be largely accomplished with just HTML itself. None of that functionality has gone away, has it? A lot of what a static site generator is doing is saving you copy-pasting a bunch of HTML across files, by giving you templates for common functionality. But you still end up with plain HTML files, and you can certainly get there by editing them all by hand in a text editor.
  - Scarbutt 8y ago
    I think you missed his point, he wants to be able to compose html without having to resort to a programming language.
    - pjmlp 8y ago
      Easy, configure Apache to serve Server Side Includes, the feature is still there. https://httpd.apache.org/docs/2.4/howto/ssi.html https://httpd.apache.org/docs/2.4/howto/ssi.html
rado 8y ago
Amazingly, Shadow DOM does not block all outside CSS. The * properties leak in, unless you add #container { all: initial; } inside, but that doesn't work in Firefox. I wonder why authors forget this strange fact.
- spankalee 8y ago
  I don't think it's very strange. It's extremely likely that you want to inherit the default inherited properties like color and font-family. Otherwise Web Components would look out of place on the page by default.
SEJeff 8y ago
I believe Home Assistant's new fancy UI codenamed "lovelace" is based on web components: https://www.home-assistant.io/lovelace/ https://www.home-assistant.io/lovelace/ This should give you a sense of the power of web components.
superbaconman 8y ago
I'm not such a fan of how spread out everything is. I'd really like to see html, js, and css all together in one place. React is the best I've seen, but it doesn't provide a good solution for css.
- spankalee 8y ago
  Check out LitElement. It lets you define everything in one place, and because it uses Shadow DOM, CSS is handled as well. Here's where we'll be with plain standard JavaScript once class fields and decorators land: import {LitElement, html, property, customElement} from '@polymer/lit-element'; @customElement('hello-element') class HelloElement extends LitElement { @property() name = 'World'; render() { return html` <style> :host { display: block; background: blue; } h1 { color: white; // scoped to the ShadowRoot } </style> <h1>Hello ${this.name}!</h1> `; } }
- marcosdumay 8y ago
  > I'd really like to see html, js, and css all together in one place. You mean like Vue components? I think HTML components go on the same line, although this article does not emphasizes this.
- cageface 8y ago
  Try styled-components: https://www.styled-components.com/ https://www.styled-components.com/ Makes handling CSS in react a pleasure.
ausjke 8y ago
I could be totally wrong here as I am not an expert in frontend, it seems Google has been the loner pushing web component(polymer,etc). Mozilla was lukewarm about it. Something changed or did I miss something badly? Vuejs has its own web-component(non-standardized), so does React. If browsers can provide native web-component support that will be really nice.
- e111077 8y ago
  I work at Google and can confirm that we are very much pushing web components and Polymer / lit-html.
robocat 8y ago
caniuse shadow components: https://caniuse.com/#feat=shadowdomv1 https://caniuse.com/#feat=shadowdomv1 So not Edge (I loath testing MSEdge - always finding new bugs in it - yesterday the F12 development tools crashed even on a blank page -- needed an opaque powershell script from MS to fix it...)
ehnto 8y ago
I put together a micro-pattern for working with WebComponents that I really wish were cross browser compatible as it is. It works in Firefox and Chrome and it is partly how I wish the web would move forward. There is no technical limitations to making encapsulated portable pieces of html, css and js, yet it seems a very uncommon practice to make libraries of small re-usable components, even if they are boutique to you or your company. I think that is partly down to how we go about specing out and producing websites, and partly down to the fact that many don't realise you can already do it. https://polylab.co/projects/polyblocks.html https://polylab.co/projects/polyblocks.html An important part of that is well encapsulated CSS, and theming on top of that, something I have written a little bit about as well. https://polylab.co/articles/ccm-contexts-and-components-css.html https://polylab.co/articles/ccm-contexts-and-components-css....
littlecranky67 8y ago
WebComponents only solve the problem of creating independent, self-contained functional units for the web. They don't fix all the other issues modern framework stacks try to fix like state management, change detection, two-way binding, inter-component communication/data passing etc. Thats why I don't see the framework soup (Angular, React, Vue, Ember, Aurelia) going anywhere in the near future. Maybe the "component" part will converge in the frameworks towards WebComponents but all the other bits and pieces the framework stacks ship will remain.
deleted 8y ago
[deleted]

170 points by lainon 8y ago

It's weird that the default behavior when appending a template is to not clone it requiring an additional clone call >>template.content.cloneNode(true)

lucideer 8y ago
That's the default behaviour when appending a DocumentFragment or a Node, and has been since 1997. The template is just a container for the DocumentFragment, the template content still behaves like any other DocumentFragment always would have, so changing behaviour would be pretty crazy.

Flenser 8y ago

Web components may give power to developers but they take it away from users. Any page made with web components is hostile to user styling. I'm surprised Mozilla would support them.

potch 8y ago
Hello! Author here. I'm a fan of web components for widgets and embeddable third-party interfaces. I'm not as much a fan of them to wrap a site's primary content, for both accessibility and user styling reasons.
- Flenser 8y ago
  Hi! I'm not a fan of them for web apps that use excessive whitespace between repeating components[1]. Previously you could just edit the global stylesheet in dev tools but now that only changes the current component. Edit: I get the widget / embedable use case but fear that it won't just be used for that. [1] e.g. Chrome's new material design bookmarks manager that shows far less bookmarks per page than the old design.
- wilsmex 8y ago
  Great write up. Can a web component author create one in such a way that the inner shadow dom styles ARE editable/styleable by the outer or person implementing the custom component?
  - megous 8y ago
    Yeah, I have the similar need. I want to use <slot> mechanism, so I need shadow DOM, but I'd like to re-use styles, so that they don't need to be copied to each instance of the component. Aside from complicating things, it seems wasteful. It should be possible to use styles from the document's CSS to style the innards of a web component. I'm still learning, and I'm still missing solution to this. I know about var(--custom-prop), but that's limited, and still doesn't help with the waste of useless duplication of styles.
    - spirodonfl 8y ago
      What I've done is kinda standardized the solution. I've made all my elements listen for a template tag in the html page that contains <link> tags to the stylesheets I use globally. <template id="x-global-styles"> <link rel="stylesheet" href="some/sheet.css" /> </template> Kinda like that. You can use prefetch in the main header to get all your styles in one shot, before page load, if you want. Then I make my element, if the template is found, pump the innards of the template into itself so all my styles are available. I use it in conjuction with tailwind so I can write atomic classes and include my atomic css with every element I desire. From what I can tell, for the most part, my styles don't get reloaded every time. I could be wrong. They seem to get prefetched, if I use a prefetch, or loaded once, then cached. It seems that no matter how many elements I have on the page there are no external calls to get the stylesheet every time. One and done. Correct me if I'm wrong here. It's just something I fiddled around with.
      - megous 8y ago
        Very interesting! Thank you. I didn't realize you can use <link> inside web component. But it makes sense! I read some more, and I reaized that it's probably meant to be that every component has its own small piece of CSS independent of the rest, so that you can use :host, and all the other trickery and so that least amount of CSS per component needs to be parsed and processed. So I ended up writing a small pre-processor, that converts sass files into a js file with a variables containing styles for each component (like BUTTON_CSS, DIALOG_CSS, SPLIT_LAYOUT_CSS). I just hope that there's some optimization in the browser, such that when the same <style> content is used in multiple instances of the component, it is parsed/processed only once and the results cached for the other instances.
peterhunt 8y ago
Weren’t user stylesheets removed from [1] / never present in most browsers? [1] https://src.chromium.org/viewvc/chrome?revision=234007&view=revision https://src.chromium.org/viewvc/chrome?revision=234007&view=...
- Flenser 8y ago
  I use GreaseMonkey/TamperMonkey, but WebComponent even make modifying a page using dev tools hard. Edit: e.g for printing or to make reading / using easier.
- srgpqt 8y ago
  They are still in Firefox, but hidden from the user.
  - lowercased 8y ago
    there seems to be something in mac safari for 'stylesheet' loading under 'advanced' preferences. if the browsers don't give people tools to edit/manage from within the browsers, even the average tech-savvy user won't bother with these, which is a bit of a shame.
blacksmith_tb 8y ago
It seems like the * CSS selector would still apply to these new elements? And in js things like el.children? I wonder if user styles via something like Stylus[1] could style them also? Now that I think about it, it seems like some of the worst (and most likely) applications will be advertising (to try and avoid blockers). 1: https://addons.mozilla.org/en-US/firefox/addon/styl-us/ https://addons.mozilla.org/en-US/firefox/addon/styl-us/
ravenstine 8y ago
How many users apply their own style sheets? I remember this was popular among a relatively few people, and now I don't know anyone who uses things like Stylish or Greasemonkey/Tampermonkey anymore.
- wwweston 8y ago
  User applied stylesheets are fairly uncommon, but then again, so is using a screen reader. Both are essentially a kind of accessibility tech, and when it comes to accessibility questions, the chief concern isn't necessarily whether everyone uses it. It's probably worth noting that reader-mode -- another accessibility tech -- does seem to be fairly popular.
  - someone7x 8y ago
    > and when it comes to accessibility questions, the chief concern isn't necessarily whether everyone uses it. I wish more developers had your perspective. My Dad uses Windows' high contrast mode. It's less that "literal dozens" use this feature and more that this feature transforms all that desktop-shaped-material into a computer for the vision impaired. Isn't the biggest performance enhancement the transition from not-working to working? I view accessibility as the ultimate performance enhancement for a given slice of users.
    - TeMPOraL 8y ago
      Some companies care. Most don't. Unless a feature is used by double-digit percentage of users, it'll be axed. It's a sad reality of today, and no, I don't buy the arguments about saving development time, not when said by the same people who also say they want to deliver value to users (as opposed to extract value from them). Because somehow, feature cancellation always seems to touch the features that enable users to unbreak things or optimize their experience.
      - zeroname 8y ago
        Delivering value to only 0.1% of users is equal to taking away value from the other 99.9% of users. You're not strictly saving development time, you're reallocating it to better utility. Now, if those 0.1% of users have some sort of legitimate accessibility issue, we can talk about it. If they just have highly idiosyncratic preferences about their user experience, the axe it shall be.
megous 8y ago
OTOH for me (another freakish web user who does unusual things with the web), web components may make it easier to scrape the website. Developers will be passing data into a component in some way, JSON atrtribute, or a nicely defined data in a property, so it will be easier to scrape and understand via devtools DOM insepctor. Insteaed of a soup of deeply nested divs, there will be nicer and more meaningful structure of web components.
- jazzyjackson 8y ago
  The move to single page apps have definitely surfaced a lot of JSON-speaking api endpoints that make scraping for data a thing of the past. A great thing for the web, I think, whether or not the site owners are aware!
megous 8y ago
You can still probably override attachShadow to ignore the argument, and make shadowRoot always open and then use that to modify the <style> inside shadowRoot. More complicated, but probably doable (with greasemonkey).
rictic 8y ago
The last time I looked into it, user agents may support the '>>>' combinator for cases like user styling, where the user should trump the page content.
simplify 8y ago
If web components will be built-in, I imagine it's possible for browsers to provide a way to style them in user-land.

ravenstine 8y ago

I really hope that web components take off, because I'm getting pretty tired of having to learn different ways of building components every damned year. Most components don't need blazing-fast rendering engines, the templating engine of the now, or even two-way bindings out of the box, and thus I'd like to use components that can live on their own but also be easily wrapped into whatever framework I'm using. I'd like frameworks to be a lot closer to scaffolds, or actually be frameworks, as opposed to what most of them are now which is reimplementations of application units. The web components standard can help make it possible for tools to become interoperable between frameworks(okay, and view libraries), that would be wonderful.

nevir 8y ago
Web components work very well in isolation, and/or within a homogenous web component framework/library. However, it is still pretty challenging to pass data throughout web components (in a way that allows you to build a complete application). HTML attributes are not great for data transfer (string serialization for everything). JS properties are a bit opaque (not represented by markup). And everyone ends up wanting some sort of property binding system, which may be unrealistic to standardize. I think there will always be a place for some amount of framework/library support necessary for application builders.
- ravenstine 8y ago
  Oh I definitely agree. I'm not at all proposing that components make frameworks obsolete. It's just that I would like a future where the Web Component standard becomes the first answer to the frontend development question before moving on to more specialized solutions. Existing frameworks and Web Components would go hand in hand.
- tdumitrescu 8y ago
  Yeah, the way we use web components at Mixpanel involves sticking to the vanilla APIs for lifecycle management, but we still need libraries to handle inter-component communication, state and rendering (see my discussion at https://engineering.mixpanel.com/2018/06/12/making-web-components-work/ https://engineering.mixpanel.com/2018/06/12/making-web-compo... and https://github.com/mixpanel/panel https://github.com/mixpanel/panel). I do hope some of these concerns eventually get addressed in the standards though.

kyledrake 8y ago

This is a bit off topic, but I really wish the idea of including HTML imports (https://developer.mozilla.org/en-US/docs/Web/Web_Components/HTML_Imports https://developer.mozilla.org/en-US/docs/Web/Web_Components/...) was taken seriously. There's a lot of people that just want to make a simple HTML site with templates for things like the navigation menu, without a bunch of nasty JavaScript goop that can't be search indexed easily, and the ability to include simple templates using HTML would have been an huge resource for those people and for search engines. I think it really shows how much of a bubble the web often lives in now. We used to be able to just make a solid web site with simple HTML and a text editor. I shouldn't need to be an extremely hardcore JS programmer or use a crazy static site generator or overengineered LAMP backend to do basic things like reusing HTML and other things that could be largely accomplished with just HTML itself.

vosper 8y ago
> We used to be able to just make a solid web site with simple HTML and a text editor. I shouldn't need to be an extremely hardcore JS programmer or use a crazy static site generator or overengineered LAMP backend to do basic things like reusing HTML and other things that could be largely accomplished with just HTML itself. None of that functionality has gone away, has it? A lot of what a static site generator is doing is saving you copy-pasting a bunch of HTML across files, by giving you templates for common functionality. But you still end up with plain HTML files, and you can certainly get there by editing them all by hand in a text editor.
- Scarbutt 8y ago
  I think you missed his point, he wants to be able to compose html without having to resort to a programming language.
  - pjmlp 8y ago
    Easy, configure Apache to serve Server Side Includes, the feature is still there. https://httpd.apache.org/docs/2.4/howto/ssi.html https://httpd.apache.org/docs/2.4/howto/ssi.html

rado 8y ago

Amazingly, Shadow DOM does not block all outside CSS. The * properties leak in, unless you add #container { all: initial; } inside, but that doesn't work in Firefox. I wonder why authors forget this strange fact.

spankalee 8y ago
I don't think it's very strange. It's extremely likely that you want to inherit the default inherited properties like color and font-family. Otherwise Web Components would look out of place on the page by default.

SEJeff 8y ago

I believe Home Assistant's new fancy UI codenamed "lovelace" is based on web components: https://www.home-assistant.io/lovelace/ https://www.home-assistant.io/lovelace/ This should give you a sense of the power of web components.

superbaconman 8y ago

I'm not such a fan of how spread out everything is. I'd really like to see html, js, and css all together in one place. React is the best I've seen, but it doesn't provide a good solution for css.

spankalee 8y ago
Check out LitElement. It lets you define everything in one place, and because it uses Shadow DOM, CSS is handled as well. Here's where we'll be with plain standard JavaScript once class fields and decorators land: import {LitElement, html, property, customElement} from '@polymer/lit-element'; @customElement('hello-element') class HelloElement extends LitElement { @property() name = 'World'; render() { return html` <style> :host { display: block; background: blue; } h1 { color: white; // scoped to the ShadowRoot } </style> <h1>Hello ${this.name}!</h1> `; } }
marcosdumay 8y ago
> I'd really like to see html, js, and css all together in one place. You mean like Vue components? I think HTML components go on the same line, although this article does not emphasizes this.
cageface 8y ago
Try styled-components: https://www.styled-components.com/ https://www.styled-components.com/ Makes handling CSS in react a pleasure.

ausjke 8y ago

I could be totally wrong here as I am not an expert in frontend, it seems Google has been the loner pushing web component(polymer,etc). Mozilla was lukewarm about it. Something changed or did I miss something badly? Vuejs has its own web-component(non-standardized), so does React. If browsers can provide native web-component support that will be really nice.

e111077 8y ago
I work at Google and can confirm that we are very much pushing web components and Polymer / lit-html.

robocat 8y ago

caniuse shadow components: https://caniuse.com/#feat=shadowdomv1 https://caniuse.com/#feat=shadowdomv1 So not Edge (I loath testing MSEdge - always finding new bugs in it - yesterday the F12 development tools crashed even on a blank page -- needed an opaque powershell script from MS to fix it...)

ehnto 8y ago

I put together a micro-pattern for working with WebComponents that I really wish were cross browser compatible as it is. It works in Firefox and Chrome and it is partly how I wish the web would move forward. There is no technical limitations to making encapsulated portable pieces of html, css and js, yet it seems a very uncommon practice to make libraries of small re-usable components, even if they are boutique to you or your company. I think that is partly down to how we go about specing out and producing websites, and partly down to the fact that many don't realise you can already do it. https://polylab.co/projects/polyblocks.html https://polylab.co/projects/polyblocks.html An important part of that is well encapsulated CSS, and theming on top of that, something I have written a little bit about as well. https://polylab.co/articles/ccm-contexts-and-components-css.html https://polylab.co/articles/ccm-contexts-and-components-css....

littlecranky67 8y ago

WebComponents only solve the problem of creating independent, self-contained functional units for the web. They don't fix all the other issues modern framework stacks try to fix like state management, change detection, two-way binding, inter-component communication/data passing etc. Thats why I don't see the framework soup (Angular, React, Vue, Ember, Aurelia) going anywhere in the near future. Maybe the "component" part will converge in the frameworks towards WebComponents but all the other bits and pieces the framework stacks ship will remain.

deleted 8y ago

[deleted]