So you’re ready to take the plunge and develop your next project in Angular 2. Great! But, Angular 2 is just one piece of a larger puzzle. A key question you must answer as you define your Angular 2 architecture, is “which component and styling libraries should be used?”.
Here is list of choices that this post discusses (in alphabetic order). For a list from the Angular team itself see https://angular.io/resources/.
- Angular Material 2
- Bootstrap (with two flavors of Angular adapters)
- Foundation (not available until late 2016)
- Ionic 2
- React Native
Wow. That’s big list, and it’s not exhaustive!
New Angular Features
You may have wrestled with this question while using Angular 1. Be aware of some important changes with Angular 2.
A key new feature of Angular 2 is the separation of the renderer from Angular. While the most common approach is to use Angular 2 with a browser (and the DOM), you can now use Angular to present native components with tools such as React Native and NativeScript.
Components and View Encapsulation
One of the first things you’ll learn about Angular 2, is that the UI is made from a dynamic hierarchy of components. View Encapsulation allows you to decide if CSS scope should be local or global. Here’s an article to introduce you to the subject: https://scotch.io/tutorials/all-the-ways-to-add-css-to-angular-2-components.
Devices being Targeted
The biggest and most obvious factor is what devices you want to run on. Some choices are mobile only, some are web, and some are desktop (not web, installed desk top).
Naturally, you can also develop more than one presentation tier. For example, most likely you’ll choose to use one approach for mobile and a different library for web and tablet. You can share a lot of client code between the two. I’ll be expanding on this topic in a future post.
Know what you Know
Styling and component libraries are big. Consider drop downs, radio buttons, modals, tabs, inputs, date pickers, buttons, and on and on… Each library has a unique approach to each of the components. It just takes a lot of time before fingers go auto-pilot and developers are not bogged down reading documentation and looking for examples.
This tends to drive devotion to one library or another.
When selecting a styling library, consider the team that will be implementing the presentation tier and what skills (and biases) they have.
To increase your speed to market and manage costs, people are always looking for 3rd party components (commercial or open source) to give some nice short cuts.
Sometimes, you might find a perfect open source component, but it uses a different styling library. For example, if you committed to Angular Material, and then you find a Bootstrap module you want to use, you’re left in an awkward position.
Mixing CSS libraries can be treacherous and bloating, although the new view encapsulation may make this more feasible (but it won’t address bloat). If the libraries must exist in a global space, then you risk name clashes. If you can isolate them, then are they configurable enough to provide a seamless user experience?
No discussion of presentation tier choices is complete without a discussion of real native apps. By “real” native, I mean using Java and Android Studio for Android and Objective C or Swift and XCode for iOS.
The question of using a hybrid vs. native for your mobile strategy is very different if you already have a predictable and productive team pumping out native Android and iOS apps compared to starting from a blank slate.
Native developers will likely be resistant to hybrid, and if it ain’t broke, don’t fix it (it being your team’s productivity).
However, a pattern I’ve seen at many start-ups is that they have squeaked out an iOS MVP and Android is constantly being pushed back. Having made the native choice, the team rationally decides to get the iOS app more mature before investing in Android. Weeks, turn to months, months turn to quarters, quarters turn to years. No Android.
But don’t think hybrid is all roses. Be prepared for the write-once, debug everywhere syndrome. When you’re staring at a white-screen-of-death or head banging some bizarre iOS only bug and the hours are ticking by, you’ll be cursing the hybrid choice wondering how much time you’re really saving.
Now that Angular supports native renderers with tools like NativeScript and React Native, a new middle ground opens up that offers some advantages:
- Use the same client-side business logic implementation in your web, native Android, native iOS and desktop apps
- Develop a true native experience
A key question to consider is, “how much to invest in a native user experience for the next release?”.
iPhone users want their apps to look like iPhone apps and Android users want their apps to look like Android apps, or so the argument goes. On the other hand, my Gmail app on iPhone looks rather Material Design-ish and it doesn’t bother me.
How important is it for you to follow iPhone idioms, and to what degree? Should it just look good and be obvious how to use? To whom? How does that translate to your specific app features? What do you want to be consistent across devices?
Browser based hybrid apps tend to be a less snappy than their native counter parts and native apps can more easily access features such as keyboard control and pull to refresh.
How much extra time are you willing to commit your team to, to build functionality unique to each device and honing the user experience? Do you want to economize and define the layout just once in your early iterations? Is hybrid performance good enough? Can you damage your brand with an early release that makes too many compromises? What data do you have from your customer discovery efforts to inform this decision?
Minimalist vs. Broad Feature Set
Since, this post was first written, I’ve added Basecss and Tachyons to the list of considerations. Both prefer performance, elegance and smallness compared to large feature sets with Basecss being the leaner of the two. Neither have any particular features for Angular 2.
Discussion of the Choices
OK, enough naval gazing. What library should you use? I’ll walk through some choices and add my perspectives. I only have hands on experience with a few, and it is a rapidly evolving space, so comments are much appreciated and I’ll try to keep the post up-to-date.
Angular Material 2
Synopsis: CSS and directives following material design principals for mobile and web
Release Stage: 2.0.0 Alpha (as of November, 2016)
- Automates the implementation of material design principles (https://design.google.com/) which are very well accepted.
- Simple clean looking HTML markup with good responsive features to allow you to automatically adjust to different screen sizes
- It’s being made by Google who are hinting at an ambitious road map (https://youtu.be/bSssb9AmiJU?t=3067)
- With the development of progressive web apps (https://www.youtube.com/watch?v=wLWVASD0dvU) and increasingly capable browsers, you get a glimpse of a mobile future where you don’t even need Cordova
- It’s less popular than Bootstrap, so fewer developers know it and it could cause issues with third party components
- There are no specific features to easily look native
- And for balance, here’s a scathing post by an iOS purist: http://gadgets.ndtv.com/apps/features/sorry-google-material-design-just-doesnt-belong-on-ios-619799
A reasonable choice for “write once, run everywhere” or “web and Android” specific presentation tiers. You can package your app using Cordova, Meteor or others to install a mobile app version and manage form factor differences between web and mobile with responsive features. You can write platform branching in your code to address any high priority native motifs. (E.g. if you want the share button, to look different on iOS and Android, write code to make it so.)
Synopsis: A low level CSS toolkit
- Small and performant
- Could be more work. Bigger frameworks have more things prebuilt for you.
Bootstrap (ng2-bootstrap or ng-bootstrap)
- ng2-bootstrap (Angular 2 wrappers for Bootstrap 3 or 4) claims version v1.0. on github, but my experience is that it is more of a work-in-progress
- ng-bootstrap (another Angular 2 wrapper for Bootstrap 4) alpha release July 8, 2016
- Bootstrap itself (made by Twitter) is rock solid stable at v3.3.6 and version 4 is coming soon and (in my limited experience), is very stable
- Very popular and a staple on most front end developer resumes. Tons of third party components and style packages
- Good responsive design system
- ng2-bootstrap makes bootstrap JQuery free (but you can still choose to use it)
- Reputed to be slow and a poor choice for mobile apps, although it positions itself as “mobile first”
- ng-bootstrap and ng2-bootstrap are two parallel efforts creating confusion and diminishes interoperability of skills and components. Annoying that the teams didn’t collaborate.
Good for web sites. You could use it as economical “write-once, run everywhere” choice for an MVP for mobile (hybrid installable or web mobile). If you go this route, plan to replace the mobile apps with a better mobile presentation tier when demand forecasts warrant. The web version can be maintained and if/when you do migrate to something better for mobile, you can re-use much of your code.
Synopsis: Develop and deploy desktop apps using web authoring tools by packaging your app with a browser and node.js that gets installed like a normal desktop app and accesses desktop resources.
Release Stage: 1.0
- Used by popular apps like Slack. Even Microsoft Visual Studio Code uses it
- It’s for desktop apps and you’ll still need to decide on component and styling (e.g. Angular Material vs. Bootstrap vs …)
Cool! Develop desktop apps with web technologies! This could be a great choice for products that need both cloud and local processing.
Synopsis: One of the popular CSS styling packages, not yet serious about Angular 2.
Release: Nonexistent as of June 30, 2016
Foundation came up when I was researching this issue back in my Angular 1 days. Today, it is notable by its absence.
Synopsis: The leader in hybrid, Ionic is for hybrid mobile apps that automatically style your app to look native.
- Define your views and the platform automatically makes check boxes, tabs, etc. look like native. (E.g. iOS tabs are at the bottom and Android tabs are at the top automatically by default.)
- Simple concise mark up
- Access to native features like phone, GPS via Cordova plug ins
- Sometimes behaves mysteriously
- In odd ways, the current beta does not follow Angular 2 approaches. For example:
- the tab control won’t let you push data into the child components with @Inputs()
- NgOnChange is not fired and you have to use ionChange
- It uses its own router. (Perhaps it is better for mobile, but not obviously so)
- Form validation is different (e.g. it does not (yet?) support built in validation directives). This area has been changing in Angular 2 so perhaps it will change in the future
- Mobile only
- Not really native (slightly jittery scrolling sometimes, can be a little laggy compared to native. To be fair, these observations were made using Ionic 1.)
Use it to develop hybrid iOS and Android (and Windows mobile) apps that look more native. If you also require a web site, choose a different styling library for web and share as much code as possible. (More on this in a future post.)
Synopsis: A popular commercial library that supports Angular 2 and others.
Synopsis: Use Angular to program native components using a cross platform UI abstraction. No DOM, not HTML.
- Ability to access native APIs and handle iOS and Android differently when necessary
- Familiar Angular 2 approach (Component decorators, template micro-syntax, dependency injection) with a subset of CSS for styling
- I haven’t used it, so commentary is limited. I’d love to hear about people’s experiences
I can’t wait to give it a try.
Synopsis: PrimeNG is a collection of rich UI components for AngularJS2 (browser/DOM based)
This is a new one on me. Perhaps useful for migrating JavaEE Prime apps to Angular.
Synopsis: React Native (by Facebook) allows you to use native platform components to give your app a native look and feel. Paired with the angular renderer, it allows you to write apps that use native controls and the Angular framework. As with NativeScript, no DOM, no HTML.
Release: Alpha (for angular/react native renderer). Reactive Native and React itself are, of course, mature and widely used.
- There is less material, e.g. video tutorials, compared to NativeScript/Angular 2 (as of July 2016).
I can’t wait to give it a try.
Synopsis: Create fast loading, highly readable, and 100% responsive interfaces with as little css as possible.
- Small and performant
- More components than Basecss
- Could be more work. Bigger frameworks have more things prebuilt for you.
Synopsis: A commercial package that has basic controls and big components like Excel like spreadsheets and data visualization.
That completes the round up. Be sure to review https://angular.io/resources/ as this post is not exhaustive. I’ve added commentary where I have some personal experience to share and highlighted a few important options that I was interested to recently learn about.