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

On Tuesday, November 27, 2018 at 4:34:49 PM UTC-7, Justin Fagnani wrote:
>
> 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
>
>
>
> On Tue, Nov 27, 2018 at 8:35 AM <ssis...@customdelivery.net <javascript:>> 
> wrote:
>
>> 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
>>
>> On Tuesday, November 27, 2018 at 8:03:13 AM UTC-7, Joern Turner wrote:
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> 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 <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/polymer-dev/f05dd191-3948-480e-b9e1-de473834eefb%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/polymer-dev/f05dd191-3948-480e-b9e1-de473834eefb%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/polymer-dev/6ef59626-a3de-4e5d-a084-dd0199e03298%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to