A Toolbox of the Angular 2 Developer

Say you need to hire a Web developer experienced with Angular. What would you expect the developer to know? Well, he or she needs to know how to create Angular components, what’s data binding, dependency injection, routing et al. But this is just the tip of the iceberg. Below is a list of languages and tools that professional Angular developers use.

* JavaScript is a de-facto standard programming language for the front-end of Web applications. ECMAScript 6 (ES6) is the latest standardized specification for scripting languages and JavaScript is the most popular implementation of this spec.

* TypesScript is a superset of JavaScript that makes developers more productive. TypeScript 1.5 (currently in Beta) supports most of the features of ES6 and adds optional types, interfaces, meta-data annotations and more. The Angular 2 framework itself is written in TypeScript.

* DefinitelyTyped is a vast collections of files describing the API of 500+ libraries and frameworks. Using DefinitelyTyped allows the TypeScript compiler and IDEs know the types expected by the APIs of these libraries.

* Angular 2. It’s a complete re-write of a popular Angular 1.x. It’s currently in Alpha.

* Transpilers. Since most of the Web browsers support only the ECMAScript 5 syntax, you need to transpile (convert, compile one source code to another) the code written in TypeScript or ES6 to its ES5 version for deployment. Angular developers use Babel, Traceur, and the TypeScript compiler.

* SystemJS is a universal module loader, which load modules created in ES6, AMD or CommonJS standards.

* Node.js is a platform built on Chrome’s JavaScript engine. Node includes both a framework and a runtime environment to run JavaScript code outside of the browser. We don’t use the framework, but you can’t avoid using the Node runtime to install required tools for developing Angular applications.

* npm is a package manager that allows to download tools and reusable JavaScript modules. Npm has a repository of thousands modules, but we’ll mostly use it for installing developer’s tools, e.g. the TypeScript compiler, the task runner Gulp and more.

* Bower used to be a popular package manager for resolving application dependencies (e.g Angular 2, jQuery at al.). We don’t use Bower any longer as everything we need can be downloaded using npm.

* jspm is yet another package manager. Why do we need another package manager if npm and bower can take care of all dependencies? Modern Web applications consist of loadable modules and jspm integrates SystemJS, which makes loading modules a breeze.

* Grunt is a task runner. Lots of steps need to be performed between developing and deploying the code. All these steps must be automated. You may need to transpile the code written in TypeScript or ES6 into widely supported ES5 syntax. The code, images, and CSS files need to be minimized. You may want to include the tasks that will check the code quality and unit-test your application. With Grunt you configure all the tasks and their dependencies in a JSON file so the process is 100% automated.

* Gulp is a newer than Grunt task runner. It can automate all the tasks just as Grunt does, but instead of configuring the process in JSON you simply program it in JavaScript. This allows you to debug it if need be.

* jslint and eslint are code analyzers that looks for problematic patterns in a JavaScript program or JSON-formatted documents. These are code quality tools. Running a JavaScript program trough jslint or eslint results in a number of warning messages suggesting how to improve the code quality of this program.

* tslint is is a code quality tool for TypeScript. It has an collection of rules (can be extended) to enforce the recommended coding style and patterns.

* Minifiers make files smaller. For example, in JavaScript they remove comments, line breaks, and make variable names shorter. Minification can also be applied to HTML, CSS, and image files.

* Bundlers combine multiple files and their dependencies in a single file.

* Testing frameworks. Since JavaScript syntax is very forgiving, the application code requires testing. We use the Jasmine framework and the test runner called Karma.

* IDE. Both JavaScript and TypeScript are well supported by modern IDEs and text editors such as WebStorm, Visual Studio, Visual Studio Code, Sublime Text, Atom et al.

* Browser as a development environment. All major Web browser comes with developer tools that allow to debug your programs right inside the browser. We use Chrome Developer Tools.

* Web Components. This is the future of Web development. The goal is to develop reusable widgets for the Web application. We already started using the Polymer library of Web components in a pilot project and like it a lot.

This list may look intimidating, but it can be mastered one step at a time. Programming in Angular 2 is easier than in Angular 1.x, but the initial environment setup should be done right so you can really enjoy the development process.

13 thoughts on “A Toolbox of the Angular 2 Developer

  1. Yakov, another very helpful Ang2 post – thanks for sharing

    I’ve been putting together a list of the things I’ll need to get up and running in my “developer stack” as I make the transition to Ang2, and this covers most of the bases. Figuring out where the package managers complement each other, and where they’re competing, is one thing that’s been challenging to decipher. Do you think that npm, bower, SystemJS and jspm are all helpful to use together for maximum efficiency, or is there some overlap/redundancy there?

    Also, do you have a Grunt-vs-Gulp preference? Gulp seems to have rep as newer/faster/cleaner, but I have no experience upon which to base an opinion. Thanks!

    1. Our main set of tools is npm, jspm, SystemJS, and Gulp. In some cases we still use Bower.
      In early August Manning will publish (as MEAP) the first chapters of our Angular 2 book, where we give more details about our tooling preferences.

  2. Nice post!

    This is just about the list I’ve created for myself since diving into all this two months ago; it took me a while to discover all these though!🙂

    I currently use the following (all covered by my gulp build):
    – Gulp 3.9 for the build
    – TypeScript (transpiled to ES5 + automatic generation of reference files)
    – ES6 (transpiled to ES5)
    – Sass
    – NPM: manage all build-related dependencies
    – JSPM: manage all app dependencies (angular2, etc)
    – SystemJS
    – JSPM API to build production JS bundles
    – jshint for js code quality
    – jscs for js code style
    – tshint for ts code quality/style
    – css & js sourcemaps
    – html minification
    – BrowserSync as dev web server (automatic reloading, synchronization across connected browsers, etc)
    – watch for changes with automatic re-build after changes (sass, ts, js, html)
    – …🙂

    My build is pretty solid right now, it only lacks incremental builds (just a matter of adding gulp-watch & gulp-batch I think..) and testing.

    I’ve also setup a good project structure so that the code stays organized, though the build is flexible enough to let me move things around.

    I’d like to create a yeoman generator based on my build but that’s for later🙂

    The project is here for the curious: https://github.com/dsebastien/midnightLightV2

  3. Can you suggest a good book to get up and running fast in Angular JS 1.3/1.4? I need to use this in my next project and need a book that talks about 80% stuff that one needs in a project and not one big fat book that covers the remaining 20% as well. Thanks in advance!

  4. Thanks for pointing to me the Angular JS Book. It was very helpful.

    I have an architectural question and was wondering if you would share your thoughts. Say we have 2 web applications WEBAPP1 and WEBAPP2 deployed in the same or different application server. During the application flow of WEBAPP1, we need to launch WEBAPP2 in a new browser window from WEBAPP1. The application flow is now transferred to WEBAPP2 where the user is passed through various pages of forms and based on the responses to the question, we get a final result. Now, we have to pass the results(JSON format) to WEBAPP1 and close the browser window of WEBAPP2.

    Is there a clean way of doing this communication between the 2 web applications based on the scenario I mentioned?

  5. Yes, that’s where it gets pretty nasty for me……these sites could be in potentially different domains😦

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s