Paul Hammant's Blog: UI Technology Paradigm Shift
I’ve blogged about Angular before in 2009, and I’ve been aware of it since May 29th, 2009 when Ola Bini and had breakfast with Miško Hevery at Google before rolling into the first “Wave hackathon” the day after it was announced at Google I/O. We (I ?) chuckled at Miško then for his in-a-web-page idea, and since finding out more, I’m regretting that.
What has changed?
Well it has been over two and a half years since Miško and Adam Abrons started this thing. Initially they were thinking of a data-service priced by the mega-byte and you’d host your Angular pages anywhere. Now with Adam not so active for the time being, and Googlers Igor Minar, Vojta Jina as well as many contributors, Miško’s Angular is more than ready for large app development. Production ready, despite not being a 1.0 release yet (that’s coming soon I’m told).
There’s also new competition in the “declarative HTML extending tech” space - Backbone (October 2010), Knockout (July 2010), Batman (January 2011), Knockback (November 2011), YUI Library (urggh; when??).
Knockback is a serious attempt to merge the best of Backbone and Knockout by Kevin Malakoff, that deserves further attention I think. If nothing else, it’s comparison table is a powerful starting point to think about the pros and cons of these technologies.
What’s the criteria for selection?
- Can bind to nodes in a JSON document, especially for repeating ones.
- Feels like an extension to HTML (albeit not a W3C approved one)
- HTML is round-trip editable in DreamWeaver. e.g. DreamWeaver does not take out HTML attributes it does not recognize on ‘Save’ so technologies that rely on attributes for implementation are safe.
- Doesn’t require much Javascript/CoffeeScript in order to get into the rapid prototyping of the whole UI experience.
Not making the cut as far as I’m concerned.
JavaScriptMVC doesn’t make the list because of its verbose templating / binding Ember (some time in early 2011?) sadly still has a verbose HTML syntax Spine (when?) has some ugliness around its {{if var}} {{/if}} logic that makes it feel like it’s not an natural extension of HTML. Sammy (March 2009) has separated templates that feel like a whole other world. This is only a little further than Backbone which I like a little, so maybe I’m being too hard on Sammy.
Not sure about my selections? - take a look for yourself: Addy Osmani has a repo that compares implementations of a Todo list on GitHub That project is the definitive place for comparing these presently. That said the reader some take some caution, as some of the Todo list implementations are minimalist, and some have ‘bells and whistles’.
The Paradigm shift.
If you get into the way of working with these technologies, you start to think of the document on the wire as the contract. That document is JSON of course, and emerged through iterations of UI development. The development is so rapid that you could almost sit next to your end user and ever minute or so say “how about this?”
This is Model View Controller (MVC) in a web page at its best. Purists will say that it’s Model View View Model (MVVM) which is a derivation of Model View Presenter, which as far as I’m concerned was necessary because of the unit-testing complexity of earlier ASP.Net implementations. I’m really happy with thinking of this as MVC though.
It will force you to change your back-end from traditional designs. It is going to have to serve up that document for the page load, and accept it back (modified) and subject to verification when the end-user finishes with the page. Maybe incrementally as the page is used are a possibility. As such the storage for the data behind the document could potentially be a lead weight. If you choose a traditional design (highly normalized data), that’s going to definitely be the case. Perhaps if you are hell bent on that reality, you should delay its creation as long as possible while developing the app, and use something lightweight for the time being. In terms of backend technologies you’re still wide open, though ones that implement JSON are a must. Node, Scala, Ruby, Groovy have JSON built in, though even Java can play well too with the likes of GSON.
The whole development experience is going to be faster. Perhaps 10x over what you’re used to. I’m reminded of Microsoft-Access applications from the mid 90’s where non-technical people could put together shared DB apps for small teams with forms/ reports etc quite quickly. Lotus Notes plays (played) to the same space. Cold Fusion and PHP, back then, were attempts to get the simplicity into web app development, and to lower the bar for development generally. Anyway, the data-bound yet MVC nature of Angular and its ilk really are an accelerator on rapid app dev. I’ve also been measuring page performance with the latest release across for all tier one browsers, and some four thousand data-bound fields on an local Angular page are now being rendered inside of a second. As a result, I’m happy this is quick enough for most apps.
This stuff is so fast for application development, that it should really be your default for new projects, and you then determine if you need to shift away from it for more sophisticated applications. To give you a feel to suitability - booking apps, shopping experiences, and anything that would have fitted a 100 table schema are all very much within reach of Angular, Knockback etc. Content Management systems, Games, GoogleDocs, apps that feel like desktop ones are perhaps not. For those think of GWT, ExtJS and Cappuccino if they must be web-apps.
If these technologies take off, Agile practitioners should be pleased because it shifts the emphasis away from data driven / long-cycle design towards an naturally iterative and emergent one. UX driven development/design, in order words.
Thoughts on Angular per se.
It’s the leader as far as I’m concerned because of the ability to drive a single page from model mutations and Angular attributes sprinkled throughout the page. Even occasional or modal parts of the page. The breakthrough thinking for me was a realization that you could have more than one model in a page. One for the data that came from the server, and one for the flow-control for the page that isn’t going to be saved anywhere. One more for the reference data that came from the server (or was inlined in the page, if it doesn’t change too much). More than once I’ve saved a HTML page using Firefox’s MAFF plugin, then operated on the source to a) remove all JavaScript that normally makes the page, replace the JSON and models that the original web-technology placed in the page with an Angular loaded JSON document. You could do so quite easily for a Amazon’s cart page, or any Airline’s “available flights” page. With Angular in particular, I’m not having to push HTML into ‘script’ tags to make them into templates.
Angular sells itself via the tag line “What HTML would have been, had it been designed for web apps” which is better than their page title “Superheroic JavaScript MVC Framework”. Decipher Inc suggest The model is the single source of truth. I think there’s some general messaging that could be improved, especially when compared to the competing frameworks. It is also lamentable that the AngularJS.org site is (a) not presently indexed by Google, and (b) a place to get stuck on, as the back-button doesn’t allow you to leave it.
Lastly, I think they’re headed in the wrong direction on one specific aspect. Array functions (as they call them), that would have lead into more sophisticated aggregate functions in the style of SQL’s Group-By and Having. In their live example on the lower right of their front page, the remaining number of Todos is presently:
<span>{{remaining()}} remaining</span>
Mapping to a JavaScript function:
scope.remaining = function(){
return angular.Array.count(scope.todos, function(todo){
return !todo.done;
});
};
This used to be the following expression, without an accompanying JavaScript function:
<span>{{todos.$count("!done")}} remaining</span>
I hope they’ll revert the commit that took that out.
Next up : “(almost) No JavaScript prototyping with Angular in a single source file”
PS - I’m still dreaming of a nested UI markup that’s not an derivative of XML that has inline turing completeness and closures.
Jan 28 - update
Kevin Malakoff has a thorough response on his blog. Well worth a read!