Category Archives: ECMAScript

TypeScript and ES2016 Decorators vs. Java Annotations

Consider this TypeScript snippet. It’s a very simple Angular2 component. It looks almost like a Java class, doesn’t it?

    selector: 'my-app',
    template: '<h1>My First Angular 2 App</h1>'
export class AppComponent { }

In particular, the @Component looks like a Java annotation. In fact, it plays the some role as a Java annotation. It tells the Angular2 framework that this class is not an ordinary POJO, but something special. It’s a component, one of the building blocks of Angular.

Striking similarity

That’s exactly the same thing I already knew from the Java world. @Named converts a POJO into a CDI bean. Sometimes Java annotations even have the same fancy curly braces syntax:

  @ResourceDependency(library = "bsf", name = "js/datatables.min.js", target = "body"),
  @ResourceDependency(library = "bsf", name = "css/datatables.min.css", target = "head")
public class DataTable extends UIData {}

So why do the JavaScript and TypeScript communities insist on calling their annotations “decorators”?

Decorators decorate!

The answer is simple: Decorators are called decorators because that’s what they are. You can use them as annotations. But in reality, they are function calls. The Angular2 framework contains a function called Component() that takes a function as a parameter and returns another function. The @ of @Component tells TypeScript and EcmaScript 2016 to call the Component() function and to pass it the function after the decorator. Usually decorators are used to add functionality to a function.


Does this ring a bell? Exactly – that’s more or less the same as aspect oriented programming. In fact, AOP is one of the classical use cases of Java annotations. Just think of @transactional. This annotation surrounds a method with the glue code needed to execute it in a transaction. In other words, it adds some code before executing the method (opening a transaction) and it adds code after the method (committing the transaction, or rolling it back).


Making the @ symbol an alternative way to call functions is a very elegant way to implement both static annotations and AOP. Plus, it should be possible to pass variables as additional parameters. In Java, annotations only support constants that can be resolved a compile time, and every once in a while, that’s a nuisance.

In hindsight, it’s hard to understand why the Java team added simple annotations instead of full-blown decorators to Java 5. I suppose they didn’t want to add a complex multi-purpose tool. Annotations can be used for exactly one purpose. They resemble a comment. They rely on a framework to be useful. This framework can be the editor, the compiler or the runtime environment. Only a few years later the JavaScript world showed how useful decorators are.

Can decorators be added to Java?

Sure. Java 8 introduced default methods. So we could define a default method in an annotation class and execute it when the annotated method is called. We’d have to consider a couple of corner cases, though. Annotations can be applied to classes, static fields, class attributes and method parameters. We’d have to define useful semantics for each of these corner cases. But that’s not a big deal.

Wrapping it up

However, I don’t think this will ever happen. Annotations have become such an important part of the Java world it’s unlikely anybody takes the risk. So, for now, we can only marvel at the way the language designers took the syntax of the annotation and converted it into something even more useful. By the way, the flexibility of the JavaScript language allows for some tricks Java developers can only dream of. Only – Java applications tend to be a lot bigger than JavaScript applications, so this dreams would quickly turn into a nightmare. Nonetheless, the article I’ve linked in the “dig deeper” section is very interesting, and it’s full of surprises – at least for a programmer like me spending most of their day in the Java ecosystem.

Dig deeper

Exploring EcmaScript 2016 decorators in detail

What is AngularJS 2.0 Going to Look Like?

At last week’s ng-conference in Paris the AngularJS team gave us an early impression of how AngularJS 2.0 is going to look like.

Maybe you remember me writing in an earlier article that AngularDart is a preview on AngularJS 2.0. It wasn’t my own claim. I found it at the AngularDart web site. When I was jotting it down I couldn’t help but wonder how this might be done. AngularDart benefits largely from classes, annotations and an optional type system. This can’t be ported to Javascript, I thought?
Continue reading

Angular 2.0: Courageous Plans

This morning the AngularJS team published their plans on AngularJS 2.0. Among lots of minor and major improvements there are two courageous ideas: AngularJS 2.0 is written in a new language developed for AngularJS, AtScript, which is sort of a superset of ECMAScript 6 and TypeScript. Plus, they are dropping support for older browsers. The only browsers to be supported are evergreen browsers, i.e. browsers that update themselves automatically. This might be a dangerous decision: many companies are very reluctant to update their browsers.

Update Nov 02,2014: AngularJS 2.0 at ngEurope

Since I wrote the original version of this article, the AngularJS team revealed more informations about the coming Angular and AtScript. See What is AngularJS 2.0 going to look like? and sneak preview on data binding (and both article contain links to the AngularJS design documents). The plans raised a controversial debate among AngularJS programmers. The nice thing is the AngularJS team listens to the feedback and is looking for a better approach.
Continue reading

What About TypeScript? A Java Programmers Perspective

Is it a déjà-vu, or did I accidentally enter a time machine this morning? A couple of minutes ago I saw a video introducing two brand new features: Intellisense (aka auto-completion) and refactoring. It wasn’t even a particularly fancy refactoring – just “rename variable”.

And it felt just great!

Believe it or not, even in 2014 there’s still a wide range of popular programming languages that simply aren’t suited for autocompletion, let alone complex refactorings. One of them isn’t merely popular, it’s ubiquitous: Javascript.

So today I’m going to introduce you to TypeScript, a language trying to adress some of the issue of current Javascript while trying to keep the spirit of the language alive.

Continue reading

JAX Conference 2013 Roundup

During the last years the annual JAX conference served as a good gauge for the trends and hypes of the Java world. This year’s JAX conference felt almost boring by this measure. As far as I can see, most of the conference was about evolution. If there was any revolution I missed it. Maybe it was hiding in the dark, but the conference generally felt a lot like steady but constant progress. Actually, consolidation’s not a bad thing – apart from that it’s boring to write a blog article about it :).

Nonetheless there were a few exciting topics: the renewed GUI battle, the arrival of the mobile platforms as major players in the Java word and the sobering after getting drunk with agile programming. As for languages, Javascript was by far the language most talked about (second to Java, of course). To my disappointment most of the other languages were hardly mentioned.

Continue reading

Java 8 – Catalyst for a Superior Language?

These days I’ve read two language-related stories at Lavalobby. The first story I read matched my own experience on the topic. It has also an refreshingly optimistic air. Obviously, the author believes in progress. The second article also had a lot of ideas matching my experience.

Thing is, both articles contradict each other.

While the first article expects Java 8 to be merely a catalyst giving rise to more innovative languages, the second article insists that Java is here to stay. It the programming world’s lingua franca, and it won’t be replaced by a fancy new language.

Both articles have a point.
Continue reading

Overview of ECMAScript 5 (aka modern Javascript)

As you probably know, Javascript used to be an an underdog among programming languages. But chances are you also may know by now it’s an interesting full-blown language of its own. It isn’t object oriented the way Java is. Or rather, it doesn’t know classes; all it knows is objects. You can add methods and fields to objects, and you can use objects as prototypes to create other objects. This makes Javascript program look very alien to Java programmers, but you shouldn’t mind: ECMAScript may take a slightly different approach than Java does, but at the end of the day it is just as powerful.

These days, OIO’s blog gave an interesting overview of the new features of ECMAScript 5.
Continue reading