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.

AngularJS Testing Frameworks – Mark Katerberg – Angular Lunch

At our September 9, 2015 Angular Lunch, Mark Katerberg compared the different testing frameworks with AngularJS 1.x. He shows and explains the differences between Jasmine, Mocha and associated libraries, and how they compare for Angular application unit testing.

If you don’t have time to watch it, here is my super-high-level summary:

  • Karma+Jasmine is a solid, very usable default. It is also what we use here at Oasis Digital frequently.
  • Mocha and its associated libraries are more popular for server-side testing, and have certain advantages if you are willing to learn and adopt them.
  • QUnit is most appealing to those already familiar with an older generation of testing tools, but also has completely acceptable features for modern unit testing.

But don’t take my word for it. Watch the talk video, Mark has compared all of these and more.

Transcript

We have transcribed the talk about to text, provided below. This is a rough, first-draft transcription, so any errors are probably from that process.

Continue reading AngularJS Testing Frameworks – Mark Katerberg – Angular Lunch

Angular 2 Observable Data Flow

(The usual warning: This is code from a couple weeks after Angular 2Alpha 45 – if you’re watching this months later, things may have changed!)

A few weeks ago at the Angular Connect conference in London, the core Angular team presented on the new Observable data flow and related concepts available and under development in Angular 2. Sharp-eyed viewers have tried to copy the code they presented and run it, but found that it does not actually work yet. But not all hope is lost, and it is not necessary to wait. As I write this at the beginning of November 2015, it is possible to run and see the exact kind of demo they presented, in action.

 

In this video, I present the running code, and explain it (as best I understand, keeping in mind that many of the relevant pieces are not yet documented…) line by line.

 

First Angular 2 Class Completed

Today we finished teaching our first Angular 2 class. This was our “Early Start with Angular 2“, a special, preview two-day version of what will soon be a three-day class – or perhaps even longer. This was an “alpha” class, using alpha materials, covering an alpha product, but in spite of that it went well. More importantly, it gathered positive reviews from the students, several of whom commented that the class answered important questions they had and other questions they didn’t even know they had, about Angular 2.

Paul Spears and I (Kyle Cordes) taught this one –  In the coming months our other instructors will be getting up to speed on the new technology also.

Angular 2 is a considerable step upward in terms of learning curve compared to Angular 1. This is because it is built on more powerful abstractions and libraries, most notably RxJS / ReactiveX / RxNext. As always, if you’re looking for help learning or adopting Angular (1.x or 2) please contact us. We have two more Early Start classes, then after that we will teach the full three-day version.