Fast Angular 2 compile cycle with TSC

There are numerous choices for tooling in a TypeScript Angular 2 project. This list is no doubt incomplete:

  • SystemJS with JSPM
  • SystemJS without JSPM
  • Webpack
  • Angular-CLI (which uses System and Broccoli and other things behind the scenes)

(Warning – this content has been made obsolete by progress in Angular 2 and related tooling.)

At Oasis Digital, we have worked with all of these variations, and experienced trouble at least with all of them but have been around long enough to have trouble with. There is no clear winner yet, there are only trade-offs.

Speed matters. Specifically, speed of the development cycle, of how long it takes to compile/recompile an application and reload it in the browser during development. (I’m less concerned with the speed of a “production build” because those happen much less often and usually without a human actively waiting.)

As of May 2016 (these things change rapidly) we have found the following yields the very fastest results for the development cycle:

  • Bundle libraries using JSPM/System-Bundler or WebPack, or use bundles shipped by the Angular 2 team.
  • Set up tsconfig to use “module”: “system” and “outFile”: “somebundlenamehere.js”. TypeScript both compiles your code, and produces a single-file bundle of the results. This is much faster than having typescript emit numerous files and then bundling them with another tool.
  • Run tsc in your IDE; don’t bother to “watch” from the command line or by other means – better for compile errors to land in the IDE. There is no benefit to simultaneously compiling in your IDE and in a concurrent “watch” – omitting that (for example, by moving away from Webpack) roughly cuts in half the total CPU effort spent on each development cycle.

To demonstrate how little work is typically needed to set this up, see the following tiny “fork” of the angular.io “quickstart”. This single commit shows the slightly less configuration needed with the “module”: “system” approach.

https://github.com/kylecordes/quickstart/commit/3cf3041dd80ee8701a3cffb0cbe6264784017a2b

Of course, there is no benefit to this change in the quickstart application – the tutorial adds only a handful of components. But we have confirmed the performance lead with other teams developing on Angular 2 “at scale”. This approach is, as of May 2016, the fastest compile-reload cycle for large Angular 2 applications.

It might not last long; there are many efforts underway, including the official angular-cli, to build better development tooling. Moreover, Hot Module Reloading might make speed up the development cycle enough that the clean-reload time isn’t important.

Angular 2 and the rise of the Elm / Redux architecture

As I write this in April 2016, Angular 2 is in beta (with a recent comment from Google about a release candidate coming soon), and while it is still early days for production Angular 2 use, we already know of a number of projects (including here at Oasis Digital) heading rapidly in that direction.

Looking around the Internet, listening to the podcasts, reading the blogs, watching the GitHub repositories, we have seen a surprising early emergence of an architectural preference with Angular 2. Here is our expression of this preference, I’m sure a group of thought leaders could gather and each would have a different take on it of course.

In a complex Angular 2 SPA:

  • Avoid the “bucket brigade” of data binding business domain data one component at a time across an application component hierarchy. The new syntax makes each step of the bucket brigade tidy, but still ultimately error-prone and tedious. One binding is good, a series of bindings one to the next is not.
  • Avoid unmanaged state floating in a bunch of stateful services (classes) – now that it is easy and fast to create these as plain classes with Angular 2, it is also easier to create a complex enough system that unmanaged state leads quickly to slow, error-prone, complex development.
  • Use RxJS heavily. There is some dispute around the web as to whether RxJS is the most ideal implementation of reactivity, but it is emerging as the most popular, and the one most similar to an upcoming likely standardized API.
  • Adopt the Redux / Elm architecture, coalescing all application state to a central (but hopefully well-modularized) data store, mutated only by the processing of actions using reducers.
  • The early leader as the “glue” to do the above in Angular 2 is ngrx/store.
  • Test essential logic at that central state.
  • If you happen to be using a Node backend, it it very easy to share data structure definitions and UI-free application logic between client-side and server-side code. Do so as needed.

We have adopted this architecture where suitable, we see lots of activity around the web which indicates others are adopting something similar. This approach generally is likely to emerge as the dominant approach in complex Angular 2 development. Further, it appears to be part of a growing trend across a variety of SPA libraries/frameworks. Whether using Angular 2, AngularJS, React, Cycle, Vue, OmNext, etc., this idea of state separated from UI logic is compelling.

(Conveniently, here at Oasis Digital, we are deeply familiar with CQRS/ES, and this Elm/Redux architecture echoes quite strongly of that.)

What does this mean for Angular 2 development? I think most likely it means: the differences between Angular 2 and its competitors are growing less important. If you are managing state in a centralized, decoupled manner anyway, the choice of UI / view layer becomes more a matter of development preference than before. This is a tremendously positive development.

Writing AngularJS 1.x Application to Prepare for Angular 2

How should AngularJS 1.x be used, to make things easier (as easy as they can be…) if the time comes to port an application to Angular 2? This is a frequent topic of discussion at our Angular Boot Camp classes, which are still quite popular (in early 2016) for AngularJS 1.x even as Angular 2 grows close to release.

We often have students or private class managers ask that our class cover this topic, but they really don’t even need to ask. Over the last 6-9 months we have revamped our curriculum and approach to teaching AngularJS 1.x to pervasively answer aspects of this question. Here it is, in a more explicit summary:

  • Build your application mostly from components. If you are able to use 1.5 right now, go ahead and use the new .component() API extensively. If you are stuck on an older version, use component style directives. Regardless, mostly follow the component pattern, only reach for a standalone controller or template in rare cases.
  • The migration tools coming from the core team are about migrating from 1.5 forward, not about older versions; so if you have an application built on an 1.4, 1.3,, or even older, now is a good time to move past whatever is stopping you from upgrading to 1.5. There are numerous other benefits to upgrading also, each incremental version of AngularJS 1.x has improved performance and other areas.
  • Make your components mostly push data downward using data binding.
  • Make your components mostly push information about things that happened upward, mostly using “&” hooks (the closest thing in A1 to A2 events).
  • Mostly use the A1 features data binding, to avoid needing to write things like manual $watches. We have found at Oasis Digital that nearly every manual watch can be removed and replaced with data binding, letting AngularJS itself watch (and stop watching when appropriate) an expression instead.
  • Minimize or avoid the A1 scope event system; use it only in very unusual cases. There is nothing like it in A2, and even in A1 it is of limited utility with a component-centric approach. Those isolate scopes will stop events anyway. We typically use the scope event system only for things like talking to APIs which are exposed in that way (like route change notifications).
  • Consider TypeScript, today, even on AngularJS 1.x. Here at Oasis Digital, we have done this and been very pleased with the results. We have found and fixed numerous bugs with the help of the type system, which otherwise would have been fixed later and a greater expense and risk, with testing or with production failures.

An application built in this way (and following some other things that I have overlooked) is ready to walk the Google-sanctioned migration path, mentioned from conference stages by Google team members. First make old code look more like Angular 2 (ng-forward), then put Angular 2 on the page alongside AngularJS 1.x (ng-upgrade), then convert components one at a time, then eventually remove AngularJS 1.5 from the page.

Sometimes Reality Is In The Way

We have worked with numerous teams working on numerous medium and large AngularJS applications; and sometimes the reality is not so compatible with the idealized path described above. For older, large AngularJS 1.x projects, the upgrade path might actually look something like this:

  1. Rewrite your AngularJS 1.x application, to follow 2015/2016 best practices, instead of the 2012 practices it is built with.
  2. Then you can follow the recommended upgrade path to make it a Angular 2 application.

Obviously this is not an especially appealing path. We believe there will be many large AngularJS 1.x projects that simply remain in that framework for a long time to come; and this is okay, a working application does not necessarily need to be rewritten. For many applications the path to the next framework (whether that be a newer version of Angular, or one of the many competitors) is to write the replacement application far in the future, in that new framework.

For that reason and many others, perhaps the best advice is this: don’t write huge applications at all. If you have a problem space which appears to warrant a huge application, think about it carefully and divide it up into several cooperating medium-sized applications, which might appear as one from a user point of view but which are not entangled with each other technically more than necessary. With such a system design, if the day comes that it will be moved to another framework/library (Angular 2, React, Vue, Mithril, Elm, Ember, Reagent, Om, I could go on…) you have the option of converting a portion of an overall system at a time. This is both faster, cheaper, and less risky than migrating a gigantic monolith all at once.

 

Is Angular 2 Production Ready? Yes (*)

As of March 2016 (Angular 2 beta.11) the answer is yes… or rather, yes*.

Google offers an existence proof. The Angular project leaders at Google have stated publicly (I most recently heard it on a podcast) that Angular 2 is already in production on significant projects inside Google. They mention a project with size information: around 100 developers, hundreds of components, thousands of users. It is a CRM system – they did not describe its features, but we can safely assume that it has the sorts of things you typically see in a CRM system.

(They also mention that a new version of the Adwords advertiser interface is in development in Angular 2, with a much larger team team, intended for a vast user-base, right at the heart of how Google earns money – but this project is not yet in production.)

Now for some caveats:

  • The Angular team was talking about internal applications – which usually implies loading over a fast network, so payload size is not very important. As of March 2016 the payload size of Angular 2 is still quite large.
  • Google’s large Angular 2 projects, at least the ones mentioned, are coded in Dart, not TypeScript, so they benefit from the more straightforward tooling for Dart. In fact, this makes me wonder if we should consider Dart. So far we have not, as it appears the development community is far more interested in TypeScript.

Oasis Digital’s Experiences So Far

Here at Oasis Digital we are building software for customer production deployment in the coming months, in Angular 2. We also have a large swath of Angular 2 training materials for Angular Boot Camp (already teaching Angular 2 classes). To further get our feet wet, we have even built some of our recent public-facing web properties with Angular 2 – but temporarily accepting the large payload size, assuming the size will come down before becomes a priority for us. We’ve also met teams at other companies building at scale in Angular 2.

From this experience, here are more caveats about heavy development or production use:

  • We work primarily on business applications where deployment payload size is not such a big deal… but extensive functionality is vital.
  • There has been quite a bit of churn over the last few month. Keeping up with the churn in a stack of alpha and beta tools, can use up quite a bit of time. Here at Oasis Digital we can justify it because we invest this time building up our expertise, to teach classes. It could be harder to justify an organization only building applications, looking for a stable and finished platform.
  • The developer experience has some critical rough edges. Unlike the competition over at React, Angular 2 offers no compile-time help with either the types or the names of any data that passes through templates. For now we recommend limiting exposure to this by moving data almost entirely outside of the template system, using it only for tableting and not for binding our components to each other more than necessary. There are other great options (Elm/Redux-like architecture, injection, Observables) for data flow. (WebStorm now offers a degree of development tool support for Angular 2 templates, though that doesn’t remove the need for Angular 2 to support it natively.)
  • Browser supports isn’t very complete yet – some built-in Angular 2 features (like most of the Pipes) are broken in some common browsers, though the problem can be patched with a polyfill.
  • The build/package story is rather rough:
    • Webpack is mature, but using it in development on a sizable angular 2 project is quite frustratingly slow, on Windows especially.
    • JSPM offers an alternate future-oriented approach, with the frustration of installing most packages twice: once via NPM so that TypeScript can see them, once via JSPM. so that the bundler can see them. This irritation may go away, if TypeScript becomes more configurable, or becomes aware of JSPM out-of-the-box.
    • A third approach, which seems most practical for today, is to use SystemJS but not JSPM, then use the pre-bundled Angular 2 and related packages, and perform TypeScript compilation with the –outFile option. This means minimal moving parts during development, and faster recompilation. It also makes it possible to perform TypeScript compilation in your IDE for error checking, and use that same output (rather that throw it away and compile it again via a bundler plugin) to execute in the browser.

Ready Enough

Angular 2 is ready enough to use today, to build applications at scale for production deployment – but be aware of the need to allocate ongoing technical effort to keep up with things.

 

OLAP/BI as a system component

There is a thriving market, of software makers, system integrators, service firms of all kinds, and so on around OLAP and business intelligence. This market got a lot more attention 10 or 20 years ago, when the work was primarily done by specialist firms. But OLAP has not disappeared, rather it is become “table stakes” and most firms of enough size inevitably have ongoing analytical data projects that decision-makers rely on – even if some are rebranded to sound newer.

Oasis Digital is not such an integrator; we don’t resell or service any OLAP tools. We don’t do pure business intelligence off-the-shelf deployment projects. But we do touch these tools in another way.

Rather, at Oasis Digital we see OLAP / BI / ETL tooling is a system component that can be used “behind the scenes” to create software features and systems quickly and effectively. We are perpetually on the lookout for desired custom software feature requests which are best implemented by feeding the data into an OLAP system then querying that system for display in the custom software.

You can read a case study about a recent project we did, where this came into play. Those with BI experience may recognize some of the screenshot snippets as presenting OLAP data in a custom UI.

Although most any OLAP tool can be used for this, more than once we have chosen Mondrian or one of the tools built atop it like Pentaho. This open-source approach can make it possible to add OLAP engine technology behind the scenes even in software which will be redistributed or installed many times, without invoking the per-server costs of a commercial OLAP engine deployed to numerous servers or bundled in a shipping product.

Angular 2 – Staggeringly Ambitious

By now, most readers know a little about the motivations and features of Angular 2.0. Here I recap them briefly, these are ideas I have seen Angular team members say in conference talks, mixed with others I have inferred.

  • Performance, and design/API changes needed to achieve it.
  • Accommodate the changing web development environment, including Web Components.
  • Embrace JavaScript / TypeScript / Dart progress.
  • Replace Angular-specific features with web platform features.
  • Dynamic Loading, especially for faster mobile startup.
  • Easier learning curve, though it is unclear how well this will pan out, given the large pile of dependency technologies.
  • Scale up to complex applications effectively.
  • Excellent tooling support, which again helps scale up development teams.
  • Server-side pre-rendering – SEO Friendly and mobile friendly.
  • Server-side template compilation (as a build step), for faster application start.
  • Leverage web workers – ideally this will be trivial, for use in almost any application.
  • Leverage RxJS, make it nearly as easy to create an end to end real-time/reactive system, as it was to create a old-fashioned manual-update application with the older tools.
  • Retain the large-scale corporate development appeal which AngularJS 1.x has enjoyed.
  • Keep up with the competition! React, for example.

Putting all this together, my assessment is that Angular 2 is staggeringly ambitious. Not for any one goal (most of the goals and features above, are present in at least one competitor); but rather, it takes ambition to combine all of the above into one framework, then to drive that framework to completion fast enough for all of these things to be of current interest.

But, will it work?

At Oasis Digital we have been following the Angular 2 alpha versions for months now, and we have multiple applications underway on Angular 2. We know customers who are already deep into production application development on Angular 2. We have taught “early start” classes on Angular 2, and have our curriculum well underway to teach full-length “boot camp” classes. We were thrilled to see the beta version ship earlier this month.

From all the above, and studying some of the competition as well, it seems likely that Angular 2 will achieve its technical ambitions.

Hazards

There are some risks and challenges facing the Angular 2 team, they are well aware of these and working hard.

Size: So far, as of beta.0, Angular 2 has surprisingly substantial code size. There is work underway to trim this, but the extent of success is to be determined. Code size might be the unavoidable cost of ambition.

Dependency size: Angular 2 has mercifully few dependencies, but one of them (RxJS “RxNext”) is important, powerful, and large. This can be minimized by including only the pieces of Rx that a given application actually uses, but a complex application written using Angular 2 and much of RxJS will, unless things change greatly, end up with a big total code size.

Development pace: because Angular 2 is so ambitious and large, it has also taken a while to build. The competition has not stood still, so there is risk that by the time Angular 2 is fully out the door, it may have fallen behind in some key area. This risk is much more well-managed now that the product is in beta.

Innovation: There are other alternatives out there, radically different and with some chance of being radically better. Imagine if, for example, something like Elm were adopted by one of the major technology companies.

Style and preference: for good reasons, Angular 2 has a split between code and template. This design choice has served version 1 very well, and while there are technical reasons to choose between a code/template versus an all-code, that choice is also to a significant extent a matter of style, preference, and fad. If the prevailing preference moves toward and all-code approach, this could be a challenge to Angular 2 adoption.

Place Your Bets

There is no sure thing, and there are significant unknowns and hazards. But I will step out on a limb with the following (scoped) prediction:

For “enterprise” applications, which primarily run behind a firewall, contain extensive functionality, and are developed by large teams, Angular 2 will turn out to be in the top two JavaScript frameworks over the next five years.

 

Expert Angular Developer-Trainers Wanted

Here at Oasis Digital, a sizable portion of our work revolves around AngularJS and soon Angular 2: writing software, reviewing software, consulting, teaching classes. Our Angular classes are described in detail at AngularBootCamp.com – as you can read there, our classes are taught by professional, expert developers.

Our Angular classes have proven quite popular – to meet our customers’ needs, we plan to hire additional developer-instructors.

Requirements

  • Extensive experience with AngularJS, deep familiarity with a broad range of its features.
  • Work history predominantly as a software developer and leader.
  • Experience presenting to groups of people: in a classroom setting, in technical talks, or similar.
  • Interest in teaching.
  • Experience with a broad range of software technologies, on both the client and server tiers. Our training engagements sometimes include a consulting element, working closely with our customers’ developers to understand how Angular fits into their overall solution.
  • Availability for travel to customer sites, etc.
  • The usual legal requirements, such as the right to work in the United States (and possibly elsewhere)

Full-time or Occasional Contract

Our classes are mostly taught by our full-time developers. If another developer/instructor joins us full-time now, they would need to be ready for a busy teaching schedule (though still leaving time to write software).

We also welcome applicants currently working as independent AngularJS consultants/contractors, interested in teaching classes from time to time. Such contractors would also need to devote time to interact with our core team, to build the shared deep understanding of Angular that our customers have come to expect.

Contact us

If this sounds right for you, please email us – see our contact page. Even if you are not ready to jump in right now, feel free to get in touch about the possibility of future work.

 

Online vs In-Person Classes

Earlier this year, we started offering some of our classes (most prominently Angular Boot Camp) online as well as in person. We intentionally waited to offer an online option until our classes were well proven as live, in-person events, with the goal of making the online experience capture as much of the quality from the personal event as possible.

Many prospective students have emailed or called us to ask about the trade-offs between the in-person versus online options. Here are our thoughts.

Hands-on Workshops

Our classes offer and include lots of hands-on experience, pausing after every few units of teaching for an exercise. During in-person classes, our instructors walk back and forth around the room, keeping an eye on everyone’s progress and offering assistance. In offering an online experience, we were concerned about how well this aspect of the class would transition, and explored numerous approaches to capturing this experience online.

Our solution is to invite each student to use a “cloud IDE” to perform the exercises, and then to make their cloud workspace available to our instructors. Using this approach, we have found that (surprisingly) our ability to assist students during workshops is possibly even better online than it is in person. This is such a compelling result that we sometimes even persuade in-person students to use such an online IDE.

Interactivity

An in-person class can be highly interactive, and ours are especially so, because all of our trainers primarily work as practitioners – question-and-answer is our specialty. So far, students have been very pleased with the level of interactivity in online classes also. We keep a chat room open during online classes, to make it especially easy to interject a question; in fact sometimes it is even a bit easier to ask a question in an online class, because the student can always do so without risk of interrupting the instructor, and instructors can look back at the online chat record to avoid skipping over an important question.

On the minus side, back-and-forth discussion is slightly less fluid online; so overall is probably a wash.

Long, Hard Questions

At in-person classes, our instructors often engage in deeper side conversations about long or difficult questions during breaks or before class. This does not work as well online, so if you have a lot of hard questions, an in-person class is probably the better option.

Depth and Breadth

Given the same total class time, we typically cover slightly more material in our in-person classes. We don’t have a metric to say whether this is a trade-off with the depth of coverage, or whether it is a consequence of slightly more time-consuming transitions between lecture and workshop, around breaks, etc. with online classes.

Overall Results

Overall, we estimate that our online classes are at least 85% as good as “being there”, and possibly up to 95 or 100%. We encourage students to choose between the two options based primarily on their own travel availability, timing, etc.; we have plenty of satisfied students for each.

 

Angular Firebase Observable – Simple Weather Example

In preparation for Angular 2, we have been digging into its capabilities extensively. One of the most interesting areas is around Observables, as mentioned in a blog post and video a couple of weeks ago. Here is more along the same lines, this time using Firebase.

Source code:

https://github.com/OasisDigital/angular2-firebase-observable-weather

This is intentionally a relatively straightforward and simplistic example – it uses Firebase, but you are unlikely to see any data change in “real-time”. Rather, the point of this example is that even when not expecting data to change, with Angular 2 it is hardly any more work to implement “push” updates.

Creating a 3D Configurator with ThreeJS

(Maneesh Tewani was a summer intern at Oasis Digital in 2014, and returned to lead the Summer Intern Program in 2015. As of this posting, he currently attends Purdue University. Maneesh recently wrote this technical description of a 3D project which was started by interns, and first documented, in 2013.)

Introduction

“Swingset” is a custom rules-based configurator. It allows users to customize their own swingset given a set of options to choose from. When an option is selected, the change can be seen on on the 3D swingset shown.

swingset-1

The web app was built primarily using HTML, CSS and JavaScript. Alongside the JavaScript we utilized JQuery, AngularJS and ThreeJS. JQuery is a library that provides extra tools in selecting and manipulating HTML and CSS. Angular, its counterpart, is a popular framework that allows manipulation of the DOM driven by data-changes. ThreeJS, which utilizes WebGL, was very important in this application. WebGL allows 3D rendering in the browser and its framework allowed CPU-Intensive tasks to happen without very much CPU usage.

swingset-4

Build Tool

Swingset uses Broccoli.js, a build tool provided by the npm registry. Broccoli is very similar to Grunt and Gulp. Instead of working with “globs”, Broccoli has its equivalent “trees”. Initially we believed Grunt.js was the ideal choice, but as time progressed, we experimented with new tools and picked up Broccoli. Our use was relatively simple: process all our files, move them to a directory, and serve them statically.

Broccoli served this purpose very well. For example, Broccoli is known for its automatic “watching” feature. Watching is when a build tool keeps checking a specific directory for changes such as updates, additions and removals. This is very useful because as developers are writing code, they want to see the changes live on their local server. This can usually be quite a hassle, but Broccoli has this unique feature built-in.

swingset-3

Node.js

Node.js is a tool that allows you to write server-side code in JavaScript. It comes prebuilt with NPM, which unofficially stands for “node package manager”. NPM allows you to easily deal with server-side dependencies. Without Node you can’t have build tools such as Broccoli or Gulp.

Directives

Directives are a key feature in AngularJS. Directives allow you to take a common snippet of code and extract it for future use. Directives are represented by their names and every instance of one represents a template or HTML code. Directives are very flexible and therefore can be used practically anywhere.

ThreeJS

One of the most important components of the application is the scene. The scene consists of the swingset and the components around it. The main parts of a scene are the position and lighting, in addition to any object you would like to add. In our case, that was the swingset optimized with different textures laid upon it.

The model directive sets up ThreeJS model to make the 3D swingset appear. First, an ObjectLoader is initialized with an image. Next, a scene is created with the image and a camera as well as multiple types of light. Then, the controls are created that allow the user to manipulate the scene/view. The renderer basically renders the scene along with the controls, lighting, etc. Upon initializing, a Canvas HTML element is returned. In our case, most of the boilerplate code was written in the directive. So, we append the canvas element to the directive element.

An ideal part of this was updating the scene to match the user’s selections. This was where we used AngularJS. As everything was set up, many variables were bound to the scope, meaning that as anything on the scope changed, the corresponding changes would be provided to ThreeJS.

 

Dependency Injection in Angular 2.0 (alpha) – Angular Lunch

Another in our series of Angular lunch talks. Paul Spears walks through dependency injection in Angular 2.0. This covers an alpha version, the details could easily be different when the real thing ships. Recorded 2015-09-15.

Transcript

We have transcribed the talk to text, provided below.

Continue reading Dependency Injection in Angular 2.0 (alpha) – Angular Lunch