4 ms·

This is why Web Components are so important. It's great to have so much innovation, but when each innovation is incompatible with the next it makes it very dif

This is why Web Components are so important. It's great to have so much innovation, but when each innovation is incompatible with the next it makes it very difficult to actually use the better things. You can't incrementally adopt them, you have to port an entire application. This in turn makes it harder for new entrants to get adoption, even if they're better in some ways, because they need to reach a critical mass before many people are willing to put in the effort to, and accept the risk of, porting a whole app. If we establish the base component layer and interop with the platform and other components - which Web Components does - then people can innovate on the internals of components, things like how and when DOM is updated. This is mostly what's being focused on anyway, the component models themselves are usually pretty comparable. Not to mention that Shadow DOM is incredible and just fixes CSS. If Firefox finishes up their Web Components implementation soon, we'll be at 3/4 major browsers with native Web Components support. I think more people will take them as a given for basing their UI libraries on.

ausjke 9y ago
I did look into web components and google polymer, great idea, still somehow not gaining much traction as they should.
- spankalee 9y ago
  I work on Polymer, and I think we're well on the way to fixing that. Our uptake with large enterprises is quite good already, we're just not very popular with the HN crowd... yet. Our annual summit starts Tuesday, and the talks are live-streamed, check them out for some updates: https://summit.polymer-project.org/schedule https://summit.polymer-project.org/schedule
  - ausjke 9y ago
    Thanks. Looking forward to the live stream.
  - mbrumlow 9y ago
    I tried to push polymer at my work (I use it for personal projects). The problem I came into is I am a backend guy trying to convince that polymer and web components are the only sane way that I have ever seen to do web dev. To many people were set it their own ways had just flat out did not want to learn something new. They could not put down react and redux for two seconds. Admittedly I am not a front end developer, but when I did get some to have conversations many of them went like this -- How do you do xyz in polymer / web components -- Umm seems to be a concept your framework had to create at a work around, that is not something you will need to worry about any more. So what did we end up with? Some use react, some use ZK!?!, some just stick with straight up html/css/js -- oh and we have some angular too, but that fell apart because the guy doing it tried to do some weird shit with making some sort of tight integration with zk... Side rant, if I have somebody send me that video about how react just had to be created to fix unread notification count at facebook one more time... Webdev is a mess in my opinion and coming from the backend / systems side of things polymer / web components is the only thing that looks sane to me. Beyond what the component looks like I think a push in this direction will hopefully remove the requirement for a "web developer" vs just another developer who can work on any part of the project.
  - jondubois 9y ago
    I've been using Polymer for several years on my side projects - Based on pure technical merit, I've always liked it the most of all other front end frameworks (though I have to say that in the early days performance and cross-browser compatibility were issues; but it's no longer the case though; now it's just great). Most companies these days are using React or Angular 2 (that's what I've been forced to use as part of my contract work). VueJS is getting traction but I don't feel that Polymer is getting the recognition it deserves just yet (it's very hard to find Polymer contract work). I really like that I don't need a separate compile step to build an app (almost no setup). The way the components compose together is also really nice. The CSS style encapsulation of Polymer 2.0 is another great feature - It might upset a few people due to lack of automatic backwards compatibility with external stylesheets but I do think it's the right long term decision. If someone is starting an app from scratch today, I think that Polymer 2 is the best choice.
  - bruxis 9y ago
    Interesting that https://polymer-project.org/ https://polymer-project.org/ does not load, but https://www.polymer-project.org/ https://www.polymer-project.org/ works fine.
  - Casperin 9y ago
    Wow, this couldn't be better place and timing for me. I can actually make it. I can't find anything about price. Is it free to attend? Would love to come.
    - ergo14 9y ago
      Yeah polymer summit is free, I was going to attend this year but some thing collide for me :/
      - Casperin 9y ago
        I'm going!
- spankalee 9y ago
  Also, take a look at SkateJS, a Web Components library that takes a more JavaScript-centric approach than Polymer: https://github.com/skatejs/skatejs https://github.com/skatejs/skatejs By default it uses Preact to render components, but you can switch it out for any renderer. The author of SkateJS is speaking at the Polymer summit too.
  - idibidiart 9y ago
    If you run into Trey at the conference tell him we're all waiting for it! With excitement :-)
- brylie 9y ago
  The [Aurelia](https://aurelia.io https://aurelia.io) framework is also aligned with Web Components and other web standards. Aurelia extends beyond Web Components, and comes with a lot of features built-in, such as routing, validation, and internationalization. This saves time from having to assemble/build your own framework.
chuckdries 9y ago
Can I pick your brain for a minute? I'm vaguely aware of what the shadow DOM does, how on earth does it have anything to do with, let alone "fix," CSS?
- mirkules 9y ago
  It "fixes" it by (sort-of) hiding the styling from the parent CSS. Shadow DOM is kind of like OOP in that regard: it encapsulates a bunch of data (styles, other objects) and makes it seem like one object.. er, sorry, I mean component :)
- spankalee 9y ago
  Shadow roots - where components put their internal DOM - create CSS scopes with both upper and lower bounds. This gives both encapsulation and perf benefits. 1) You don't have to worry about selectors for your component internals accidentally matching somewhere else in the document. As a result you can write simple selectors, often just tagname or id selectors, and have much smaller stylesheets. It's just a lot easier to read and reason about. 2) Perf is better, partially because of smaller style sheets and simpler selectors, but also because there's much, much less tree invalidation when DOM changes because you only invalidate inside the scope of the change. There's also huge parsing benefits because browsers deduplicate <style> tags that have identical text, so if you put the same style in many shadow roots, it's only parsed once, and one stylesheet object among all the roots.
  - wruza 9y ago
    I often hear that "DOM caching, DOM invalidation" talk, but being non-web guy can't figure out what's the issue is. Seems like Santa didn't deliver cell renderer conception into DOM? :) Afaik, you basically draw table rows and cells via distinct widgets, no doubt it's expensive as hell.
ralmidani 9y ago
Universal web components are a pipe dream. Even within a community using the same framework or library, there is disagreement on how to solve certain problems. For example, the folks behind React Router removed parsing of querystrings, because people wanted the flexibilty of using alternative solutions [0]. It's hard to imagine something more trivial than parsing querystrings, yet no consensus exists among users of the same library (which itself is not officially-sanctioned by FB yet, and even React, while stronger than other libraries, is not loved and used by all client-side web devs) on how to do it best. Yet people think someday in the near future, these differences will just disappear magically, and we will be able to author web components that snap--like Lego bricks--into whatever environment a developer wants? [0] https://github.com/ReactTraining/react-router/issues/4410 https://github.com/ReactTraining/react-router/issues/4410
- spankalee 9y ago
  If you look at the component models themselves, they're incredibly similar to Custom Elements. Most of the lifecycle hooks are the same, and things like setProps() in React are replaceable by reactive setters. So yes, I do think it'll work.
  - deleted 9y ago
    [deleted]
  - ralmidani 9y ago
    querySelector() and querySelectorAll() are similar to jQuery, but they are not what unseated jQuery. It took a new library with compelling new features (unidirectional data flow, no need to use a special, crippled language just for templates) to get people to abandon jQuery. React is the dominant client-side web framework, but its preferred template syntax has a method for inserting components into the document which is totally different from the "standard" (and Ember) way of doing things. JSX uses CapitalizedComponentNames, while the standard uses dasherized-component-names. JSX has self-closing tags with slashes before the closing angle bracket, while the standard does not. There are perhaps tens of thousands of devs using React, Preact, and Inferno. How can these differences be smoothed over in order to enable universal web components?
pjmlp 9y ago
Web Components would make me finally be happy again when doing web development, but sadly I don't get to code only for latest browser versions and polyfills many times hinder more than help.

ausjke 9y ago

I did look into web components and google polymer, great idea, still somehow not gaining much traction as they should.

spankalee 9y ago
I work on Polymer, and I think we're well on the way to fixing that. Our uptake with large enterprises is quite good already, we're just not very popular with the HN crowd... yet. Our annual summit starts Tuesday, and the talks are live-streamed, check them out for some updates: https://summit.polymer-project.org/schedule https://summit.polymer-project.org/schedule
- ausjke 9y ago
  Thanks. Looking forward to the live stream.
- mbrumlow 9y ago
  I tried to push polymer at my work (I use it for personal projects). The problem I came into is I am a backend guy trying to convince that polymer and web components are the only sane way that I have ever seen to do web dev. To many people were set it their own ways had just flat out did not want to learn something new. They could not put down react and redux for two seconds. Admittedly I am not a front end developer, but when I did get some to have conversations many of them went like this -- How do you do xyz in polymer / web components -- Umm seems to be a concept your framework had to create at a work around, that is not something you will need to worry about any more. So what did we end up with? Some use react, some use ZK!?!, some just stick with straight up html/css/js -- oh and we have some angular too, but that fell apart because the guy doing it tried to do some weird shit with making some sort of tight integration with zk... Side rant, if I have somebody send me that video about how react just had to be created to fix unread notification count at facebook one more time... Webdev is a mess in my opinion and coming from the backend / systems side of things polymer / web components is the only thing that looks sane to me. Beyond what the component looks like I think a push in this direction will hopefully remove the requirement for a "web developer" vs just another developer who can work on any part of the project.
- jondubois 9y ago
  I've been using Polymer for several years on my side projects - Based on pure technical merit, I've always liked it the most of all other front end frameworks (though I have to say that in the early days performance and cross-browser compatibility were issues; but it's no longer the case though; now it's just great). Most companies these days are using React or Angular 2 (that's what I've been forced to use as part of my contract work). VueJS is getting traction but I don't feel that Polymer is getting the recognition it deserves just yet (it's very hard to find Polymer contract work). I really like that I don't need a separate compile step to build an app (almost no setup). The way the components compose together is also really nice. The CSS style encapsulation of Polymer 2.0 is another great feature - It might upset a few people due to lack of automatic backwards compatibility with external stylesheets but I do think it's the right long term decision. If someone is starting an app from scratch today, I think that Polymer 2 is the best choice.
- bruxis 9y ago
  Interesting that https://polymer-project.org/ https://polymer-project.org/ does not load, but https://www.polymer-project.org/ https://www.polymer-project.org/ works fine.
- Casperin 9y ago
  Wow, this couldn't be better place and timing for me. I can actually make it. I can't find anything about price. Is it free to attend? Would love to come.
  - ergo14 9y ago
    Yeah polymer summit is free, I was going to attend this year but some thing collide for me :/
    - Casperin 9y ago
      I'm going!
spankalee 9y ago
Also, take a look at SkateJS, a Web Components library that takes a more JavaScript-centric approach than Polymer: https://github.com/skatejs/skatejs https://github.com/skatejs/skatejs By default it uses Preact to render components, but you can switch it out for any renderer. The author of SkateJS is speaking at the Polymer summit too.
- idibidiart 9y ago
  If you run into Trey at the conference tell him we're all waiting for it! With excitement :-)
brylie 9y ago
The [Aurelia](https://aurelia.io https://aurelia.io) framework is also aligned with Web Components and other web standards. Aurelia extends beyond Web Components, and comes with a lot of features built-in, such as routing, validation, and internationalization. This saves time from having to assemble/build your own framework.

chuckdries 9y ago

Can I pick your brain for a minute? I'm vaguely aware of what the shadow DOM does, how on earth does it have anything to do with, let alone "fix," CSS?

mirkules 9y ago
It "fixes" it by (sort-of) hiding the styling from the parent CSS. Shadow DOM is kind of like OOP in that regard: it encapsulates a bunch of data (styles, other objects) and makes it seem like one object.. er, sorry, I mean component :)
spankalee 9y ago
Shadow roots - where components put their internal DOM - create CSS scopes with both upper and lower bounds. This gives both encapsulation and perf benefits. 1) You don't have to worry about selectors for your component internals accidentally matching somewhere else in the document. As a result you can write simple selectors, often just tagname or id selectors, and have much smaller stylesheets. It's just a lot easier to read and reason about. 2) Perf is better, partially because of smaller style sheets and simpler selectors, but also because there's much, much less tree invalidation when DOM changes because you only invalidate inside the scope of the change. There's also huge parsing benefits because browsers deduplicate <style> tags that have identical text, so if you put the same style in many shadow roots, it's only parsed once, and one stylesheet object among all the roots.
- wruza 9y ago
  I often hear that "DOM caching, DOM invalidation" talk, but being non-web guy can't figure out what's the issue is. Seems like Santa didn't deliver cell renderer conception into DOM? :) Afaik, you basically draw table rows and cells via distinct widgets, no doubt it's expensive as hell.

ralmidani 9y ago

Universal web components are a pipe dream. Even within a community using the same framework or library, there is disagreement on how to solve certain problems. For example, the folks behind React Router removed parsing of querystrings, because people wanted the flexibilty of using alternative solutions [0]. It's hard to imagine something more trivial than parsing querystrings, yet no consensus exists among users of the same library (which itself is not officially-sanctioned by FB yet, and even React, while stronger than other libraries, is not loved and used by all client-side web devs) on how to do it best. Yet people think someday in the near future, these differences will just disappear magically, and we will be able to author web components that snap--like Lego bricks--into whatever environment a developer wants? [0] https://github.com/ReactTraining/react-router/issues/4410 https://github.com/ReactTraining/react-router/issues/4410

spankalee 9y ago
If you look at the component models themselves, they're incredibly similar to Custom Elements. Most of the lifecycle hooks are the same, and things like setProps() in React are replaceable by reactive setters. So yes, I do think it'll work.
- deleted 9y ago
  [deleted]
- ralmidani 9y ago
  querySelector() and querySelectorAll() are similar to jQuery, but they are not what unseated jQuery. It took a new library with compelling new features (unidirectional data flow, no need to use a special, crippled language just for templates) to get people to abandon jQuery. React is the dominant client-side web framework, but its preferred template syntax has a method for inserting components into the document which is totally different from the "standard" (and Ember) way of doing things. JSX uses CapitalizedComponentNames, while the standard uses dasherized-component-names. JSX has self-closing tags with slashes before the closing angle bracket, while the standard does not. There are perhaps tens of thousands of devs using React, Preact, and Inferno. How can these differences be smoothed over in order to enable universal web components?

pjmlp 9y ago

Web Components would make me finally be happy again when doing web development, but sadly I don't get to code only for latest browser versions and polyfills many times hinder more than help.