Polymer cli implemented in Typescript? What gives?

[mar...@maklesoft.com]

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!

[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, the extensible, open source mail client.

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.

[Justin Fagnani]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/82rafzmqajtm5etkxzvm9okdi-0%40mailer.nylas.com.

[rictic]

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.

[mar...@maklesoft.com]

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.

[AJ Ortega]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f7ef6540-6973-4be9-94d5-201b384298d4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

AJ Ortega | Software Engineer | a...@google.com | 626-872-5064 

[Peter Burns]

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

You received this message because you are subscribed to a topic in the Google Groups "Polymer" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/polymer-dev/BEgD4qx1vto/unsubscribe.
To unsubscribe from this group and all its topics, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAKf8-xgtnm%3DU2ftTg5t04Q_vbZmN0Z36mSJb7f7hCZZgBz3SWQ%40mail.gmail.com.