Polymer Team - I'm really frustrated!

[clintwood]

@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!?

[web-padawan]

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

[LiberQuack]

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

[tjsavage]

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:

Native Browser Support				Combined size of Polymer & Polyfills (in kb, gzip)
Browser	HTMLImports	Custom Elements	ShadowDOM	Other Platform	1.x	2.x (legacy API)	2.x
Chrome	✔︎	✔︎	✔︎	✔︎	53	23	10
Safari w/ CEv1		✔︎	✔︎	✔︎	53	26	13
Safari 10			✔︎	✔︎	53	30	17
Firefox				✔︎	53	45	32
Microsoft Edge/IE					53	49	36
Polyfill size	3.5	3.7	14.8	3.5

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.

[tjsavage]

We're doing an issue scrub on Polymer/polymer currently - I'll move this thread to github.com/polymer/project where we try to keep these convo's open

[tjsavage]

This issue was moved to Polymer/project#36

[MehdiRaash]

Hello, based on the human being characteristics, many developers are scared of changes, on the other hand Web components look basically is a substantial change in Web development industry( in wrting code & its approach), so of course shifting in Polymer brings new problem and of course new solutions, but another factor that makes Polymer powerful is trusting more people on it for their real web scenarios( your software ).

[jogibear9988]

Again... 2 months... no new infos... Whats happening to designer? What are the plans of the team now, since polymer 2 is released? What are the plans about html includes or es6 modules? What about bower?

[AndreasGalster]

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.

[simplygreatwork]

Part of the problem is that there does not appear to be a cohesive kitchen sink demo for Polymer 2.0. Polymer 0.5-1.0 did have one. With Polymer 2.0, all of the documentation for UI elements is isolated behind webcomponents.org.

https://elements.polymer-project.org/

The Polymer project is so modular now that there is not any good top-level documentation for components. MDC Web is suffering from these same issues. If you look at the documentation for Vuetify or material.io, everything you need to know is front and center. Copy and paste.

[TimvdLippe]

@simplygreatwork All documentation of Polymer elements is available at https://www.polymer-project.org/2.0/docs/devguide/feature-overview which is very extensive. If you are missing something in this documentation, feel free to open an issue at https://github.com/polymer/docs

[jogibear9988]

Are there any News about polymer3? And about lit html?

[AndreasGalster]

lit-html just reached version 0.8 with Edge support, shady CSS support is supposed to come this week most likely, meaning lit-html should be close to production-readiness.

Polymer 3.0 is still being worked on in the modulizer repo, they've been quite busy lately, I'm guessing we will see a new release of all the elements via npm this month (just a hopeful assumption based on the effort they're pouring in)

[Khaleel]

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

[MehdiRaash]

I believe Polymer project cannot be judged normally with others, It's not correct. Web component on its own, is a new standard, so Polymer doesn't mean just as a library, that's why it's named polymer project. On the other hand, it's developed enough, of course every software out there need constant development...

[twoBirds]

There already is a working web component framework, it existed since 2006 as such, and is still being developed. It does not have special system requirements, so it works cross-browser and even on the server side out of the box. It supports lazy loading of web components (recursively). Also it easily digests autonomous custom elements /w a polyfill. Look at this small app code example, its is self-explaining: twobirds todoMVC app footer The API is documented within the package twobirds-core API, but additional support is meager so far. This will change in the nearer future, though.

[MehdiRaash]

I don't know about it but when I opened its website it was like since 2006 hasn't been changed... :-)

[twoBirds]

Thats why I am (so far locally) working on a website now ... but trust me the system covers all needs, and I recently used it for very complicated multi-tier programming in a multi-datacenter microservice environment. Since it has been a one-man show for so long I was limiting myself to jsDoc auto-documentation, but all feedback I get is about a website for examples, tutorials and better docs obviously - I had to start doing this. Feel free to contact me on skype frank.thuerigen

[MehdiRaash]

Good job, "but all feedback I get is about a website" I do understand that the feedbacks firstly should be about the code itself therefore will be valuable, but there is a reality which is on the (introducing)website at least there should be a simple definition along with basic examples, thus I feel more eager to discover the philosophy and ... behind it.

[mahdiridho]

I have been using polymer since 2017, from v1 v2 and v3. I ever developed the projects with angular 1 2 4 7 and ionic 1 4. My comparison, polymer is really powerfull than angular. I ever worked a lil bit with reactjs project and still fall in love with polymer yet. Many things I noted here from my comparison, these main reasons :

1. Polymer is webcomponent base, not a framework for me
2. I can't find the way to do super.template in both angular and reactjs. Maybe we can create a static template on the parent class first on angular or reactjs. Not sure it works?
3. Easy to create new own component/library by polymer init element, serve & demo it, install & import it to other project, publish it to npm. Tell me how do you create component in angular and react? How do you deploy it to be an npm package? How do you install and import to the other project? How do you maintain and update this component? Very2 complex right? They said reusable component, but hard to running or serve itself
4. Fully OOP, mostly my projects with polymer using fully OOP approach. Angular framework is modular approach, I will say implement fully OOP with angular need more effort. We can extends the class, but not the template either on angular and reactjs. See point 2
5. The speed is faster than both
6. Easy to parallize the task to the team because of point 4
7. this.$ is cool right? In angular will be complex
8. If we create the polymer app using lit-element approach, it's very similar to reactjs I think. So I can migrate my skill to reactjs easily. What do you think?
9. I love their cli that provide initialization for element, blank application, starter kit, and the shop. My customize shop is built with.

But ghost.. honestly it's very hard to get the job with this skill. It's something like you have Ronaldo but no Football team interested to buy even glance. I ever offered the polymer approach to my previous companies that developing with angular and reactjs. All of my arguments not change their choice.

The funny one, I got this issue link on google after I felt frustated find the google polymer job LOL