Re: [polymer-dev] Polymer cli implemented in Typescript? What gives?

['Peter Burns' via Polymer]

It is less familiar, but give it a shot! If the community finds it hard to
work with I think that'd be an important signal. My suspicion is that it
will make things easier and not harder on balance for contributors but I'm
willing to update based on evidence :)

On Tue, May 24, 2016 at 4:12 PM, 'AJ Ortega' via Polymer <
polymer-dev@googlegroups.com> wrote:

> I would argue that it lowers the barrier to entry for new people. There's
> a little bit of syntax that could be distracting, but with an editor that
> has typescript support, you can dive into a function and instantly know
> that types the arguments have. I often spend huge amounts of time tracing
> back a function's stack to figure out what shape an object passed to it is.
>
> On Tue, May 24, 2016 at 3:40 PM,  wrote:
>
>> First of all, thanks for your answers! It's cool that you're taking the
>> time to discuss this.
>>
>> Being a fully open source project I like to see Polymer as a community
>> effort, even if the vast majority of contributions come from the core team.
>> I agree that the use of typescript might not affect anyone downstream but I
>> think it does significantly raise the barrier of entry for new people
>> wanting to contribute. But then maybe that is not necessarily a bad thing.
>>
>> On Tuesday, May 24, 2016 at 5:06:50 PM UTC-5, rictic wrote:
>>>
>>> I second that. For our node-based tools, the decision to go with
>>> typescript was very straightforward. Our use of typescript has no impact on
>>> anyone downstream, whether they use the tools as libraries or as binaries,
>>> as by the time the code is published in npm it's totally normal, legible,
>>> commented javascript.
>>>
>>> If typescript were to part ways with the standard, then we could migrate
>>> off of it with minimal effort. It's purely a labor saving device for those
>>> of us that contribute to the tools repos.
>>>
>>> I'm more skeptical than Justin of compile-to-javascript languages, but
>>> for Typescript the output looks so much like the input that it does not
>>> worry me or feel like a departure from the platform.
>>>
>>> On Tuesday, May 24, 2016 at 12:08:31 PM UTC-7, Justin Fagnani wrote:

 Using TypeScript in tool has really helped our development process -
 from documentation, refactoring, and code-completion, to the type checking
 and errors that compliments our tests. We've been converting our tools
 projects to TypeScript for months now, so this is nothing new.

 There are extremely few downsides that we've experienced in practice.
 The TypeScript compiler is so fast that the project is build be the time we
 switch tabs to run tests or a command. The main outstanding issue is stack
 traces referencing the compiled output, but this hasn't been much of a
 hinderance - the output is very similar to the input, and we're going to
 look into source map support. I'm not aware what other drawbacks might be
 big issues.

 I personally don't think that the "Use the Platform" philosophy is in
 conflict with TypeScript, or many other compile-to-JS languages for that
 matter - in node or the web. For tools, we don't run some huge abstraction
 over node's processing model, or it's core libraries. On the web, all of
 the critical platform features are available as with JS: The entire DOM,
 including Custom Elements, Mutation Observer, Custom Events, Shadow DOM,
 the CSSOM, and all JS features like classes, Promises, etc. TypeScript
 doesn't define it's own object model, and always uses JS features directly.

 The tools team really needs to maximize it's output, and TypeScript
 helps us do that while still targeting Node, which our customers
 appreciate. so there's no reservations from us here. In fact, we grow
 happier with the decision every day.

 Cheers,
   Justin


 On Tue, May 24, 2016 at 11:10 AM, Daniel Llewellyn 
 wrote:

> Personally, I am a bit ambivalent towards Typescript.
>
> On one hand I like the types system helping me during development; but
> on the other, like you, I like to use the language of the platform 
> natively
> to prevent weirdness in machine-written code that is less understandable 
> to
> a human reader. The IO mentions of using the platform rather than
> abstractions also points towards not using Typescript.
>
> Sent from Nylas N1 , the extensible,
> open source mail client.
> On May 24 2016, at 7:06 pm, mar...@maklesoft.com wrote:
>
>> I mean nothing against Typescript but after all the talk at I/O about
>> sticking to standards and reducing the amount of necessary tooling, 
>> whoever
>> thought this was a good idea? I understand that there are a lot of things
>> that speak for Typescript in general but I haven't seen it used anywhere
>> else in the 

Re: [polymer-dev] Polymer cli implemented in Typescript? What gives?

['AJ Ortega' via Polymer]

I would argue that it lowers the barrier to entry for new people. There's a
little bit of syntax that could be distracting, but with an editor that has
typescript support, you can dive into a function and instantly know that
types the arguments have. I often spend huge amounts of time tracing back a
function's stack to figure out what shape an object passed to it is.

On Tue, May 24, 2016 at 3:40 PM,  wrote:

> First of all, thanks for your answers! It's cool that you're taking the
> time to discuss this.
>
> Being a fully open source project I like to see Polymer as a community
> effort, even if the vast majority of contributions come from the core team.
> I agree that the use of typescript might not affect anyone downstream but I
> think it does significantly raise the barrier of entry for new people
> wanting to contribute. But then maybe that is not necessarily a bad thing.
>
> On Tuesday, May 24, 2016 at 5:06:50 PM UTC-5, rictic wrote:
>>
>> I second that. For our node-based tools, the decision to go with
>> typescript was very straightforward. Our use of typescript has no impact on
>> anyone downstream, whether they use the tools as libraries or as binaries,
>> as by the time the code is published in npm it's totally normal, legible,
>> commented javascript.
>>
>> If typescript were to part ways with the standard, then we could migrate
>> off of it with minimal effort. It's purely a labor saving device for those
>> of us that contribute to the tools repos.
>>
>> I'm more skeptical than Justin of compile-to-javascript languages, but
>> for Typescript the output looks so much like the input that it does not
>> worry me or feel like a departure from the platform.
>>
>> On Tuesday, May 24, 2016 at 12:08:31 PM UTC-7, Justin Fagnani wrote:
>>>
>>> Using TypeScript in tool has really helped our development process -
>>> from documentation, refactoring, and code-completion, to the type checking
>>> and errors that compliments our tests. We've been converting our tools
>>> projects to TypeScript for months now, so this is nothing new.
>>>
>>> There are extremely few downsides that we've experienced in practice.
>>> The TypeScript compiler is so fast that the project is build be the time we
>>> switch tabs to run tests or a command. The main outstanding issue is stack
>>> traces referencing the compiled output, but this hasn't been much of a
>>> hinderance - the output is very similar to the input, and we're going to
>>> look into source map support. I'm not aware what other drawbacks might be
>>> big issues.
>>>
>>> I personally don't think that the "Use the Platform" philosophy is in
>>> conflict with TypeScript, or many other compile-to-JS languages for that
>>> matter - in node or the web. For tools, we don't run some huge abstraction
>>> over node's processing model, or it's core libraries. On the web, all of
>>> the critical platform features are available as with JS: The entire DOM,
>>> including Custom Elements, Mutation Observer, Custom Events, Shadow DOM,
>>> the CSSOM, and all JS features like classes, Promises, etc. TypeScript
>>> doesn't define it's own object model, and always uses JS features directly.
>>>
>>> The tools team really needs to maximize it's output, and TypeScript
>>> helps us do that while still targeting Node, which our customers
>>> appreciate. so there's no reservations from us here. In fact, we grow
>>> happier with the decision every day.
>>>
>>> Cheers,
>>>   Justin
>>>
>>>
>>> On Tue, May 24, 2016 at 11:10 AM, Daniel Llewellyn 
>>> wrote:
>>>
 Personally, I am a bit ambivalent towards Typescript.

 On one hand I like the types system helping me during development; but
 on the other, like you, I like to use the language of the platform natively
 to prevent weirdness in machine-written code that is less understandable to
 a human reader. The IO mentions of using the platform rather than
 abstractions also points towards not using Typescript.

 Sent from Nylas N1 , the extensible, open
 source mail client.
 On May 24 2016, at 7:06 pm, mar...@maklesoft.com wrote:

> I mean nothing against Typescript but after all the talk at I/O about
> sticking to standards and reducing the amount of necessary tooling, 
> whoever
> thought this was a good idea? I understand that there are a lot of things
> that speak for Typescript in general but I haven't seen it used anywhere
> else in the Polymer ecosystem and I don't understand why the team chose to
> start using it now. I'm not going to list all the reasons why I think this
> is a bad idea - I think everybody in the team is aware of the drawbacks -
> but I'd love to hear the reasoning behind this.
>
> 
>
> Sorry, but I just had to get this out of my system. Really love the
> work you're doing! Keep it up!
>
> Follow Polymer on Google+: 

Re: [polymer-dev] Polymer cli implemented in Typescript? What gives?

[martin]

First of all, thanks for your answers! It's cool that you're taking the 
time to discuss this.

Being a fully open source project I like to see Polymer as a community 
effort, even if the vast majority of contributions come from the core team. 
I agree that the use of typescript might not affect anyone downstream but I 
think it does significantly raise the barrier of entry for new people 
wanting to contribute. But then maybe that is not necessarily a bad thing.

On Tuesday, May 24, 2016 at 5:06:50 PM UTC-5, rictic wrote:
>
> I second that. For our node-based tools, the decision to go with 
> typescript was very straightforward. Our use of typescript has no impact on 
> anyone downstream, whether they use the tools as libraries or as binaries, 
> as by the time the code is published in npm it's totally normal, legible, 
> commented javascript.
>
> If typescript were to part ways with the standard, then we could migrate 
> off of it with minimal effort. It's purely a labor saving device for those 
> of us that contribute to the tools repos.
>
> I'm more skeptical than Justin of compile-to-javascript languages, but for 
> Typescript the output looks so much like the input that it does not worry 
> me or feel like a departure from the platform.
>
> On Tuesday, May 24, 2016 at 12:08:31 PM UTC-7, Justin Fagnani wrote:
>>
>> Using TypeScript in tool has really helped our development process - from 
>> documentation, refactoring, and code-completion, to the type checking and 
>> errors that compliments our tests. We've been converting our tools projects 
>> to TypeScript for months now, so this is nothing new.
>>
>> There are extremely few downsides that we've experienced in practice. The 
>> TypeScript compiler is so fast that the project is build be the time we 
>> switch tabs to run tests or a command. The main outstanding issue is stack 
>> traces referencing the compiled output, but this hasn't been much of a 
>> hinderance - the output is very similar to the input, and we're going to 
>> look into source map support. I'm not aware what other drawbacks might be 
>> big issues.
>>
>> I personally don't think that the "Use the Platform" philosophy is in 
>> conflict with TypeScript, or many other compile-to-JS languages for that 
>> matter - in node or the web. For tools, we don't run some huge abstraction 
>> over node's processing model, or it's core libraries. On the web, all of 
>> the critical platform features are available as with JS: The entire DOM, 
>> including Custom Elements, Mutation Observer, Custom Events, Shadow DOM, 
>> the CSSOM, and all JS features like classes, Promises, etc. TypeScript 
>> doesn't define it's own object model, and always uses JS features directly.
>>
>> The tools team really needs to maximize it's output, and TypeScript helps 
>> us do that while still targeting Node, which our customers appreciate. so 
>> there's no reservations from us here. In fact, we grow happier with the 
>> decision every day.
>>
>> Cheers,
>>   Justin
>>
>>
>> On Tue, May 24, 2016 at 11:10 AM, Daniel Llewellyn  
>> wrote:
>>
>>> Personally, I am a bit ambivalent towards Typescript.
>>>
>>> On one hand I like the types system helping me during development; but 
>>> on the other, like you, I like to use the language of the platform natively 
>>> to prevent weirdness in machine-written code that is less understandable to 
>>> a human reader. The IO mentions of using the platform rather than 
>>> abstractions also points towards not using Typescript.
>>>
>>> Sent from Nylas N1 , the extensible, open 
>>> source mail client.
>>> On May 24 2016, at 7:06 pm, mar...@maklesoft.com wrote: 
>>>
 I mean nothing against Typescript but after all the talk at I/O about 
 sticking to standards and reducing the amount of necessary tooling, 
 whoever 
 thought this was a good idea? I understand that there are a lot of things 
 that speak for Typescript in general but I haven't seen it used anywhere 
 else in the Polymer ecosystem and I don't understand why the team chose to 
 start using it now. I'm not going to list all the reasons why I think this 
 is a bad idea - I think everybody in the team is aware of the drawbacks - 
 but I'd love to hear the reasoning behind this.

 

 Sorry, but I just had to get this out of my system. Really love the 
 work you're doing! Keep it up!

 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/80b27bd8-d3ea-4de1-819c-9f1825084f38%40googlegroups.com
  
 

Re: [polymer-dev] Polymer cli implemented in Typescript? What gives?

['rictic' via Polymer]

I second that. For our node-based tools, the decision to go with typescript 
was very straightforward. Our use of typescript has no impact on anyone 
downstream, whether they use the tools as libraries or as binaries, as by 
the time the code is published in npm it's totally normal, legible, 
commented javascript.

If typescript were to part ways with the standard, then we could migrate 
off of it with minimal effort. It's purely a labor saving device for those 
of us that contribute to the tools repos.

I'm more skeptical than Justin of compile-to-javascript languages, but for 
Typescript the output looks so much like the input that it does not worry 
me or feel like a departure from the platform.

On Tuesday, May 24, 2016 at 12:08:31 PM UTC-7, Justin Fagnani wrote:
>
> Using TypeScript in tool has really helped our development process - from 
> documentation, refactoring, and code-completion, to the type checking and 
> errors that compliments our tests. We've been converting our tools projects 
> to TypeScript for months now, so this is nothing new.
>
> There are extremely few downsides that we've experienced in practice. The 
> TypeScript compiler is so fast that the project is build be the time we 
> switch tabs to run tests or a command. The main outstanding issue is stack 
> traces referencing the compiled output, but this hasn't been much of a 
> hinderance - the output is very similar to the input, and we're going to 
> look into source map support. I'm not aware what other drawbacks might be 
> big issues.
>
> I personally don't think that the "Use the Platform" philosophy is in 
> conflict with TypeScript, or many other compile-to-JS languages for that 
> matter - in node or the web. For tools, we don't run some huge abstraction 
> over node's processing model, or it's core libraries. On the web, all of 
> the critical platform features are available as with JS: The entire DOM, 
> including Custom Elements, Mutation Observer, Custom Events, Shadow DOM, 
> the CSSOM, and all JS features like classes, Promises, etc. TypeScript 
> doesn't define it's own object model, and always uses JS features directly.
>
> The tools team really needs to maximize it's output, and TypeScript helps 
> us do that while still targeting Node, which our customers appreciate. so 
> there's no reservations from us here. In fact, we grow happier with the 
> decision every day.
>
> Cheers,
>   Justin
>
>
> On Tue, May 24, 2016 at 11:10 AM, Daniel Llewellyn  > wrote:
>
>> Personally, I am a bit ambivalent towards Typescript.
>>
>> On one hand I like the types system helping me during development; but on 
>> the other, like you, I like to use the language of the platform natively to 
>> prevent weirdness in machine-written code that is less understandable to a 
>> human reader. The IO mentions of using the platform rather than 
>> abstractions also points towards not using Typescript.
>>
>> Sent from Nylas N1 , the extensible, open 
>> source mail client.
>> On May 24 2016, at 7:06 pm, mar...@maklesoft.com  wrote: 
>>
>>> I mean nothing against Typescript but after all the talk at I/O about 
>>> sticking to standards and reducing the amount of necessary tooling, whoever 
>>> thought this was a good idea? I understand that there are a lot of things 
>>> that speak for Typescript in general but I haven't seen it used anywhere 
>>> else in the Polymer ecosystem and I don't understand why the team chose to 
>>> start using it now. I'm not going to list all the reasons why I think this 
>>> is a bad idea - I think everybody in the team is aware of the drawbacks - 
>>> but I'd love to hear the reasoning behind this.
>>>
>>> 
>>>
>>> Sorry, but I just had to get this out of my system. Really love the work 
>>> you're doing! Keep it up!
>>>
>>> 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/80b27bd8-d3ea-4de1-819c-9f1825084f38%40googlegroups.com
>>>  
>>> 
>>> .
>>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/polymer-dev/82rafzmqajtm5etkxzvm9okdi-0%40mailer.nylas.com
>>  
>> 

Re: [polymer-dev] Polymer cli implemented in Typescript? What gives?

['Justin Fagnani' via Polymer]

Using TypeScript in tool has really helped our development process - from
documentation, refactoring, and code-completion, to the type checking and
errors that compliments our tests. We've been converting our tools projects
to TypeScript for months now, so this is nothing new.

There are extremely few downsides that we've experienced in practice. The
TypeScript compiler is so fast that the project is build be the time we
switch tabs to run tests or a command. The main outstanding issue is stack
traces referencing the compiled output, but this hasn't been much of a
hinderance - the output is very similar to the input, and we're going to
look into source map support. I'm not aware what other drawbacks might be
big issues.

I personally don't think that the "Use the Platform" philosophy is in
conflict with TypeScript, or many other compile-to-JS languages for that
matter - in node or the web. For tools, we don't run some huge abstraction
over node's processing model, or it's core libraries. On the web, all of
the critical platform features are available as with JS: The entire DOM,
including Custom Elements, Mutation Observer, Custom Events, Shadow DOM,
the CSSOM, and all JS features like classes, Promises, etc. TypeScript
doesn't define it's own object model, and always uses JS features directly.

The tools team really needs to maximize it's output, and TypeScript helps
us do that while still targeting Node, which our customers appreciate. so
there's no reservations from us here. In fact, we grow happier with the
decision every day.

Cheers,
  Justin


On Tue, May 24, 2016 at 11:10 AM, Daniel Llewellyn 
wrote:

> Personally, I am a bit ambivalent towards Typescript.
>
> On one hand I like the types system helping me during development; but on
> the other, like you, I like to use the language of the platform natively to
> prevent weirdness in machine-written code that is less understandable to a
> human reader. The IO mentions of using the platform rather than
> abstractions also points towards not using Typescript.
>
> Sent from Nylas N1 , the extensible, open
> source mail client.
> On May 24 2016, at 7:06 pm, mar...@maklesoft.com wrote:
>
>> I mean nothing against Typescript but after all the talk at I/O about
>> sticking to standards and reducing the amount of necessary tooling, whoever
>> thought this was a good idea? I understand that there are a lot of things
>> that speak for Typescript in general but I haven't seen it used anywhere
>> else in the Polymer ecosystem and I don't understand why the team chose to
>> start using it now. I'm not going to list all the reasons why I think this
>> is a bad idea - I think everybody in the team is aware of the drawbacks -
>> but I'd love to hear the reasoning behind this.
>>
>> 
>>
>> Sorry, but I just had to get this out of my system. Really love the work
>> you're doing! Keep it up!
>>
>> 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/80b27bd8-d3ea-4de1-819c-9f1825084f38%40googlegroups.com
>> 
>> .
>> 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/82rafzmqajtm5etkxzvm9okdi-0%40mailer.nylas.com
> 
> .
>
> 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/CAEKsHmDP%2BfdHEr1Q3m8QcCguBfrodi%2Bwm%2Be0T1V5PPKkXaOsAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [polymer-dev] Polymer cli implemented in Typescript? What gives?

[Daniel Llewellyn]

Personally, I am a bit ambivalent towards Typescript.

  

On one hand I like the types system helping me during development; but on the
other, like you, I like to use the language of the platform natively to
prevent weirdness in machine-written code that is less understandable to a
human reader. The IO mentions of using the platform rather than abstractions
also points towards not using Typescript.  
  
Sent from [Nylas N1](https://nylas.com/n1?ref=n1), the extensible, open source
mail client.  

![](https://link.nylas.com/open/5nposllwbhi4nz5zmeksi4tyt/local-a01bf058-9da9)

On May 24 2016, at 7:06 pm, mar...@maklesoft.com wrote:  

> I mean nothing against Typescript but after all the talk at I/O about
sticking to standards and reducing the amount of necessary tooling, whoever
thought this was a good idea? I understand that there are a lot of things that
speak for Typescript in general but I haven't seen it used anywhere else in
the Polymer ecosystem and I don't understand why the team chose to start using
it now. I'm not going to list all the reasons why I think this is a bad idea -
I think everybody in the team is aware of the drawbacks - but I'd love to hear
the reasoning behind this.

>

>  

>

> /rant

>

>  

>

> Sorry, but I just had to get this out of my system. Really love the work
you're doing! Keep it up!

>

> 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](mailto:polymer-
dev+unsubscr...@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid
/polymer-dev/80b27bd8-d3ea-4de1-819c-
9f1825084f38%40googlegroups.com](https://groups.google.com/d/msgid/polymer-
dev/80b27bd8-d3ea-4de1-819c-
9f1825084f38%40googlegroups.com?utm_medium=email_source=footer).  
For more options, visit .  

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/82rafzmqajtm5etkxzvm9okdi-0%40mailer.nylas.com.
For more options, visit https://groups.google.com/d/optout.

[polymer-dev] Polymer cli implemented in Typescript? What gives?

[martin]

I mean nothing against Typescript but after all the talk at I/O about 
sticking to standards and reducing the amount of necessary tooling, whoever 
thought this was a good idea? I understand that there are a lot of things 
that speak for Typescript in general but I haven't seen it used anywhere 
else in the Polymer ecosystem and I don't understand why the team chose to 
start using it now. I'm not going to list all the reasons why I think this 
is a bad idea - I think everybody in the team is aware of the drawbacks - 
but I'd love to hear the reasoning behind this.



Sorry, but I just had to get this out of my system. Really love the work 
you're doing! Keep it up!

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/80b27bd8-d3ea-4de1-819c-9f1825084f38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.