How to make Angular and WebAssembly work together

In this blog post I will explain how you can make an Angular app work with WebAssembly code. This combination of technologies can bring interesting advantages to web development and it is fairly simple to implement.

As I write this post, Angular is currently at version 5.1 and WebAssembly is still in its initial version, but it is making fast progress since Chrome, Edge, Firefox, and WebKit have reached a consensus on the binary format and API (see their roadmap).

Create the Angular App

Let’s start with the Angular app. If you are not familiar with Angular, you should visit its website and read its quick start guide and related documentation. You should be able to easily create a boilerplate app with the ng command (see angular CLI). We can start creating a new project called “ng-wasm”:

ng new ng-wasm

The generated project will have some basic source code and configuration files ready to be used. You should be able to serve the app right away and test it with the following command:

ng serve --open

The app should load on the web browser at http://localhost:4200/

Create the WebAssembly Code

The second step now is the creation of the WebAssembly code. If you are not familiar with WebAssembly, you should visit their website and go through the documentation. You will have to download and install the emsdk package.

Angular will need access to the WASM code we will create, so the easiest solution for us is to create a cpp folder inside the src folder of the Angular project. The Angular project should then have a structure that looks like this:

 +-- e2e/
 +-- node_modules/
 +-- src/
     +-- app/
     +-- assets/
     +-- cpp/           <-- NEW FOLDER
     +-- environments/

Inside the cpp/ folder let’s create a file called main.c with the following C code:

#include <string.h>
#include <emscripten/emscripten.h>

double EMSCRIPTEN_KEEPALIVE multiply(double a, double b) {
    return a * b;

int EMSCRIPTEN_KEEPALIVE get_length(const char* text) {
    return strlen(text);

int main() {}

Basically we have implemented two C functions that we will be able to call from Angular. Note that we have to decorate these functions with EMSCRIPTEN_KEEPALIVE, which prevents the compiler from inlining or removing them.

We can now compile this code with the following command:
emcc \
    -O3 \
    -s WASM=1 \
    -o webassembly.js \

Note that I compile the C code with optimizations on (-O3 parameter), which makes the output more compact and efficient (if possible). The WASM=1 option tells the compiler to generate WebAssembly code (without this parameter, it would generate asm.js code instead). The EXTRA_EXPORTED_RUNTIME_METHODS=[‘ccall’] option is needed because we want to call the C functions from Javascript using the Module.ccall() javascript function (see the Angular code in the next section). I encourage you to read more about these parameters and play with them in order to see what errors or changes you will get.

Once you compile the C code, two files will be generated in the cpp/ folder:
  • webassembly.js — Javascript glue code that helps loading the webassembly code (wasm)
  • webassembly.wasm — Intermediate binary code to be used by the browser to generate machine code

The WebAssembly code is now ready to be used. Let’s go back to the Angular project now.

Modify the Angular Project

The default project created by the angular CLI contains an app/ folder with the following contents (among other files):

 +-- src/
      +-- app/
           +-- app.component.ts
           +-- app.component.html
           +-- app.component.css

Let’s change the app.component.ts file to have the following code:

import { Component } from '@angular/core';

declare var Module: any;

    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.css']
export class AppComponent {
    multiplyResult: number;
    getLengthResult: number;

    multiply(a: number, b: number): void {
        this.multiplyResult = Module.ccall(
            'multiply', // function name
            'number', // return type
            ['number', 'number'], // argument types
            [a, b] // parameters

    getLength(s: string): void {
        this.getLengthResult = Module.ccall(
            'get_length', // function name
            'number', // return type
            ['string'], // argument type
            [s] // parameter

In this code we implement two methods of the AppComponent class that will forward the call to our WebAssembly code generated in the previous section.

The first thing you should notice is the “declare var Module: any” at the top of the file. This is the typescript way of saying “there is a global variable named Module that I want to use in this scope”.The Module variable is actually a Javascript object used by the WebAssembly glue code. We declare it using type “any” because we don’t want typescript to complain about the things we will do with it. You should NOT do that in production code. It should be fairly simple for you to create a typescript definition file with class and method signatures (see my previous blog post where I discuss this).

Inside the multiply() member function we can call WebAssembly code using the Module.ccall() javascript function:

    'multiply', // function name
    'number', // return type
    ['number', 'number'], // argument types
    [a, b] // parameters

In such call we pass the function name, return type, argument types and actual parameters to the binary function.

Now let’s change the app.component.html code in order to build our user interface:

<button (click)="multiply(10.5, 21.2)">
    Call multiply(10.5, 21.2)
<div *ngIf="multiplyResult">
    multiply result is {{ multiplyResult }}

<button (click)="getLength('Testing String Length')">
    Call length('Testing String Length')
<div *ngIf="getLengthResult">
    get_length result is {{ getLengthResult }}

This HTML code adds two buttons to the page. The first button will call the multiply() function with two parameters (10.5 and 21.2), and the second button will call the getLength() function with “Testing String Length” parameter.

The Last Step

If you try to serve the existing source code with the ng serve command, you will notice that Angular doesn’t automatically load the WebAssembly code we have added to the src/cpp/ folder. We have to manually change the index.html file (inside the src/ folder) and add the following code snippet to the end of the <head> section:

var Module = {
    locateFile: function(s) {
        return 'cpp/' + s;
‹/script›script src="cpp/webassembly.js"›‹/script

This code imports the Javascript glue code generated by the WebAssembly compiler, but it also defines a Module.locateFile() function that will be used by WebAssembly to find the WASM file. By default, WebAssembly will try to find the WASM file at the root level of the application. In our case, we keep that file inside the cpp/ folder, so we have to prepend that folder’s name to the file path.

Now everything should be fine to go and the app should look like the screen below (with a bit of CSS makeup).



Angular and WebAssembly are two great technologies that can be used together without too much effort. There is no secret in this combination since both technologies are designed to work with web browsers and Javascript code is a common byproduct of their operations.

WebAssembly is still under development, but it has a huge potential towards native code performance, which is a dream yet to come true for web applications. Its roadmap is full of amazing features that serious web developers should never turn their back on.



Beware the return statement in Javascript

The return statement in Javascript looks innocent and intuitive, but it hides a caveat that can break the logic of your code and lead to undefined behavior. The best way to illustrate this is to use a simple example, so let’s consider this function:

function greeter(name) {
    return 'Hello ' + name;
greeter('Hugo');  // works as expected

The function above works as expected and you don’t have to worry much about it. Now let’s imagine that you have to concatenate more strings inside the greeter function and you end up with a much longer line of code like this:

function greeter(name) {
   return 'Hello, ' + name + ',\nThis is a long long long sentence.\nThis is another long sentence.';

The code above also works fine if you keep it exactly as it is. You can notice that the string is too long to fit the width of the screen, so any decent developer would care about that and try to break that long line into smaller readable chunks. One possibility is:

function greeter(name) {
       'Hello, ' + name + ',\n' +
       'This is a long long long sentence.\n' + 
       'This is another long sentence.';

B-I-N-G-O! The code above does NOT work as expected. This function returns undefined because the return statement is actually empty and Javascript doesn’t consider the next lines to be part of the return statement. There are some ways to fix this issue. One of them is to remove the line break after the return keyword, like this:

function greeter(name) {
   return 'Hello, ' + name + ',\n' +
       'This is a long long long sentence.\n' + 
       'This is another long sentence.';

You can notice that the code above is a bit unaligned. A perfectionist (like me) would add the line break after the return in order to fix the alignment problem, but this actually creates the other (much bigger) problem. Sigh.

Another way of fixing the code is to use parenthesis around the return value. In this case the alignment isn’t a problem:

function greeter(name) {
   return (
       'Hello, ' + name + ',\n' +
       'This is a long long long sentence.\n' + 
       'This is another long sentence.'

Parentheses are valid in this case because the return statement can be followed by an expression. It is quite uncommon to see such syntax, but in this case it plays an important role. This is one of the many details about the language that you have to be aware of in order to play it safe. If you develop code in other languages — like Java or C++ — you know that such code without the parentheses would work perfectly fine in those languages, so it would be fairly easy to forget to use them when you switch back to Javascript.

Typescript is better

In Typescript we could have some similar code like this:

function greeter(name: string): string {
       'Hello, ' + name + ',\n'
       'This is a long long long sentence.\n' + 
       'This is another long sentence.';

If you try to compile this code with Typescript you get the following error message:

code.ts(3,8): error TS7027: Unreachable code detected.

So it basically says that line 3 has unreachable code and now you have to fix it. This is a much better world compared to pure javascript development since you know that this issue will not waste your time later.

If you use Typescript, make sure you have the compiler option “allowUnreachableCode” enabled (otherwise you will not see the error above). Read more about this flag on the compiler options page.

One question may come to your mind at this point: should Typescript fix the code automatically by generating JS code that doesn’t contain the line break after the return statement? Nope. The number of scenarios that this issue could happen is huge, so it is much safer to just warn the developer instead of trying to fix the code silently. I think Typescript is doing a good job here (kudos to Microsoft).


The return statement issue described in this post is just one of many caveats of the Javascript language. It should remind you that Javascript alone can be a treacherous path and you should definitely consider better alternatives like Typescript in your development. Javascript alone can make the software maintenance a nightmare in the long run, so serious developers must look for better alternatives in order to detect and fix mistakes as early as possible. Be productive and stay safe.

Having fun with Typescript, ThreeJS and Ammo.js

This week I implemented a simple 3D experiment with Typescript, ThreeJS and Ammo.js. It works like an FPS game where you can navigate with the mouse pointer and W-A-S-D keys, and you can also shoot cannon balls with the mouse button.


Using Typescript

Typescript is a great language that compiles to Javascript code. If you are a web developer and have never used this language before, you should check it out immediately because it has a lot of interesting things that can make your life (as a web programmer) much easier. You know that Javascript is a powerful language, but alone it can make the maintenance of big projects a nightmare. Typescript is a great step towards high quality maintainable code because it is a typed superset of Javascript.

The challenge of using Typescript with some external libraries is that you need the type definition files of those libraries to compile your code. A type definition file is a piece of typescript code that contains the declaration of types, classes, interfaces and functions of a library. It doesn’t provide implementation details, only types and signatures. This allows Typescript to analyze your code and detect programming errors. For example, check the ThreeJS definition file here:

DefinitelyTyped is a website that aggregates lots of definition files and it is a great asset for Typescript developers. Sometimes it doesn’t contain definition files that you need and this was the case of the Ammo.js library I used in my experiment.

No definition files – What should I do?

When there is no definition file available for the library you want to use, you can build one your own. Typescript can certainly guide you through this process. The compiler errors reported by Typescript will show you exactly what is missing in the definition file. For example, let’s try to declare a variable like this:

let physicsWorld: Ammo.btDiscreteDynamicsWorld;

You can start with an empty definition file (ammo.d.ts). Compiling the code above will show this message:

Cannot find namespace 'Ammo'.

So you can use this information to fix your custom definition file for that library. In this case, you can just add an empty namespace like this:

declare namespace Ammo {

After that, if you try to compile again the error message will change to:

Module 'Ammo' has no exported member 'btDiscreteDynamicsWorld'.

So you can change your definition file to:

declare namespace Ammo {
    export class btDiscreteDynamicsWorld {

Following this pattern, you can basically add the missing information piece by piece to the definition file until your project is fully compilable.  Of course you have to keep an eye on the real library code and make sure your declarations are consistent with the real implementation. For Ammo.js, you can see below the final definition file I created. Note that there is no implementation code, only types and signatures.

declare namespace Ammo {

   export class btDefaultCollisionConfiguration {}

   export class btCollisionDispatcher {
      constructor(c: btDefaultCollisionConfiguration);

   export class btVector3 {
      x(): number;
      y(): number;
      z(): number;
      constructor(x: number, y: number, z: number);

   export class btAxisSweep3 {
      constructor(min: btVector3, max: btVector3);

   export class btSequentialImpulseConstraintSolver {}

   export class btDiscreteDynamicsWorld {
      constructor(a: btCollisionDispatcher, b: btAxisSweep3, c: btSequentialImpulseConstraintSolver, d: btDefaultCollisionConfiguration);
      setGravity(v: btVector3);
      addRigidBody(b: btRigidBody);
      stepSimulation(n1: number, n2: number);

   export class btConvexShape {
      calculateLocalInertia(n: number, v: btVector3);
      setMargin(n: number);

   export class btBoxShape extends btConvexShape {
      constructor(v: btVector3);

   export class btSphereShape extends btConvexShape {
      constructor(radius: number);

   export class btRigidBody {
      constructor(info: btRigidBodyConstructionInfo);
      setActivationState(s: number);

   export class btQuaternion {
      x(): number;
      y(): number;
      z(): number;
      w(): number;
      constructor(x: number, y: number, z: number, w: number);

   export class btTransform {
      setOrigin(v: btVector3);
      getOrigin(): btVector3;
      setRotation(q: btQuaternion);
      getRotation(): btQuaternion;

   export class btRigidBodyConstructionInfo {
      constructor(mass: number, motionState: btDefaultMotionState, shape: btConvexShape, inertia: btVector3);

   export class btDefaultMotionState {
      constructor(t: btTransform);

You should realize that my type definitions for Ammo.js are far from complete, considering what the library does. Ammo is a huge library and it contains a lot more things that my code will not use at this point. This is okay and the main point here is that the file I created is enough for me to compile my experiment and keep moving. If I need more methods from Ammo.js, I can adjust that file as needed and move on.

Typescript and browser differences

Sometimes Typescript will NOT understand your Javascript code and you will have to deal with it. Let me give you a clear example:

let m = document.body.requestPointerLock || 
        document.body.mozRequestPointerLock || 

The code above is syntactically correct and it looks for the Pointer Lock API in the current browser. Typescript complains about this code with the following error message:

Property 'mozRequestPointerLock' does not exist on type 'HTMLElement'.
Property 'webkitRequestPointerLock' does not exist on type 'HTMLElement'.

Those methods are browser-specific and typescript doesn’t recognize them. We have to fix this error message and one possible solution is to assign the document.body value to a variable of type “any”. This will prevent typescript from checking if those properties belong to the HTMLElement type:

let _body: any = document.body;
let m = _body.requestPointerLock || 
        _body.mozRequestPointerLock || 

There are other ways of handling such cases, but I won’t explain them in this post. One great thing about Typescript is that it doesn’t stop the compilation when it finds errors like the one above. It simply generates the javascript output as if the code were correct and you can clean up that error message later.


Working with Typescript is an amazing experience. I believe that Microsoft is doing a great job with this language and contributing to the future of web development with great ideas. My experiment with ThreeJS and Ammo.js is just in the beginning. I have a good experience with the BulletPhysics library (see my personal projects) and this should allow me to expand the code and build more cool demos, examples and games.


jQuery: Performance analysis of selectors

In this article jQuery is tested with different selectors in order to find specific elements in the DOM tree. The delay of each selector is precisely calculated and the idea is to find out which one is the fastest for the given goal.

jQuery is one of the best javascript libraries I have ever worked with. It is quite simple and usually reduces the amount of javascript code in web applications. Besides all the advantages it brings to the web community, we have to pay attention to a few details when reusing this library in order to get the best part of it.

I will describe a few tips on how to improve the performance of your javascript code. Most of these tips aren’t a big deal if your pages are small and simple. But if you create complex html pages, you should follow them in order to prevent the browser from locking when the page loads up. Even if you are not concerned with performance at all, learning these things will bring benefits to your overall knowledge about this library.

jQuery has a bunch of different selectors – as you can see from the documentation here – and I won’t consider all of them in this analysis. My idea is to explore different ways of finding a specific element in the html page by using different types of search. Benjamin Sterling has already researched this topic here, but I want to add a different point of view, which is more accurate and provides more alternatives for the developers.

Let me start talking about the test html page, which has over 20,000 elements separated in chuncks of 5,000. Basically, there are 5,000 divs + 5,000 spans+ 5,000 paragraphs and 5,000 small tags with the following characteristics:

<!-- 5000 'div' elements -->
Div 0


Div 1

Div 4999

<!– 5000 ‘span’ elements –> <span id=”b-0″ class=”span-0″ row=”b-0″>Span 0</span> <span id=”b-1″ class=”span-1″ row=”b-1″>Span 1</span> … <span id=”b-4999″ class=”span-4999″ row=”b-4999″>Span 4999</span> <!– 5000 ‘p’ elements –> <p id=”c-0″ class=”p-0″ row=”c-0″>Paragraph 0</p> <p id=”c-1″ class=”p-1″ row=”c-1″>Paragraph 1</p> … <p id=”c-4999″ class=”p-4999″ row=”c-4999″>Paragraph 4999</p> <!– 5000 ‘small’ elements –> <small id=”d-0″ class=”small-0″ row=”d-0″>Small 0</small> <small id=”d-1″ class=”small-1″ row=”d-1″>Small 1</small> … <small id=”d-4999″ class=”small-4999″ row=”d-4999″>Small 4999</small>

The 20,000 elements above are generated by javascript. They provide a good laboratory to check the speed of each selector, since we can expect more accurate results in this analysis. The page itself has a few more tags to display information and execute each test, but this shouldn’t affect the final results.

The test page is available here. It takes a few seconds to load because the javascript must create the DOM tree as described above. So please be patient. Note also that each test uses the measure() function, which calculates the delay of the call in milliseconds.

Test 1 – Finding an element by ID

The first test is to find an element by its ID. I decided to get the element whose ID is “d-2642”. We can do this in three different ways:

A – Using the ID selector

B – Using attribute search

C – Using attribute search + tag

Running this test for the first time in different browsers, I could reach the results displayed in the following table (in milliseconds). It is clear that the # operator is the most efficient one.

Firefox Opera IE6 IE7 Safari
A 156 0 31 40 0
B 3609 828 2344 841 844
C 578 93 406 210 172

Test 2 – Finding an element by Class

Although CSS classes are intended to be reused among elements, you might create some elements with a unique class name just to identify and retrieve them through javascript. This is exactly what we test in this second test by seaching the element whose class is “p-4781”. We have four alternatives:

A – Using the class selector

B – Using the class selector + tag

C – Using attribute search + tag

D – Using tag search + filter

After running this test for the first time in different browsers, I got:

Firefox Opera IE6 IE7 Safari
A 2891 641 1718 631 329
B 453 78 313 180 78
C 422 109 578 201 187
D 203 266 375 210 94

The table above shows case B as the fastest selector for most browsers (except Firefox). It is easy to understand why case A isn’t efficient, since the code has to iterate over all elements of the DOM tree. Case C and D aren’t that bad, but I would say case B should be the preferred one for this goal.

Test 3 – Finding an element by Attribute

The third test is to find elements by a given attribute value. Sometimes this technique is useful and I decided to test it by searching for the element that has “c-3221” as the value of the row attribute. There are four possibilities in this case:

A – Using attribute search

B – Using attribute search + tag

C – Using tag search + filter

D – Using (tag + attribute) search + filter

Running this test for the first time in different browsers, I could get the following results:

Firefox Opera IE6 IE7 Safari
A 6610 1390 2500 801 1156
B 1250 360 406 200 250
C 1265 968 485 231 281
D 4078 1000 656 320 625

Case B is for sure the best approach to find an element by a specific attribute value.


This experiment was an attempt to find the right and fastest way of finding specific elements in the DOM tree using jQuery. Every jQuery developer should know and understand these details in order to create efficient code. Benjamin Sterling gave the first step in such performance analysis, but I could provide another point of view, which uses a big DOM tree and more alternatives to be checked.