Over a million developers have joined DZone.

How to Run Angular 2 in Production Today

With Angular 2 currently in beta and the final release just around the corner, it's tough to decide whether or not to go ahead and make the switch or continue working in Angular 1. With the methods presented below, it's totally possible to start developing an application in Angular 2 and also have it running in production today.

· Web Dev Zone

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

Recently, there were announcements that made clear that the Angular 2 final release is just around the corner. This might be as early as mid-May during Google IO!

But that's still several months into the future, and there are many projects that we will start between now and then. A question that gets asked a lot these days is: should I use Angular 2 or just stick with Angular 1?

Angular 2 is currently in beta, and being in beta means the following, according to the official announcement:

Beta means we're now confident that most developers can be successful building large applications using Angular 2

This was about 3 months ago. So, the answer is yes, we should definitely use Angular 2 for projects starting today. But how?

Let's answer this and several other questions while going through the following topics:

  • A strategy for putting an Angular 2 app in production
  • Choosing a package manager and a module loader
  • Is the bundle size a real concern?
  • The current state of the angular-cli
  • Choosing a lightweight toolchain while waiting for angular-cli
  • How to use Angular 2 with a minimal build
  • How to handle HTML templates
  • How to handle CSS
  • How to handle internationalization
  • Conclusions

Current Status of the Angular 2 Composing Parts

The Angular 2 core functionality which includes Components, Directives, Forms, Pipes, Dependency Injection, and HTTP has been stable for several months and ready to go. The router is expected to have some API changes to improve developer ergonomics, but the main functionality is already available.

There are still some hoops to jump through, but those are the exception and not the rule.

So, what is preventing us from using Angular 2 in production? There are several perceived reasons... one of them is that the tooling around it is still a work in progress.

The Current State of the Angular-cli

In the long term, one of the great advantages of Angular 2 is that we will have an opinionated way to setup and build a project, via the Angular Command Line Interface (CLI).

This tool will provide us with a way to scaffold projects and a standard build pipeline. The build will internally be based on broccoli, and the CLI itself is based on the popular ember-cli.

But most importantly, we will have a build system officially endorsed by the Angular 2 team that will take us from development to production.

The problem is that the angular-cli, although already working and being used to build the Angular 2 Material widget library, is currently, according to the docs:

...very much still a work in progress. We still have a long way before getting out of our alpha stage.

So, it's clear that in the long term we want our Angular 2 projects to be built using angular-cli, but that solution is still in its early stages.

Also related to the toolchain, there are more questions regarding how to setup our project.

Is There a Recommended Package Manager and Module Loader?

For one, which package manager and module loader should we choose? The Angular team mentioned recently in the Adventures in Angular podcast that they would be standing behind one package manager and one module loader.

Its was not mentioned which ones at that stage, but we can guess via the documentation and the contents of the project's google drive that:

  • Package manager: The package manager is npm, based on the existence of proposal documents for making npm more friendly for frontend development, and the fact that almost everything can be found in npm these days
  • Module Loader: both the quick start tutorial and the initial version of angular-cli use SystemJS, this will likely be the module loader of choice for building Angular 2 apps.

It's important to bear in mind that this does not mean that the framework will not work in other package managers or module loaders, on the contrary, all of them will be supported.

Besides the toolchain, there seems to be another main point that is being worked on: the overall bundle size.

Is the Bundle Size a Real Concern?

The current 115KB compressed and minified size of the main Angular 2 bundle might not be a concern depending on the type of application you are building:

  • Are you doing mobile development? If not, the bundle size might not be much of a concern. Many pages that we surf every day on the Internet load way more JavaScript than that.
  • Are you building an enterprise application that will run only on a company LAN? You probably have a very fast server connection, making the bundle size even less of a concern.
  • Are you going to production in less than 2 months? By then the size of the bundle issue (if it's an issue at all for your project) should have been fixed.
  • Are you building a productivity single page app? One extra second of initial load time might not be an issue. For example, users are used to waiting over 5 seconds for Gmail to open

Let's go back to the meaning of beta—it means we should be able to run an application in production. Given this and all of the above, can we come up with a strategy to do so?

A Strategy for Running Angular 2 in Production in the Next Few Months

One way to do it is to choose a lightweight toolchain that can be put in place quickly but still is sufficient to put an app in production. At the same time, we want to make sure that such a toolchain can be easily replaced in a couple of months once angular-cli lands.

Once angular-cli is ready, we will then have all the functionality necessary to compile templates in a build step instead of at startup time. With that the compiler part of Angular will not need to be shipped to the browser and the bundle size will be drastically reduced.

What we want to avoid is to make a large investment in a complex toolchain that we already know upfront that will be obsolete in a matter of months.

So let's start choosing our toolchain and development practices, with an eye towards the present, but keeping it future-proof regarding a future migration to angular-cli.

Package Manager and Module Loader

Let's start with the simplest choices: it's better to use npm as our package manager and SystemJS as module loader, as that seems to be the path of least friction.

Note that other package managers and module loaders would also work, but this is the choice that will likely be easier to migrate to angular-cli, and it's the combination that angular-cli currently uses.

How to Load Angular 2

For loading Angular in the app itself, a very straightforward way to do so is to simply use a CDN to get your scripts loaded. This gives the following immediate benefits:

  • it allows the development to start right now
  • it makes for a simpler initial build
  • its easy to go back later once angular-cli is available and refactor this
  • its actually a viable option to use in production (for many applications) as we will see next

Where to Load Angular From

The Cloudflare sponsored Content Delivery Network CdnJs serves for free most scripts needed to run Angular 2, as well as many others. In fact, all script needed by Angular are available there except:

  • the beta version of RxJS
  • The IE11 compatibility shims (soon to be included in the main bundle)

But those can be taken as well from the npm CDN. Let's now measure some load times. Let's take the following script tags for example:

<script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/0.19.24/system.js"></script><script src="https://npmcdn.com/rxjs@5.0.0-beta.2/bundles/Rx.js"></script><script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/2.0.0-beta.9/angular2-polyfills.min.js"></script><script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/2.0.0-beta.9/angular2.min.js"></script><script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/2.0.0-beta.9/http.min.js"></script><script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/2.0.0-beta.9/router.min.js"></script>
<script src="https://npmcdn.com/angular2@2.0.0-beta.9/es6/dev/src/testing/shims_for_IE.js"></script>

As we can see, everything is being loaded from CdnJs, a couple of scripts, and soon everything will be available in CdnJs. We could load everything from npm CDN as well, but sometimes the load times from the npm CDN are much longer, so it's better to use Cloudflare as much as possible like we are doing here.

You can easily get 300ms of total script load time for all the scripts needed to run Angular 2, including RxJs. This is with the browser cache turned off:

Load times of a Hello World Angular 2 application

These are pretty acceptable timings! We can actually run many productivity or enterprise desktop-like apps using this setup, with no problem at all.

But what about other things, like how should we handle our HTML or CSS in a way that is future proof and easy to migrate to angular-cli?

How to Handle HTML Templates

The main concern about HTML templates is that we want to make sure that we won't have to load them in separate HTTP requests in production, as this really slows down a lot the application startup.

In Angular 1, we would use a build step to pre-populate the template cache using plugins like gulp-ng-html2js.

A feature will be available soon called Template Transforms (check out this talk), that will allow one to build an ecosystem of tooling around templates. But right now, we have two ways to include templates in a component:

  • inline templates: This consists on adding templates as inline strings directly in the component code. It has the advantage that at runtime there is no extra HTTP request, but this method might not scale well for large templates
  • external templates: Templates can also be placed in external HTML files. This is cleaner and scales better, especially in a team with multiple designers and developers editing the same code. But, this will result in an extra HTTP request per template

As we can see none of the two solutions is ideal. Let's see if we can come up with a better way, but first, let's see how templates will be handled in the future.

The Solution for Importing Templates in the Future

What we need is a mechanism to import a file in TypeScript as a string. This already exists in SystemJS itself, but we are only using it to load scripts in the browser and not during TypeScript compilation. It also exists in Webpack, via the text loader.

For our setup, the ideal would be something like this:

import htmlTemplate: string from "template.html";

And then, we could use the template as a variable and pass it on to the component:

@Component({
    selector: 'your-component',
    template: htmlTemplate
})
export class YourComponent {
}

This functionality will be available in future versions of TypeScript, see for example this GitHub issue. So there is no indication that importing templates will be handled by angular-cli, this will simply be a new feature language of TypeScript (although angular-cli might provide an alternative, it's currently not clear).

But, what can we do while this is not available?

A Way of Handling HTML Templates

If the template of the component is small, the option remains to keep it inline. If the template gets too big, its possible to externalize it in a separate TypeScript file that exports a single string. In practice this looks like this:

External Angular 2 Template

Notice that the syntax highlighting and the autocompletion is still available even inside embedded strings. This is automatically the case in Webstorm. If by some reason HTML is not detected, it's possible to so manually using Alt + Enter inside the template.

The template (named test.html.ts) can then be imported via the following syntax, and simply used as a string:

import {htmlTemplate} from './test.html';

This has the following advantages:

  • This does not cause an extra HTTP request
  • The template is an external file, this scales better for larger teams and projects
  • Most of the IDE HTML tooling works correctly in the external file
  • This file can be easily migrated to a plain HTML file once Typescript "import file as string" functionality is in place

There is another important aspect of how to use the application in production: how to bundle our JavaScript?

A Simple Way to Bundle an Angular 2 Application

It might seem like something trivial, but once we have our plain JavaScript files in a build output directory, how do we prepare a bundle? We need to concatenate the files in the right order and this soon proves cumbersome.

Luckily, since Typescript 1.8, there is a simple way: we can configure the compiler to output the compilation result to a single file instead of separate files. For that, we just need to adapt our tsconfig.json:

{
  "compilerOptions": {
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "target": "es5",
    "module": "system",
    "sourceMap": true,
    "outFile": "bundle.js"
  }
}

Notice the value of the outfile property, it's a new compiler feature. With it, it's possible to generate SystemsJS and AMD bundles (currently, CommonJS is not supported).

In our case, this does not pose an issue, as we are using SystemJS. What we have with this is an output bundle of our whole application containing all the templates embedded inside it and ready to be loaded by SystemJS.

It would be just a matter of adding a simple gulp build to cache bust the file name and inject it on our index.html.

But, there are still a couple of loose strings to tie, and the biggest one is: how should we handle CSS in our application?

How to Handle CSS

Shadow DOM is not available in all browsers, but we can still import styles at the component level using emulated mode. This will encapsulate the styles to make them affect only the component by prefixing the style with a high specificity selector. Have a look at this example:

.button[_ngcontent-sxu-6] button[_ngcontent-sxu-6], .button[_ngcontent-sxu-6] a[_ngcontent-sxu-6] {
    text-transform: uppercase;
}

The problem is that without the appropriate tooling for generating source maps, this currently cannot be debugged (but it will be so in the future).

A Solution for Handling CSS

One manageable way to manage a project with a large amount of CSS is to simply include it externally as a link tag, this has always worked and nothing in Angular 2 prevents us from using it.

But to keep it manageable, a solid choice is to use Sass like the Angular 2 Material (the new Angular 2 widget library) project is currently doing, and like the Angular 1 version of the material design widgets does too.

The current version of angular-cli has Sass support, and the Angular 2 material alpha is already using angular-cli to handle their Sass/CSS.

There is a big chance that if you ever use Angular 2 material in the near future (note: the components can be used one by one), you might have to customize Sass files to adapt the widgets to your application theme.

The most future-proof path of handling CSS is to adopt the same pre-processor as the official component suite: Sass.

Using Sass in a Reasonable Way

Sass is very powerful and there has been a movement (PostCSS) to instead componentize each extension to CSS separately in a plugin architecture. So, for example, if we want a feature like CSS file imports, variables, or nested styles, we can add those in one-by-one.

One alternative is to simply use Sass but not abuse its many powerful features. For example, don't nest styles too deeply just for grouping them under a single component, it creates very long selectors. If inside another component you want to override the styles, you have to create a very long selector, with all the maintenance issues that it brings.

Doing CSS in a Structured Way

Complementing the use of Sass with a good CSS structuring methodology like Smacss is a good solution. The two are not exclusive, by the contrary it's very convenient to implement Smacss using Sass.

Using Sass Integrated With Angular 2

It's clear that further down the line it will be possible to use Sass easily with Angular, by simply importing .scss files in our component.

Then a build step will transform the Sass into CSS and generate the appropriate source mappings that will allow us to take advantage of the emulated encapsulated mode in a debuggable way.

But right now, a simple Sass build should get us going, knowing that in the future it will be easy to migrate it to the angular-cli pipeline.

How to Handle Internationalization

The final release of Angular will contain a working i18n solution, with an extended set of features. And, that is the advised solution for i18n in the long term.

We are not sure what the i18n solution will look like, but the translations will very likely be applied in a build step, and multiple versions of the application will be generated.

But if you really need to write an application, it's better to add translations from the beginning using a version of ng-translate for Angular 2: ng2-translate.

This has the same set of features that ng-translate has, which has been used to translate a very large number of applications in Angular 1. ng2-translate will cover the large majority of the needs of your application.

Conclusions

With a couple of simple methods presented above, it's totally possible to start developing an application and also have it running in production today.

By making choices and keeping the future in mind, it's feasible to set up a build and development methods that suit our immediate needs, while not preventing us from easily migrating to angular-cli in the near future.

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.

Topics:
angular 2

Published at DZone with permission of Vasco Ferreira C., DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}