Polymer 2 and Polymer 3 together - what's the route?

[Joern Turner]

We're still developing Polymer 2 applications but considering the move.

However there's one big questions that comes up. What to do with third-party components that still rely on Polymer 2? I know there's the Polymer Modularizer but shall we really convert third-party code so that it works in our newly ported Polymer 3 apps? That doesn't feel very good as you suddenly end up with maintaining foreign code and have to look after updates and fixes for those components yourself.

There are piles of good components around at webcomponents.org which are still in Polymer 2 and you never know if they will ever be ported to Polymer 3.

Are there alternatives to the conversion?

Another worry: what happens with the next major update? Will we need to port all our our components (which are certainly hundreds already) with every new major release? That really puts a huge burden on developers (and project leads looking for the budget).

I understand that the standard itself is still moving but these questions should be considered before such breaking changes are set in place.

Thanks for your thoughts on this,

Joern

[ssis...@customdelivery.net]

I share your frustration Joerm, as a small startup who started with Polymer 1 we still have some of our components in V1. It's messy business but V2 upgrade to 3 is even worst just like you mentioned, having issue with many components in V2 still. luckily we sort of invested some time and just made pretty much all the components ourselves but that comes with it's own cost. Overall, we're grateful for Polymer team's great work and yet expect a little bit more attention to the service they're providing otherwise they can easily send many people down some rabbit wholes and leave us in a ditch. 

Cheers

[Justin Fagnani]

I first want to point out that the transitions that we dealt with in Polymer 2 and Polymer 3 we mostly out of our control. The Web Components v1 spec we just different in some important ways, and we tried our best to ease that transition in Polymer 2 with hybrid mode. Then HTML Imports was clearly not going to be adopted while JS modules were implemented in every browser, and Bower was deprecated and didn't have many important packages available on it. We tried to mitigate those transitions by not changing the Polymer 3 API at all and building Modulizer.

But there's really not much we can do about libraries that haven't made the transition. There really isn't a way to import HTML Imports into JS, which is one of the reasons it didn't get adoption. The difficulty of using Polymer 2 components in Polymer 3 is the same difficulty that the entire rest of the web development ecosystem has had with Polymer until Polymer 3.

The best thing going is that if the components you use are open source they can be forked and converted, and again, the Polymer API itself didn't change.

The good news is that the Web Components v1 specs are stable and implemented in 3 major engines and in-development in the 4th. So we won't have a Polymer 1 -> Polymer 2 like transition again. And JS modules are implemented in all engines, and the whole ecosystem has coalesced around npm, so we won't have a Polymer 2 -> Polymer 3 like transition again.

What we will have is much smoother, incremental transitions like Polymer -> LitElement, where we can easily mix and match components from different vendors or built with different helper libraries. The largest barrier there is needing to manually listen for Polymer's {property}-changed events to implement 2-way data-binding if you use that, and there are helpers for that popping up. There's no application-wide blocker like incompatible specs or package managers.

So I apologize for the pains, and we really have tried to minimize them. The only way this could have been avoided though, would be if the Web Component v0 specs, including HTML Imports, were implemented by all browsers, and the ecosystem coalesced around Bower. That just didn't happen though.

Cheers,

  Justin

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f05dd191-3948-480e-b9e1-de473834eefb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Sisakht]

Thanks Justin, 

Like I said, I really appreciate the good work Polymer team has done. I think perhaps the missing part of all this is a post in your website or something like that to sort of ensure the users that this is not being abandoned and reassure them. As someone who basically got in web development via Polymer and because of it's simplicity I really hope and want to see Polymer continuing it's good work and keep up with the change. 

Thank you again, 

Sepehr

[Joern Turner]

Justin,

appreciate your comments. Regarding the future 'transition pain' i honestly hope you're right and yes things seem to stabilize. 

However that does not mean that i'm happy with the decisions taken. I fully understand why the Polymer team acted as it acted. The train is gone and some decisions cannot be reverted. We'll need to accept this as we still see Web Components as a huge thing. However literal templates are not the real thing even if you promote their performance advantages all day (still hoping for the HTML modules).

Yes, i agree that the world has decided differently that i would have hoped and that's a fact we have to deal with. The Polymer team does it's best i guess and it does it well. 

There's just one thing that worries me: it's too silent around Polymer. There just this one big event (Google IO) when there are news and the whole project feels just not as much present than other communities. I'd really like to see Polymer and Web Components succeed - standards built into the browser are so much better than any framework.

Thanks for the good work.

Joern