atScript support

[ocombe]

It would be awesome if 6to5 could support atScript. I know that it is not valid ES6, and not even valid ES7 (if there is such a thing) but we should be able to use 6to5 to compile it.

Why should you support atScript ?
Because you will need atScript for Angular 2. The google team uses Traceur (because it's their own compiler and they can do what ever they want with it), but when ng2 comes out, all angular devs will switch to Traceur because they won't have a choice.
Angular is the JS framework with the biggest dev base on the market (more than a million I think). They won't all switch to ng2 of course, but a lot will. When they do they will use Traceur.
Angular 2 will also be the first framework on the market using ES6+ (or maybe durendal will be the first if they manage to release it before ng2). A lot of people who haven't ever looked at ES6 will jump in with it. They should have the choice to use 6to5 because this project is awesome!

I would rather use 6to5 than Traceur because it's easier to use, the plugins are up to date, the code is readable and the project is really active.

What do you need to support?

• .ats files
• Type annotations: flow types are already supported by 6to5 and pretty similar to atScript types
• Field annotations
• Metadata annotations
• Runtime type assertions for type introspection: not sure if that's really a necessity, it would probably only be for test environment anyway

You will probably be better at finding out the requirements, this is just a small list according to the atScript proposal.

Links:

• atScript proposal
• atScript playground

[sebmck]

All the type examples on that page parse fine with flow type support. The automatic runtime assertions are similar to what has been requested/discussed in #458. The only thing that would have be supported would be meta-data annotations and fields. I think that if they can be implemented in 6to5 in an agnostic way then it might be acceptable, meaning that out of the box they'll parse but 6to5 will do nothing about them and you'll have to use a --optional angular option or something.

I just need to work out if this is the path that we actually want to take because right now 6to5 supports JSX/Flow out of the box so the Facebook tool workflow is basically fully supported (open to suggestions to improve that). Supporting another ecosystem may prove to be more challenging as it means that it has to be extremely solid and maintained.

[ocombe]

Maybe some kind of option (such as --optional angular as you suggested) would turn on some modules (atScript things) and turn off others (JSX/flow).
If you had a way to enable/disable features and only pipe those needed that would work?

[stefanpenner]

Angular is the JS framework with the biggest dev base on the market (more than a million I think).

Curious if their is any actual info to validate this fact.

Also, I am curious as to the stability of atscript, is it still in flux, or has it settled nicely.

[timoxley]

opinion: I worry about scope-creep creating a maintenance nightmare for 6to5 if it keeps bloating with additional flags for non-standard features. This kind of thing should be implemented by third party transforms so the people motivated to maintain these features can maintain them rather than offloading maintenance to you.

An ecosystem of 3rd party transforms would be very healthy.

[monsanto]

My opinion:

Angular 1 was a full stack framework. Angular 2 sounds like it will be even more "full stack", by involving a blessed language in the mix. I am guessing Traceur will be part of the blessed Angular experience as well.

Angular also has a very close relationship to Dart--one of the primary reasons AtScript exists at all is so
the Angular team could have a language that compiles to both ES6 and Dart. If AtScript grows more Dart capabilities, is 6to5 going to be responsible for supporting those as well? What if they end up becoming part of the blessed Angular Way? Then people using 6to5 will be stuck, especially if they use other features that Traceur does not support.

There's no point in involving ourselves in this. The point of full-stack solutions like Angular is that you don't have to mix and match all the pieces. If you want to get the full Angular Experience™, use the transpiler in the Angular stack: Traceur.

[ocombe]

I agree with @timoxley that it should not be part of the main 6to5 install, it should be an optional package. But I don't have the skills nor the time to implement this and if @sebmck can do it, that would be awesome.
I like the way @sebmck goes with the project scope, this might be the best of both worlds. Let's see how this evolves, I can live with Traceur for a while until you get the time to refractor the project.

[cesarandreu]

+1 to what @timoxley and @monsanto said.

[sebmck]

@cesarandreu See #568

[sparty02]

Angular should be left out of this as AtScript is a viable experimental ES extension, regardless of whether Angular uses it or not.... we don't need more framework flame wars. I think this issue may tie into topics like #584 . Ideally in the future (#568), JSX may move out of the core an into a pluggable transform too?

[sebmck]

@sparty02 With #568 I'm not proposing moving anything out of the core. I'm not turning 6to5 into a build your own transpiler because that's bad for users. As per #568 the plan is to make 6to5 a more general JavaScript transpiler/transformation tool so supporting AtScript definently isn't out of scope.

[sparty02]

@sebmck Do you have any recommendations/suggestions for somebody that wants to write a new transform (e.g. if somebody wanted to toy with implementing the AtScript transformer)?

[sebmck]

@sparty02 It's currently not possible. I'm currently evaluating the possibility of a pluggable parser although I'm starting to doubt it's practicality.

[sebmck]

What are the compelling AtScript features that require it to be used?

[sparty02]

@sebmck Metadata annotations. See here with arguably better examples here (also showing the non-Angular relevance). I believe @EisenbergEffect has some perspective on this too (via Aurelia)

[sebmck]

Decorators/annotations aren't really an exclusive atScript thing though.

[sebmck]

Definently interested in adding support for decorators/annotations but atScript support can't really be added. Closing this for now.

[EisenbergEffect]

Here's the deal....AtScript's annotations are probably never going to be part of the standard. As far as I know, they haven't even tried to bring them forward for discussion. Furthermore Tracuer doesn't even follow the AtScript spec right now.

As far as Aurelia goes, we leverage some metadata, but it's completely abstracted away so that we can "turn on" support for AtScript (Tracuer or actual spec) if someone wants that. But ultimately, we want this because we are future-proofing ourselves for what we want to do with decorators as soon as they are available.

Ultimately, I hope we'll see decorators in ES7 and hopefully we can get them in 6to5 sooner than later, but that depends on how quickly the decorators spec stabilizes. There is good progress being made on that though.

[sparty02]

I think the term 'annotation' is way overloaded in this context. @sebmck , what kind of annotation support from AtScript are you open to?

(i.e. Metadata annotations via '@', type annotations via : type)

@MetaAnnotation
class MyClass {
    constructor(name: string)
}

Also, regarding decorators, where is a good reference for this? All I could dig up was this rough 'dialog'

[sebmck]

@sparty02 Metadata annotations. There's currently a proposal spec being written up for decorators so there's not much in terms of reading material.

[truongsinh]

"here's the deal": http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx

[EisenbergEffect]

@truongsinh That's not actually the whole story. I don't want to share it all publicly. Suffice it to say...Angular 2.0 is not currently built with TypeScript. It's still built with AtScript. They hope to port it over to TypeScript...and they hope it will only take them a month or so. Misko stated this much in the Q&A. They don't know how long it will actually take since they have to port their entire Dart compilation infrastructure away from Tracuer and over to the TypeScript compiler APIs.

Regardless, what is important to know is that AtScript's annotations are not going into TypeScript or into ES 2016. Rather, an alternative is being proposed: Decorators. Initial work was started on this by Yehuda Katz. I joined him for some light prototyping. The TypeScript team then worked on a more formal spec along with a prototype. After that, the TS team tried convincing the Angular team to adopt it and leave their annotations stuff behind. Looks like they agreed. They are still using the "annotations" terminology, but what they are actually talking about is Decorators. Annotations was never proposed to ECMA.

[ocombe]

The good news is: @sebmck didn't start working on this for nothing :)

[EisenbergEffect]

@ocombe I sent @sebmck the Decorators spec a little while back. I think it has evolved a bit since then, but hopefully it won't take long to implement. Both Aurelia and Ember are building on Babel and both are interested in Decorators. I'm really very excited to build with it as soon as possible. Having the Angular team agree to go along with it and a TS prototype helps tremendously.

[ocombe]

It's always good news when the major frameworks agree on something, it won't take long before it becomes an official spec :)

[truongsinh]

@EisenbergEffect thank you for sharing the story. It gets my mind rid of "Atscript annotation", because Babel already has "type annotation" (which, i believe what function(param1: string): int is).

Anyway, should this issue be either closed (because AtScript is no longer alive or relevant), renamed to Angular2 (because that's the author rationale), or deprecated by some other issues specific to the TypeScript 1.5 (say, #974) but solves the author's (and my) rationale ?

[bradlygreen]

The concerns of AtScript are now in TypeScript 1.5. We will be recommending Babel as an option to Angular 2 developers and would love to recommend as a full option supporting types as well if that happens.

[truongsinh]

@bradlygreen talking of "injection-by-type", we made a fork of "ng-annotate" to suit ourselves in the meantime https://github.com/Smarp/ng-annotate

[gionkunz]

I think the guys in the type script repo also made a proposal for decorators / meta annotations for ES7 microsoft/TypeScript#1557 that was also discussed at TC39 https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-04/apr-10.md#decorators-for-es7 . However, I don't think they came close to any conclusion about syntax and how to desugar everything. I personally prefer the Annotation (similar to Java annotations) with @ sign and would be more than happy if TypeScript implements this in the near future. Also I hope ECMAScript are going into this direction. Syntactic metadata is really useful to build Frameworks and makes applications very maintainable by the declarative nature. I'd really love to use Babel to compile my Angular2 code, but at the moment it's not very clear where this is going? Clear is after all this media noise about a Angular / Google and Microsoft joint venture they need to come up with something soon :-)

I'll also give this a go: https://github.com/shuhei/babel-angular2-app

[sebmck]

@gionkunz This is the current decorators proposal that is currently at stage 1 and is currently already implemented in Babel. TypeScript however have also implemented parameter decorators which I consider extremely dangerous from a standards perspective.

[ocombe]

Yes, the repository by @shuhei works fine with babel :)

[gionkunz]

@sebmck great to see that babel is already that far. Is this already tagged in a version? The thing I'm concerned about is that currently, as far as I understood, AtScript / Traceur in AtScript mode is desugaring very differently for example:

@TestAnnotation({
  name: 'My Test'
})
class Test {}

gets desugared to ES6 something like:

class Test {}
Object.defineProperty(Test, 'annotations', { 
  get: function() {
    return [
      new TestAnnotation({
        name: 'My Test'
      })
    ];
  }
});

I prefer the https://github.com/wycats/javascript-decorators proposal much more than the AtScript desugaring, as it's up to the annotation developer how the annotation is influencing the target.

However, I'm currently looking for the best way to use Angular2 without the need to rely on Traceur and this is probably not as easy using the current Babel implementation.

[sebmck]

@gionkunz

great to see that babel is already that far. Is this already tagged in a version?

It's available in 5.x and behind experimental mode, with the stage 1 flag to be more specific:

$ babel script.js --stage 1

require("babel-core").transform("code", { stage: 1 });

The thing I'm concerned about is that currently, as far as I understood, AtScript / Traceur in AtScript mode is desugaring very differently for example:

AtScript/Traceur are just going to be the ones who're screwed when their implementation is fundamentally incompatible with eventual ECMAScript semantics.

[ocombe]

AtScript & Traceur will be deprecated soon, they are switching to typescript anyway

[sebmck]

TypeScript are still implementing a feature (parameter decorators) that has not been discussed for official inclusion in ES and with syntax that is likely going to be used in the future. It's incredibly dangerous and irresponsible.

[okunokentaro]

👍