Solvedpolymer Polymer Team - I'm really frustrated!

@tjsavage and the Polymer team, I am really frustrated with the Polymer Project / team!!!

I believe there are very few frameworks out there that are so committed to taking full advantage of and working so close to the metal of the amazing next generation web platform and specifically the Web Component technology set! Polymer should be (is?) that project! The tech benefits for WebApp development using Polymer is a no-brainer on many levels IMHO...

I keep seeing tweets and articles like this which continuously show the performance benefits of sticking with the platform and therefore Polymer!
https://twitter.com/paulcuth/status/837632180352401408
https://twitter.com/marcushellberg/status/837451438418616321
https://aerotwist.com/blog/when-everything-is-important-nothing-is/
(there are many more)

So why is Polymer not totally buzzing right up there with these other frameworks - React, Vue, etc.? Why is the community not jumping on this?

From the outside looking in I can only attribute this to two possibilities:

1. A lack of energy from the Polymer project management team who I feel do not spend enough time pushing the benefits of Polymer through the various media channels... It just feels like there is no energy there...
2. Internally Polymer is possibly a conflicting project with other projects such as Angular and is therefore not being pushed!?

On the first point:

• why does this issue have comments like "it would be nice if there is a little more communication", "Again, a update of the current state would be nice?" and "No News? Would realy be interesting to know where we are? When can we estimate first release?". Feedback on how things are to the community is slow and usually comes from issues like the one above.
• Polymer has been slow to adopt ES6/7 which other frameworks like React, Vue are not scared to assume by default - I understand the no-build concept but these days nearly every decent framework requires a build step! Just package built & unbuilt code in the same projects and default to the built one.
• Recently, not taking the perfect opportunity on the v1.0 release of the Web Component spec to solidly make 'breaking changes' to Polymer 2.x and therefore transport it into a project that competes with frameworks like React/Vue in terms of popularity - look at the Github Stars for these projects (React 61K, Vue.js 45K, Polymer 17K)!
• In v2.x not providing an imperative API that supports runtime DOM composition that makes binding to existing parent element just work - is this a design flaw in Polymer?

On the second point, it's anyone's guess - this is unlikely though, I would think!

Another point - look at the job market and compare the call for React jobs vs Polymer jobs!

The Polymer Project is such an opportunity to be the framework that drives Web Component technologies into being better supported by all modern browsers! Why is this not happening!?

If it doesn't take this opportunity then we may see another framework take up it's position of being the Web Component framework of choice!!!

I truly do not mean to offend here, if anything, I would like to see Polymer at least reach the level of recognition it deserves - right up there with React, Vue, etc!!!

How can we get it there!?

Hey @clintwood!

I hear your frustration, and appreciate your enthusiasm. We think there should be much more buzz too!

Polymer's growth has been tightly and necessarily constrained by broad adoption of the Web Components specs. I'm sure I'm preaching to the choir here about the promise of Web Components: platform-level, encapsulated component model, to make sharing components/possible easier across frameworks, to not have to re-invent a component model for every new framework, and ultimately to allow devs to write higher-level code while shipping less JS down to the client.

The Polymer project was designed to prove out Web Components, help shape the low-level API's themselves, and then ultimately to make it easier to build Web Components.

The history of the project has very tightly progressed along these lines:

• Polymer 0.1-0.5 releases were all about proving out early Web Components, as well as looking to tie in additional experimental specs (remember Object.observe!). With this, we helped bridge the gap between spec authors and developers to land on what might work and what might not.
• Polymer 1.0 was about proving Web Components could be used in production. This meant optimizing for performance - this is where Shady DOM came in so that we wouldn't have to lug around the full Shadow DOM polyfill on Safari.

Even with Polymer 1.0 though, we haven't come close to realizing the full potential of Web Components. True encapsulation, true re-usability, truly minimal JS is not possible without broad browser support for native Web Component API's. Polyfills are typically fine on desktop browser with big beefy CPU's and Wifi/Cable connections, but they do matter on mobile browsers.

Unfortunately, even though I think we've shown that despite polyfills you can still ship really fast, powerful experiences on mobile using Web Components, and even though I believe relying on polyfills should be considered an advantage, not a weakness, given that they disappear over time, the current state of Web Components is an incredibly easy thing to nitpick.

So while we're in this uncanny-valley, rather than target broad, Hacker News-type reach, we've been targeting large organizations and products inside and outside Google - those who have an immediate and crushing need for Web Components today - to make sure the project and toolset works for these use-cases.

As you note, we've recently hit a major milestone for Web Components - the Web Components v1 specs. Unfortunately, they haven't quite all shipped yet - Safari is yet to ship Custom Elements v1, though it is completed in Tech Preview. But we're extremely close.

So we've designed Polymer 2.0 to fully embrace these v1 specs. And we've been working hard to get 2.0 production-ready before v1 completely lands.

Polymer 2.0 is designed to actually realize the full promise of Web Components. One quick way to see this - here is a table showing the combined size of Polymer + the polyfills required to use 2.0's class-based element syntax:

The more specs supported natively, the less code required. Down to ~10kb on Chrome.

I wish we had a magic switch we could pull that would make Web Components wildly popular. By hitching our cart to the Web Platform horse, we're at the whim and the pace of the overall spec adoption - which is a long arc. Thanks to Google's backing we've been able to take this long view - to target the long-term paradigm shift rather than seeking short-term popularity.

I have not done as good a job as I'd like keeping the community updated on our progress - this is something we're actively working on changing our culture around.

We've also needed to conserve our credibility. As we all know, web developers can be an opinionated bunch :). We set out our long-term thesis and set the goalposts when Web Components v1 first solidified. Rather than continually pound this drum, we've put our heads down the last few (many) months to execute on this. The result will be Polymer 2.0, which will be released imminently.

We hope 2.0 will be a major transformation in Polymer's broad appeal. But we need this amazing community's help:

• We need help with feedback on the 2.0 release candidate, to make sure we end up shipping the right thing to stable. The community is absolutely critical here. We'll have more information coming on this release candidate very shortly.
• We need help building up a corpus of content on the web about Polymer. Answering StackOverflow questions, posting "How to get started" blog posts, etc.
• We need help growing the set of high-quality components available in the ecosystem - publishing to webcomponents.org. The set of components on webcomponents.org has been growing in leaps and bounds - let's keep it growing!

I hope this at least speaks to your concern, @clintwood. As a team we're pouring our hearts and souls into building the right next product, with 2.0. We need all the help and community energy we can get to make sure it's great. From there, I think we'll have a solid foundation to reach the popularity you're hoping for.

Hey guyz, take it easy...
Polymer 2.0 is on the way, I can't even imagine how much effort these guys are putting on it

I am sure we'll have tons of news when we get 2.0.0-stable... Then all of these feelings will go away and happiness will take place again 😇

I agree that there's more transparency needed. What's so hard about creating pull requests and showing progress there? I like how the html modules are approached on the github repo. Recently on the npm migration topic, one of the biggest ones, someone asked for a PR - no reply.

The answer is "we are working on it". Don't get me wrong, I do believe you are working on it, and the Polymer team is far more competent to get it done than the majority of developers relying on Polymer, but a little transparency what you're actually doing would be nice to have.

Transparency is better than just bullshitting us - we've also heard that html imports are coming for the last idk ... 3 years? It would be nicer if it would be kept real and expectations are realistic, not wishful thinking. At the last IO, again someone spoke "webcomponents are finally here, in x browsers and in progress in others". It's not even true. Microsoft still hasn't begun work on webcomponents and Firefox idk ... is it ever coming? Who knows... All I'm saying, a little bit more honesty would be appreciated with the entire project. (I'm aware the last example is actually a problem created by Microsoft & Mozilla, still please let's be a bit realistic with what the community should expect)

Also, no roadmap update after 2.0, which probably was your most significant webcomponents release so far is also meh :/

As a last comment, I want to thank the Polymer team for their hard work. I still believe what you are working on and what you are producing is one of the most valuable things out there on the open source space and it's invaluable for the future of the web. But in terms of communication to the communication, this is the worst project I'm following and I really hope things will improve in the future. I guess the problem is there's no financial consequences. Meteor Developer Group suffered from similar issues and they definitely lost customers, now their communication is really good for the most part compared to before. Maybe they can serve as inspiration for future improvements.

IMO building Polymer apps is kinda like a back to Backbone times. I mean, Polymer is great to build components, but offers very few project-level architecture solutions.

This can be partially fulfilled by projects like UniFlow for Polymer, and Polymer Redux, but for a long time we didn't have any guides on this.

So, when using Polymer, project-specific part of the code is much bigger than framework-specific. This means that switching to a different project might be pretty hard, as you will need to learn new concepts and solutions adopted by that project's team.

Another thing is tools. A month ago we received a new polymer-bundler, which is a lot more faster than vulcanize used to be. But these existing tools are less powerful than Webpack, because of Polymer limitations (e. g. placing styles in HTML, not stylesheets). They also require spec-related tricks to work (e. g. not so easy to implement HMR due to lack of ability to unregister element, etc).

Years on and nothing changed. Polymer to me is a failed project compared to React/Vue a
and AngularJS - not AngularJS. Apart from Firebase I really think Google have failed on both Angular and Polymer