This post is the 1st part of the “Angular 1.5 from the trenches” series, presenting the architecture of a component-oriented, “NG 2 ready” Angular 1.5 app we’re building.
module.component()method, introduced in Angular 1.5, may seem only a cosmetic addition, but the approach it promotes (and which we utilise to the full extent) results in a very different flavour of architecture than most of the “classic” Angular tutorials describe, so I hope you’ll learn a thing or two from our experience.
Table of Contents:
- Starting a new app in Angular 1.5 – does it make sense? [THIS POST]
- Angular 1.5 app as a tree of components [COMING SOON]
- Communication between Angular 1.5 components (and with the API) [COMING SOON]
- A flexible Angular 1.5 project structure (the “fractal” architecture) [COMING SOON]
- Writing Angular 1.5 project in ES6/ES2015 [COMING SOON]
- Unit testing Angular 1.5 components – a detailed guide [COMING SOON]
- E2E testing of component-oriented Angular 1.5 app [COMING SOON]
At the beginning of the year (mid-January) we were starting a brand new, greenfield project. We faced an important decision: in which version of Angular should we build it?
With the Angular 2 beta just released, and the Internet all the rave about “now being finally the right time” to consider building production apps in NG 2, it was surely a tempting option. On the other hand, with Angular 1.5 release candidate available (and the final 1.5.0 version lurking just around the corner) it seemed an interesting alternative.
We were torn between two choices:
- Should we “future-proof” ourselves, but endure all the pains of Angular 2 infancy?
- Or should we stick to the mature 1.5 version, but cope with the migration to NG 2 in the future?
As you can guess from the title of the series, we’ve finally decided to go with Angular 1.5.
To understand our decision, we must take a look at the state of both frameworks as well as the background and abilities of our team, and the requirements of the project.
- Mostly no prior Angular / modern JS ecosystems experience (so availability of good learning resources was an important factor for us).
- Coding starting in mid-Jan 2016 and the 1.0 release in mid-April (so we had no room to wait for the necessary tools to mature in the course of the project; we had to be sure that all the technologies and resources we need are available and production ready from the get go).
- Internal back-office app (so availability of a robust UI component library to speed-up the development was a crucial factor for us; of course, there are plenty of such libraries, but we wanted something well integrated with Angular out-of-the-box, so we wouldn’t have to waste time for wrapping UI components in NG directives on our own).
Although being regarded as stable enough to be used in production, at the time of our decision Angular 2 still had some deficiencies:
- Incomplete documentation (especially testing guides, which was a major drawback for us, as we use TDD extensively).
- Very young ecosystem (very few project boilerplates, yeoman generators, blog posts, books, style guides, and so on).
- No integrations with UI libraries (all the “major players” in this space, like Angular Material, Angular UI etc. were just starting with NG 2 migration and definitely not ready for production use).
- Some parts of the framework (e.g. animations) being still a little in flux.
In effect, although NG 2 core indeed seemed to be ready for production, the surrounding ecosystem did not.
Although reluctant to invest in an aging technology, especially for a new project, we still saw some strong arguments for going the NG 1.5 route:
- It enables component-oriented architecture very close conceptually to the one of the Angular 2 (more about designing NG 1.5 app in a component-oriented manner in the following posts in the series).
- Despite the seemingly huge conceptual shift, it is still good old Angular 1 under the hood, so it integrates seamlessly with the rich NG 1 ecosystem of tools and libraries.
- A lot of effort seemed to be put by the core team and the Angular community to make upgrade path from NG 1.5 to NG 2 as easy as possible, so our biggest fear – locking ourselves in to a legacy technology – was alleviated.
These observations tipped the scales and we chose Angular 1.5.
Insights after 3 months into the project
- The learning curve regarding component-oriented architecture and how to test NG 1.5 components (more on how to test components in one of the next posts) was a bit steeper than we hoped for. Such architecture is very different than a “traditional” Angular 1.4 architecture and the learning resources are sparse (that’s one of the reasons I’m sharing this series). However, the situation isn’t much better regarding NG 2 as for now, so I don’t think choosing NG 1.5 made this any harder for us. The key thing for us was to “reach outside” and learn from other component-based frameworks like React.
- On the other hand, learning curve regarding Angular APIs and various implementation-level details was much flatter. There is an almost endless abundance of high-quality NG 1 learning materials – we would have much harder time learning NG 2.
- We’re less than a week from our planned release, and the Angular 2 ecosystem still isn’t mature (for example, there is still no production-ready version of any of the major UI libraries available for NG 2). So, in retrospect, it was a good decision not to rely on NG 2 ecosystem to mature in the course of our project.
- Diving fully into a component-oriented architecture was a correct decision. Although NG 1.5 allows to utilize components in as narrow scope as you want, allowing any compromises here would make future NG 2 migration much harder (it would require a big mental shift and a major architectural refactoring). Also, a lot of what we would have learned would go to waste.
- We haven’t migrated to Angular 2 yet (it is still a bit too early for migration considering the current state of NG 2 ecosystem), so the direction we’re following and our assumptions regarding how easy the migration will be are still not validated. However, from what we see observing how Angular 2 develops, it looks very promising.
NG 1.5 is still a viable option for a new, greenfield app, but you must be very careful about how you design your architecture. Go fully into the component-oriented approach and you should be fine (check out other posts in this series to see how we do it in our project).
NG 2 may be a better option if your release date is further in the future (so you have more room to wait for the ecosystem to mature) or if your project is huge (so you’d have a ton of code to migrate later) – we’ll most probably go with Angular 2 for our next project we plan to start somewhere around July. But for something smaller and quicker it is probably a bit too early to jump head first into NG 2 – and NG 1.5 is a very good temporary solution for such an app.
Over to you
What do you think about starting an app in Angular 1.5 vs Angular 2? Do you have any first-hand experience? I’d love you to comment and let me know!