AngularJS in Action - An Interview With Lukas Ruebbelke
AngularJS in Action by Lukas Ruebbelke is a hands-on book about AngularJS version 1. Through a sample ToDo list application, angello, it shows AngularJS’s architecture and components. With AngularJS v.2 Beta just being released, InfoQ spoke with the author about the lessons learned from the book and AngularJS present and future direction.
InfoQ: Could you compare where Angular stands with competing frameworks like React?
Lukas Ruebbelke: I think "compete" may not be the correct operative word. React is a great rendering framework that has a huge impact on how we approach data flow through our application. The insights that React brought to the table caused a lot of frameworks to take pause and examine how they were doing things. With that said, the Angular team has a very cordial relationship with the React folks and we love how they are pushing the envelope and bringing new ideas into the light.
This is actually a really neat time for frontend frameworks as I feel like we have moved on from the negative rhetoric of "this framework is better than this framework" and accepted that there is plenty of room at the table for everyone. The collaboration with the Ember CLI team is a great example.
To elaborate on your question in specific terms, React is focused primarily on rendering the view and it does that very well. Angular offers more by providing models, controllers, directives, animations, etc right out of the box. In fact, it is not uncommon at all to use Angular to handle the architecture of your application and then let React do the rendering within a directive.
InfoQ: What are your thoughts regarding investing the effort learning and developing in Angular 1.X vs. waiting for v.2 to come out? How has the direction of the project been throughout the past years with all the turmoil around v2 and v1 backwards compatibility?
Lukas: It really depends on your capacity for change. All of my new Angular applications are in EcmaScript 2015 and I break everything into directives which has a surprising parity to an Angular 2 application. Also, I used to favor factories and vanilla controllers but now I exclusively use services and the controller as syntax. This forces me into a syntax that is basically an EcmaScript 2015 or TypeScript class. With the right approach, the need to get this question right the first time becomes less critical. Converge on the architectural overlap and things will go much smoother. On a personal note, the new style has really grown on me.
The issue with Angular 1 and Angular 2 primarily was born out of the messaging. When Angular 2 was announced, it sounded like a massacre of everything we knew. People lost their minds because it sounded like there was no way to move from one version to another. The Angular team has since done a great job of clarifying this situation and in reality, there is a really sane upgrade path that makes sense. For instance, in Angular 1.5, they introduced the component syntax for declaring a component on the module which just makes it even easier to write Angular 1.x applications in an Angular 2 style.
InfoQ: Are you planning to start working towards a revision of the book to cover Angular v.2 when it gets released?
Lukas: I am already working on an expanded edition to further expound parts of the book while introduce a couple more chapters on new material such as testing. This will cover some of the architectural patterns that we can adopt that will transfer to Angular 2.
I have already started to create an Angular 2 version of Angello which is the sample application for the book. When the time is right, we will figure out the best way to share what we have learned in the process. I think have two versions of the same non-trivial application side by side would be a great learning experience.
InfoQ: Could you expand on Angular performance overhead and any areas that can provide performance boost in response times? (note: is one vs two way binding such an example?)
For example, you should avoid complex logic structures that have nested business logic and gets parsed in a procedural fashion. Period. Now hook that into the digest cycle of Angular and the problem is only compounded. You should avoid displaying 10,000 row on a page for the simple fact that a user cannot effectively process that information. It is not even feasible to get all that information in a single fold. Now add in data binding to every row and things just go haywire.
The first step when approaching performance in any application is to optimize the user experience. The next step is to apply tried and true architectural principles like composing your application with fine-grained, single responsibility units of code.
There are still some tricks that you can do to get that extra bit of performance out of your application if you need it. If you are binding to a collection of complex objects, I will sometimes transform those objects into a shallower version of itself that only contains just the properties I need to display. One way data binding is another great optimization if you are not going to need to redraw the view. Manually adding pagination to a large list of items also helps. Anything you can do to reduce the number and complexity of the items you are binding to on the page is going to help.
I recommend checking out the talk that Scott Moss gave at ngConf 2015 on performance. He hit a homerun with that talk.
InfoQ: How important is it to master promises in Angular for complex app development?
InfoQ: Would you recommend using Angular for animations?
Lukas: Absolutely! This is one of my all time favorites pieces of Angular. The reason being is that Angular does not actually handle the animations directly but rather exposes a set of event hooks that you can do your animations however you want.
InfoQ: What are the pros and cons of using it in modern web apps?
Lukas: I have been using Angular exclusively for over three years and in the pros column, I could go on for hours. You have a prescriptive place to put all the pieces in your app without being restrictive. Angular embraces the designer developer workflow by extending HTML and even giving you a set of tools to turn your HTML into your own DSL. Testing in Angular is encouraged because of dependency injection. The ecosystem and community are phenomenal as well.
The only cons that I can think of is a few edge cases where you need to do something really custom like a game or some kind of crazy 3D rendering and Angular may not be a great choice to do everything in that case.
InfoQ: Mobile first and mobile development is gaining grounds in the past years. How easy is it to transition from Angular to mobile frameworks based on it (Ionic/Mobile Angular UI etc)? What is your advice regarding mobile development and Angular?
Lukas: You almost get mobile development for free with Ionic. I am privileged to be good friends with the Ionic team and I asked Adam Bradley one time how to become an Ionic expert. He told me that to become an Ionic expert I just needed to become an Angular expert. This has proved to be my experience time and time again.
Another awesome project that does really well on mobile is Angular Material. You get all of the power of Angular with all of the aesthetics of Material Design. Every component plays so nice on any device or screen dimension.
I feel really spoiled in this regard. The line between desktop and mobile have become so blurred as a result of Ionic playing so well with Angular.
InfoQ: What are your future plans regarding writing and involvement with Angular?
Lukas: I love Angular and am probably one of the biggest cheerleaders of the framework. The team is one of the most talented group of individuals that I know and yet they are so gracious and kind. Based on character alone, I am proud to be identified with the project.
I have pages and pages of ideas for Angular content and projects that I will get to someday. Somehow.
About the Book Author
Lukas Ruebbelke is a full-time web developer and an active contributor to the AngularJS community.