Dev►Babylon.js

Why we decided to move from plain JavaScript to TypeScript for Babylon.js

One year ago when we decided to sacrifice all of our spare time to create Babylon.js we had a really interesting discussion about using TypeScript as main development language.

At that time, TypeScript was not robust enough (even if we did some experiments) so we decided to use plain JavaScript language. But I am really excited to announce that we started the port of Babylon.js to TypeScript this weekend!

Before going further, here are some numbers you may need to correctly understand my explanations. Indeed Babylon.js is:

  • clip_image002An average of 1 version per month
  • 21 contributors
  • 32 releases
  • 365 commits (one per day!)
  • 14000+ lines of code
  • More than 120 files of code
  • More than 200 forks
  • A bandwidth of 1TB per month for the website
  • All my spare time (I cannot even remember the last time I went to see a movie)
  • 1.3GB (Code and samples)

Let me explain you what the main reasons for this decision are.

You want to discuss about this article: reach me on Twitter: @deltakosh

Because it is transparent for users

TypeScript is a language that generates plain JavaScript files. The code produced follows all the JavaScript rules (the “good parts”) and thus is clean and modular (one file per class). You can export namespaces (modules) and to be honest most of the time the produced JavaScript is fairly the same as what we can do.

Developers that use Babylon.js will not be able to see the difference between previous version developed with JavaScript and new version developed using TypeScript.

Furthermore, we can reach more users who can be afraid by JavaScript. TypeScript is for instance a good way for C#, Java and all strong typed languages developers to start developing for the web.

Because Babylon.js is an open-source project

You may consider this one as a counter-example. It could be considered as a blocker for many JavaScript developers that may want to contribute to Babylon.js. But remember that TypeScript supports JavaScript directly so nothing prevents you to fix or submit a feature in JavaScript. It will be our job then to educate developers to try to have less contributions in JavaScript and more in TypeScript.

And here why:

  • Using TypeScript, we benefit from the power of static compilation and this helps A LOT. We can easily find wrong parameters, wrong names, typos and all kind of syntax errors thanks to TypeScript
  • Integrating a pull-request is a hard task because you must guarantee that a code you did not produce nor manage will not break things. With TypeScript it is easier thanks to static compilation
  • Reading and understanding TypeScript code is easier because parameters and functions are typed, so you know what kind of parameters you should pass to a function for instance.

The funny thing is that during the port to TypeScript I even found a bug into my own code. It was in the collisions engine code where I do a lot of computations. The bug was hidden there:

clip_image003

Nothing remarkable, especially when there are tons of other lines like this.

When I moved to TypeScript this code remains the same but thanks to strong typing and static compilation here is what I got:

clip_image004

This is a common mistake in JavaScript: using a property instead of a function. It is a hard to find and easy to fix bug! TypeScript detected it instantaneously because it knew that _this.tempVector was a Vector3 and did not have a lengthSquared property.

Because TypeScript is an open source project

Our users are not all on Windows and they are not all using Visual Studio (so sad Smile) so moving from JavaScript to TypeScript would not have been possible if these users were not able to contribute if they want.

But no worries, TypeScript has us covered! First of all you can find all the source code here:

https://TypeScript.codeplex.com/

Then, TypeScript can run under:

You also have to know that everything using classes/packages/modules compiles to RequireJS and CommonJS.

Because tooling is awesome when working with a modern IDE

TypeScript works extremely well with Sublime Text, Eclipse and almost all major IDEs. On our side we are using Visual Studio and to be honest, the experience is really great.

Indeed, using Visual Studio 2013, you will have:

  • Integrated TypeScript file support
  • Syntax color
  • Intellisense:

clip_image005

  • Discoverability: With intellisense and strong typing, you have a kind of API documentation just under your mouse
  • Refactoring support
  • Integrated class browser (I LOVE this one):

clip_image007

I also use Resharper (www.jetbrains.com) as a plugin into Visual Studio. And with this tool you can get some goodness like for instance auto refactoring for lambda expressions:

Here is my initial code:

clip_image008

Can you see the green line? If I right-click on it, I have an option to convert my function to a lambda expression:

clip_image009

No more “that = this” stuff! (With just one mouse click)

  • The debug experience is also great because you can put a breakpoint into your TypeScript code! Visual Studio will handle the link between .ts and .js files for you:

clip_image011

Because TypeScript is handy

We have just seen the lambda expression (An elegant way to get rid of closures). And there are tons of other wonderful stuff like this one in TypeScript. For instance, here how to handle inheritance:

clip_image012

Here my Camera class inherits from Node class. Nothing more to do! Obviously you can call parent’s function within child’s code:

clip_image013

How can it be simpler?

The generated code handles for you all the burden of inheritance with prototyping:

clip_image014

Using TypeScript, you have all the power of a strong typed language but you can code in normal JavaScript at any time because TypeScript is optional: you can mix and match.

Because of the future

The real power of TypeScript is its compilation. At the end of the day the goal is to produce JavaScript. Thanks to the compilation you can add new options to generated files without changing a line of your code.

For instance according to TypeScript’s roadmap, the async/await language feature from C# is under exploration. This means that perhaps one day, we will not have to struggle with callback/promises/handling exceptions in an asynchronous flow.

Obviously the generated code will have to do that but as a developer you will just have a clear vision of your code.

Let’s look at this standard JavaScript code:

clip_image015

Now imagine you can do that!

clip_image016

Lovely, right?

And this is the same thing for ECMAScript 6 current and upcoming features!

Call to action

We have just started porting our code so it is a bit too early for a post-mortem but I will write an article in two or three months about how things will have gone our 3D engine written using TypeScript.

In the meantime, if you want to learn more about TypeScript here are some useful pointers:

And obviously, I urge you to think about doing the same thing if you have open source projects that use JavaScript!