Everybody has been talking a lot about JS frameworks over the last few years. There has been a large number of attempts to create the ultimate front-end framework but there is no clear winner.

While the high doses of innovation and the thrill of trying something new are great, the rapid change of technologies has become a critical risk.

Every six months, a hot new framework hits the mainstream, and our community explodes with excitement.

We can’t avoid making a decisions and answering questions like:

• Should I train my team on Angular, React, Ember… ?
• Should I use Angular, React, Ember… in a project that is expected to have a life cycle of 10 years?

While we can try to back-up our choice…

Most technology decision makers use metrics like community size, popularity, and big company support to justify their choice of framework.

Choosing the wrong answer could lead us to undesired...

An introduction to the development of React applications with Atom and TypeScript

We are about to develop the famous TODO App from the TodoMVC project using React and TypeScript:

In this post you will learn about the following:

• 1. Setting up the environment
• 2. Setting up the project
• 3. The basics about React components
• 4. Developing React components with TypeScript
• 5. Compiling the application
• 6. Running the application

Let’s get started!

 1. Setting up the environment

We will start by setting up the environment:

• Download an install Node.js from https://nodejs.org.

• Install TypeScript and tsd using npm:

$ npm install -g typescript tsd

Note: use sudo if you are using OSX

• Download and install atom from https://atom.io/.

• Install the atom-typescript plugin for atom:

$ apm install atom-typescript

This plugin has some cool features like HTML to TSX:

Or dependency...

 An in-depth look to the TypeScript implementation of decorators and how they make possible new exciting JavaScript features like reflection or dependency injection.

This article is the fourth part of a series:

• PART I: Method decorators
• PART II: Property decorators & Class decorators
• PART III: Parameter decorators & Decorator factory
• PART IV: Types serialization & The metadata reflection API

I will assume that you have already read all the previous posts of these series.

In the previous post in this series we learned what are decorators and how they are implemented in TypeScript. We know how to work with class, method, property and parameter decorators, how to create a decorator factory and how to use a decorator factory to implement configurable decorators.

In this post we will learn about:

• 1. Why we need reflection in JavaScript?
• 2. The metadata reflection API
• 3. Basic type...

 An in-depth look to the TypeScript implementation of decorators and how they make possible new exciting JavaScript features like reflection or dependency injection.

This article is the third part of a series:

• PART I: Method decorators
• PART II: Property decorators & Class decorators
• PART III: Parameter decorators & Decorator factory
• PART IV: Types serialization & The metadata reflection API

In the previous post in this series we learned what are decorators and how they are implemented in TypeScript. We know how to work with class, method and property decorators.

In this post we will learn about:

• The remaining type of decorator: the parameter decorator.
• How to implement a decorator factory.
• How to implement configurable decorators.

We are going to use the following class to showcase these concepts.

class Person { 

  public name: string;
  public surname: string;

 An in-depth look to the TypeScript implementation of decorators and how they make possible new exciting JavaScript features like reflection or dependency injection.

This article is the second part of a series:

• PART I: Method decorators
• PART II: Property decorators & Class decorators
• PART III: Parameter decorators & Decorator factory
• PART IV: Types serialization & The metadata reflection API

In the previous post in this series we learned that we can find the available decorators signatures in the TypeScript source-code.

We also learned how to implement a method decorator and we answered some basic questions about the way decorators work in TypeScript:

• Where is decorator being invoked?
• Who is providing the decorator arguments?
• Where is the __decorate function declared?

I will assume that you have already read the Part I of these series and you know the answer to these...

 An in-depth look to the TypeScript implementation of decorators and how they make possible new exciting JavaScript features like reflection or dependency injection.

This series will cover:

• PART I: Method decorators
• PART II: Property decorators & Class decorators
• PART III: Parameter decorators & Decorator factory
• PART IV: Types serialization & The metadata reflection API

A few months ago Microsoft and Google announced that they were working together on TypeScript and Angular 2.0

We’re excited to announce that we have converged the TypeScript and AtScript languages, and that Angular 2, the next version of the popular JavaScript library for building web sites and web apps, will be developed with TypeScript.

 Annotations & decorators

This partnership has helped TypeScript to evolve additional language features among which we will highlight annotations.

Annotations, a way to add...

 We will no longer write pure JavaScript really soon

I’ve been keeping an eye on the arrival of some ES6 and ES7 features and proposals, as well as some trending JavaScript technologies (particularly Compile-to-JavaScript languages like TypeScript, BabelJS or CoffeeScript) and I dare to predict that we will not longer write pure JavaScript really soon.

 What are your arguments?

I have some arguments to back up my idea:

 1. Compiler emitted metadata

We can find online proposals to add Decorators to ES7, along with a prototype for an ES7 Reflection API for Decorator Metadata. The idea behind decorators and reflection is that we can add some metadata to JavaScript objects in order to add support for some JavaScript features (like Dependency Injection, Runtime Type Assertions or Reflection/Mirroring) that were not possible no longer ago.

These new features will help us to improve the...

 A lightweight inversion of control container for TypeScript & JavaScript apps

A few months ago I started to think about the possibility of creating a requireJS TypeScript fork in order to add dependency inversion (DI) support.

After some time thinking about it, I decided that mixing a dependency loader and an inversion of control (IoC) container wasn’t the best idea (based on the S, the single-responsibility principle, in SOLID principles). So I started to create a stand-alone IoC container for TypeScript & JavaScript apps.

I started the project thinking about how it should work and how it should be used. During that time I had two major influences:

• My thoughts about how an IoC container should work are highly influenced by a popular open-source IoC container for .NET: Ninject

• My thoughts about how an IoC container should be used are highly influenced by a great book...

Since January 2015 I’ve been trying to investigate what new libraries, frameworks, languages, etc. are popular these days.

Last year learned a lot MV* frameworks, in particular, about Ember.js, Backbone.js, Chaplin.js and Marionette.js.

I also learned a lot about JavaScript in the MEAP Stack (MongoDB, Express, Angular.js, and Node.js) and about modern web development productivity tools. I mainly worked with Grunt.js and Yeoman.

2014 was a very productive year in knowledge terms. Let’s take a look to the tools, technologies and frameworks that I plan to learn in 2015.

 Browserify & Gulp

I’m planing to migrate the automated builds from Grunt.js to Gulp.js during 2015. There are not huge difference between these two tools but I find the Gulp.js configuration files more clean and easy to follow. Grunt.js is a great tool but it looks like Gulp.js will dominate the throne of the...

I like to organize my Wep API projects using the following solution organization (Sorry for the ugly diagrams…).

Each circle in the diagram is a .Net project (or DLL) in the solution:

• Solution.Global: The global DLL contains POCO objects and the public interfaces of all the others DLLs. All the DLLs have a reference to the Global DLL.
• Solution.IoC: The IoC project declares the bindings between abstractions (interfaces in Global) and implementations (Objects in each DLL). The code of this DLL can easily be re-used.
• Solution.WebApi: The Web API project is the composition root for the IoC and therefore it is the only DLL that points to the IoC project.
• Solution.DAL: The application data access layer.
• Solution.WebClient: The front-end application.

By using this separation we can follow the SOLID principles, for example I can replace the Solution.DAL DLL for a new one by just...