Peter Morlion logo


ngEurope: AtScript

The second day of ngEurope started with… the keynote. A bit strange, but whatever. Misko Hevery gave a good explanation of the future of javascript, and how it’s coming to us early with AtScript.

First, he stressed they were not building a new language. But the fact is that the current state of javascript makes it hard to develop complex applications and frameworks (hence the invention of TypeScript). Misko gave the specific example of a complex directive (check out this slide, with two ways of injecting dependencies), but large codebases in javascript are hard in general.
Building a new language might be tempting, but you could make a whole new set of mistakes, people would have to learn something new,… The XKCD comic on standards was in one of the slides:

Types are contracts between developers, ways of communicating intent and capabilities. Especially on large projects and large teams. Ideally, we would have optional types. Optional, because the existing code should keep working, and in javascript, there are no types.

Misko also mentioned annotations and introspection.

Annotations can communicate intentions by specifying the type of a field or parameter.

These annotations are available at runtime and this is where introspection comes into play.

And that is what AtScript is: optional types, annotations and introspection.

It is a run-time type system. This means that types are checked at runtime. Your code is compiled to assertions (for example, asserting that a parameter is of a certain type). AtScript can handle

  • nominal assertions (i.e. it’s an array)
  • structural assertions (i.e. a given string matches a certain regex)
  • generics
    An example Misko mentioned, is that this means it’s possible to check the server JSON response for the correct type.

He ended with an overview of the past, present and future of javascript. These two slides should clarify it better than I can type in words. The nice thing is that AtScript code is valid TypeScript code. This means the step to solid IDE support should be smaller too. They are already talking to IDE vendors.

The next steps are static type checking, alignment with TypeScript, an ECMAScript proposal, browser support and finally an ECMA standard.

I don’t expect to use this in the near future, but it is nice to know what’s coming.

Check out all the slides here.

Leave a Reply

Your email address will not be published. Required fields are marked *