Skip to main content

Angular AtScript

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…
Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more