I heard some colleagues discuss if Angular.js will ever be written using TypeScript. The answer is no. In fact, the Angular.js team is using their own language AtScript to build Angular 2.0. The goal of AtScript is similar to the goal of TypeScript, it enhances the JavaScript language with some missing features without infringing upon its current capabilities.
Here are some of the enhancements and the philosophy behind the language from the Angular.js team design documents:
Enhancements
Type Annotations: Types allow us to explicitly express contracts between different parts of the system and to give these contracts names. For large teams with large codebases, where no single person knows the whole codebase, types become a key way to discuss and reason about the collaboration between different components of the system.
Field Annotations: Types are not only about contracts (API) but also about structure. In JavaScript the fields are implicit; they are created as a side effect of assignment. By giving the developer syntax to explicitly declare the fields, and warning upon implicit creation, we allow them to think about types in a more concrete way. By doing this we in no way sacrifice the flexibility of adding fields dynamically. We simply provide an optional tool to developers who can benefit from being more explicit.
Metadata Annotations: Many things in programming are best expressed in a declarative fashion. Declarative annotations allow frameworks to understand the meaning of your code without forcing a complex inheritance or lifecycle API. Examples where this technique has been used in the past include dependency injection libraries and web frameworks.
Type Introspection with Annotation Support: When we have annotations, it’s important to provide a consistent API that developers and frameworks can leverage to gain access to this information at runtime. The reflection API should also be backwards compatible with ES5 and ES6.
Philosophy
ES6 Baseline: ES6, or ECMAScript 6, is the latest version of the Ecma International language popularly know as JavaScript. It includes many improvements such as a formal class declaration syntax, promises, modules and consistent variable scoping.
Backwards Compatibility: Types, fields, metadata annotations and reflective access need to be added in a way which does not break the existing syntax or semantics of ES6/ES5. AtScript needs to be a more succinct way of expressing what is already possible in these languages. ES6/ES5 code must be valid AtScript code without any changes to the semantics. Any developer who has written ES6/ES5 code can immediately get started with AtScript. In other words, ES6/ES5 are strict subsets of AtScript. All the code you are used to writing today will work without alteration with AtScript, but now you can take advantage of the enhancements to the language which will allow you to express your ideas in a more concrete way.
Familiar Syntax: We desire to use a syntax which has been tried, is time tested and is most likely to become the next standard. This means using ':' to indicate type annotations (proposed in ES4 and used by TypeScript), '@' for metadata annotations (used by java, dart and others) and 'name:Type;' for field annotations (used by java, dart, TypeScript and others).
Pragmatic Approach: The goal is not to build a type system that is correct 100% of the time. Rather, we want to be flexible and useful in the vast majority of real-world scenarios.
Semantics Agnostic: Type system theory is a complex field with many tradeoffs. It is our explicit goal to leave the semantic discussion as well as the assertion system outside of the scope of AtScript. Instead we want to provide hooks for others to build runtime type assertion libraries and static analyzer tools with their own semantics. In this way we believe that we can spur innovation in the area of type systems by lowering the barrier to entry.
The Angular.js team was certainly inspired by TypeScript but they choose a different path:
The AtScript has been influenced by TypeScript and Dart. Here we would like to discuss why these existing solutions do not meet our needs.
TypeScript
Types are analyzed statically only.
Static analysis makes it difficult to have optional types, since static analysis can not analyze what is not typed. (type inference has its limits)
Static analysis can not be used to assert that the JSON returned from the server has valid structure.
Lacks meta-data annotations
Provides no mechanism to access the annotations at runtime
Dart
Dart is semantically different from JavaScript. The resulting Dart2JS code uses JS as more of a VM than a language. The result is that Dart2JS code can not easily interoperate with JS code. Only primitive types (such as strings, numbers, arrays, maps) can be passed between Dart and JS. Complex things such as classes can not be marshaled easily.
Existing JavaScript libraries can not be used from Dart in a straightforward way. Limiting reuse of prior art.
As a frequent TypeScript and Angular.js user, I see what benefits AtScript brings to the table. One thing is certain, the Angular future looks promising…