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] Search JSON Objects on button click base on user input in Polymer

[Karl Tiedt]

This is probably the most polymer your demo can be...

note: I fixed the imports to use polygit and removed your search button
completely

This can probably be more efficient, I needed a distraction from work so I
tweaked things for you ;)

http://plnkr.co/edit/Qzky7tpvGjNXu8Tt77hw?p=preview

-Karl Tiedt

On Fri, May 20, 2016 at 3:35 PM, Buba Bayo  wrote:

> I am pretty new to Polymer and i have this issue where i want users to be
> able to  search through the JSON objects on button click (SEARCH BUTTON)
>  base on the user input and select option and return the message like
> “match found or exist”  if the values enter by the user  exists in the json
> object/array and if not return message that it is "not found”.
>
> Also I want that results to be shown on another page onclick of search
> button.
>
> Here is what i have so far and nothing is returning.
>
>
>  
>   
>   
>https://rawgit.com/Polymer/polymer/v1.2.2/polymer.html; />
>https://elements.polymer-project.org/bower_components/webcomponentsjs/webcomponents-lite.js
> ">
>https://elements.polymer-project.org/bower_components/iron-elements/iron-elements.html
> ">
>http://www.polymer-project.org/1.0/components/paper-input/paper-input.html
> ">
>http://www.polymer-project.org/1.0/components/paper-dropdown-menu/paper-dropdown-menu.html
> ">
>   
>   .taller {
>   height: 120px;
>   }
>
> [vertical-align="top"] ul {
>   margin-top: 0;
> }
>
> [vertical-align="bottom"] ul {
>   margin-bottom: 0;
> }
>
> button,
> paper-button {
>   border: 1px solid #ccc;
>   background-color: #eee;
>   /*padding: 1em;*/
>   border-radius: 3px;
>   cursor: pointer;
> }
>
> button:focus {
>   outline: none;
>   border-color: blue;
> }
>   
> 
>
> 
>   
> 
>   
>   
>   
> Select Department
> Digital Engagement
> Shared Research
> Research
>   
>   
>   Search
>   
>   
>   
> 
>   
>  style="font-size:15px;font-family:'Open Sans'">
>   {{item.name}} - {{item.dept}}
> 
> 
>   
> 
>   
>
>   
>   
>
> 
> 
>   Polymer({
> is: 'employee-list',
> properties: {
>   items: {
> type: Array
>   },
>   Search: {
> type: String
>
>   }
>
> },
> ready: function() {
>   this.items = [{
> 'name': 'Jack',
> 'dept': 'Digital Engagement'
>   }, {
> 'name': 'Buba',
> 'dept': 'Research'
>   }, {
> 'name': 'Kashif',
> 'dept': 'Shared Research'
>   }];
> },
> Search: function() {
>   var searchVal =
> document.getElementById('searchCompany').value,
> i, len, data, prop, matches = [],
> val, items = [];
>   console.log(searchVal);
>   for (i = 0, len = items.length; i < len; i++) {
> data = items[i];
> console.log(data);
> for (prop in data) {
>   if (data.hasOwnProperty(prop)) {
> val = data[prop];
> if (typeof val !== 'undefined' && val.toLowerCase &&
> val.toLowerCase().indexOf(searchVal) >= 0) {
>   // this data matches
>   matches.push(data);
>   break;
> }
>   }
>
> }
> showMatches(matches);
>   }
>
> },
> showMatches: function(matches) {
>   var elem = document.getElementById('result'),
> i, len, content = '';
>   if (typeof matches === 'undefined' || !matches.length) {
> elem.innerHTML = 'No results found';
> return;
>   }
>   for (i = 0, len = matches.length; i < len; i++) {
> content += '
title:' + matches[i].name +
> '
';
>   }
>   elem.innerHTML = content;
> }
>   });
> 
>   
>   
> 
>
> 
>
> Here is the code i have so far:
> http://plnkr.co/edit/9htBMs0ajJis8aSWbMoV?p=preview
>
> Thank you in advance
>
> Follow Polymer on Google+: plus.google.com/107187849809354688692
> ---
> You received this message because you are subscribed to 

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] Managing imports

[Nicolas Ocquidant]

Thank you for the feedback.

Le mardi 24 mai 2016 21:27:01 UTC+2, Justin Fagnani a écrit :
>
>
> On Tue, May 24, 2016 at 12:02 PM, Nicolas Ocquidant  > wrote:
>
>> If I had understood correctly, managing imports in one big html file for 
>> the entire app (for instance elements.html) is not a best practice anymore.
>> Indeed, PRPL and polymer-cli requires each component (or view) to manage 
>> its dependencies.
>>
>
> elements.html was never really a best practice, IMO. It completely 
> bottlenecks the import graph so that you can't tell what depends on what. 
> It's a convenience at first, but then gets harder and harder to maintain. 
> If you stop using an import in one element, it makes it hard to know if you 
> can remove the import from elements.html, or if another element is still 
> using it.
>  
>
>> Unfortunately, IDE are not a great help here. Do you have a tool to check 
>> (or automatically add if no conflict?) that a component declares all 
>> imports for the elements it uses?
>>
>
> `polymer lint --entrypoint x.html` should work most of the time, but we 
> have a few outstanding issues to make it work correctly with lazy-loaded 
> imports and it currently prefers the project configuration to the 
> command-line args.
>
> Cheers,
>   Justin
>
>  
>
>>
>> Thanks a lot
>> --nick  
>>
>> 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/b9f59980-353f-4761-a528-ed99622fd994%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/609bbf13-5f88-4bbe-8ea5-34913ee22bb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [polymer-dev] Managing imports

['Justin Fagnani' via Polymer]

On Tue, May 24, 2016 at 12:02 PM, Nicolas Ocquidant 
wrote:

> If I had understood correctly, managing imports in one big html file for
> the entire app (for instance elements.html) is not a best practice anymore.
> Indeed, PRPL and polymer-cli requires each component (or view) to manage
> its dependencies.
>

elements.html was never really a best practice, IMO. It completely
bottlenecks the import graph so that you can't tell what depends on what.
It's a convenience at first, but then gets harder and harder to maintain.
If you stop using an import in one element, it makes it hard to know if you
can remove the import from elements.html, or if another element is still
using it.


> Unfortunately, IDE are not a great help here. Do you have a tool to check
> (or automatically add if no conflict?) that a component declares all
> imports for the elements it uses?
>

`polymer lint --entrypoint x.html` should work most of the time, but we
have a few outstanding issues to make it work correctly with lazy-loaded
imports and it currently prefers the project configuration to the
command-line args.

Cheers,
  Justin



>
> Thanks a lot
> --nick
>
> 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/b9f59980-353f-4761-a528-ed99622fd994%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/CAEKsHmC%2BNQdYi846VGKXpH757dCArFYugPfZhnWXnQ2ZAU8iJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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.

[polymer-dev] Managing imports

[Nicolas Ocquidant]

If I had understood correctly, managing imports in one big html file for 
the entire app (for instance elements.html) is not a best practice anymore.
Indeed, PRPL and polymer-cli requires each component (or view) to manage 
its dependencies.

Unfortunately, IDE are not a great help here. Do you have a tool to check 
(or automatically add if no conflict?) that a component declares all 
imports for the elements it uses?

Thanks a lot
--nick  

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/b9f59980-353f-4761-a528-ed99622fd994%40googlegroups.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.

Re: [polymer-dev] Polymer build Error: Cannot find module 'gulp'

['Justin Fagnani' via Polymer]

By any chance do you have a gulpfile?

On Tue, May 24, 2016 at 4:08 AM, Marco Stolle 
wrote:

> Hello
>
> i'm trying the new polymer-cli, everything works but when i try to build i
> get the error
>
> Error: Cannot find module 'gulp'
>
>
> gulp is installed global and local
>
>
> gulp --version = 3.9.1
>
>
> searched Google and this forum but no results
>
>
> Any ideas?
>
>
> thanks
>
>
> Marco
>
>
> 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/a0eb12f0-5480-43a7-95fa-643c2dd2711f%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/CAEKsHmA%3D2Rj3KpiNPTVExCRjzx5nJgUsLiab1zkCYkgTnkeP-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[polymer-dev] Polymer build Error: Cannot find module 'gulp'

[Marco Stolle]

Hello

i'm trying the new polymer-cli, everything works but when i try to build i 
get the error

Error: Cannot find module 'gulp'


gulp is installed global and local 


gulp --version = 3.9.1


searched Google and this forum but no results


Any ideas?


thanks


Marco


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/a0eb12f0-5480-43a7-95fa-643c2dd2711f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.