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
So yes, I do think it'll work.
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?
Reusable = Reusable within ONE family of applications using a similar stack. That's already pretty nice.
UX guidelines keep evolving too and it will remain a business advantage to be able to provide a better experience (and quickly so) than your competitors. Who seriously like the crappy <select> or <input type="date"> desktop web browsers provide?
There are react components that provide a good experience that replicates the features of most built ins, but it's a constantly moving target considering native widgets vary between platforms.
In general I agree with you and gp though. I would love for web components to one day be the standard but I'll believe it when I see it.
Our annual summit starts Tuesday, and the talks are live-streamed, check them out for some updates: https://summit.polymer-project.org/schedule
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.
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.
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.
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.
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.
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.