I recently read Getting Started with Twitter Flight by Tom Hamshere. The book was published in October 2013. Another book was also published around the same time. To my knowledge, these are still the only two books about the Twitter Flight framework.
The book is very short; Chapter 1 marks 18% progress. There is nothing wrong with a short book. To me, it alludes to the simplicity of the Flight framework.
Furthermore, there is a bit of content dedicated to justifying choosing Flight for your next project. Again, I do not believe this is a flaw of the book. As developers, we want to know about success stories with a framework we are considering.
Tom does a good job of highlighting what Flight is and is not. For example, he brings up the fact that Flight does not have a data model system. He also points out the absence of an included templating engine. Better still, the author touts that these things are not “missing”; they are intentionally left out, and that gives you more flexibility to choose what works best for your project.
I really appreciate the author’s recommendations for event naming throughout the book. He takes this to another level by dedicating an entire chapter to the cause. Even if you disagree with the actual convention Tom shares, his points on devising a naming convention are spot on.
Mixins can be tricky to grasp for many. The book’s chapter on them goes into exceptional detail. In fact, Tom makes certain to answer questions a reader may not know will be on his/her mind soon after starting to use mixins. He tackles mixin order/priority, method extension, advice, and mixin composition (mixins within mixins).
Chapter 4 dives into setting up a Flight application. I felt this chapter was a little too tool-oriented. It aims the user at using Yeoman to generate the scaffolding of Flight pieces. I understand this approach makes for a very fast “get up and running” scenario, so maybe I am over-criticizing.
In contrast, chapter 12 discusses testing Flight components and mixins from a more agnostic view. There is a brief mention of the Jasmine-Flight and Mocha-Flight test extension projects. However, most of the examples show how to get at the necessary Flight objects in order to exercise them with assertions for any test framework. This is okay, but it does not fit the approach used elsewhere. I found it very odd to see a section on “Extending Jasmine for Flight”. The Jasmine-Flight project already does just that (and is referenced at the beginning of the chapter), so I do not understand the reasoning for this content.
Throughout the book, I spotted several mistakes with the code examples and corresponding discussions. Managing code for a book is not trivial, but I did expect higher quality for such a short book. Most of the mistakes were typos or names that obviously changed over the course of refactoring. However, a few of the mistakes are outright incorrect code bits. I read another review of this book where the reviewer stated he submitted errata that he discovered. Upon looking on the publisher’s website, I could not find any errata listings.
In the same spirit of errata, I do expect to see some attempts at upkeep for a technical book. By that I mean, as the framework changes, readers should really be able to see notes about areas of the book that are no longer relevant. How else will a newcomer make sense of the content when attempting to apply it to a later version of the framework? One simple example is the “defaultAttrs” property of a component. In a later version of Twitter Flight, the property was renamed to “attributes”.
A much more drastic example of this is with regard to the author’s opposition to the use of nested components. The author starts the book touting no “parent-child” relationships among components as a strong plus for a scalable architecture. In chapter 13, Tom details the problem with using nested components and how to get around their use. However, the Flight team recently released the withChildComponents mixin to handle just that; child/nested components. If you do some forum digging, you can even find that Tom had a part in a similar mixin when his team (of TweetDeck) created the withTearDown mixin internally and began probing the community for interest in open-sourcing it.
This is a perfect example where the author should come back to the book and make some amendments based on his own changes in viewpoint. I found forum posts about his team’s belief in the power of nested components since the book was published. That information is certainly worth knowing to a reader of a book that is just a little over a year old! At least add a note on the publisher site with a link to a blog article. Better still, revise the book as a second edition.
The “ugly” is named such because it is the part of the review where I offer my recommendation for or against this book. I also hate being on the fence.
Were there a better book available for the Twitter Flight framework, I would not recommend this book right now. I would not, because it feels like the book was published and never thought about again. I can live with the errors, although an errata list would be ideal. All the issues combined with the fact there are no amendments or notes about changes of the author’s views just add up to a total that is less than whole for me.
Since I have not read the only other book on Flight available, I cannot say with certainty that you should not read this book. Information on Flight is hard to come by; trust me on this one. Therefore, anything you can get is worth reading. However, be very mindful of the content; do some research, and try it out for yourself. You should be able to discern the gospel from the opinion if you are careful.