Chris Price, February 17th, 2012
I recently had a need to create a demonstration application showcasing some of the features of the Closure toolkit. Whilst I was trying to think of a suitable example to implement, I remembered coming across a project called TodoMVC.
TodoMVC is a GitHub project which aims to re-create the same simple to-do list application using a multitude of different JavaScript frameworks. Each example features (close to) identical functionality as opposed to the examples available form the framework’s homepages, which showcase differing functionality highlighting the strengths over the weaknesses of the framework.
The application itself is a very simple to-do list, featuring adding items, editing items, toggling the done state of an item and removing items. For my Closure implementation I split the UI up as follows -
- A plain HTML input Element
- A custom goog.ui.Container implementation and renderer – ToDoItemContainer(Renderer)
- A custom goog.ui.Control implementation and renderer – ToDoItemControl(Renderer), making use of the following goog.ui.Component.States -
- n.a.
- CHECKED
- SELECTED (on reflection this should probably have been FOCUSED)
- HOVER
- A custom goog.ui.ControlRenderer using the default goog.ui.Control.
- A custom goog.ui.ControlRenderer using the default goog.ui.Control and ACTION event.
All of the UI elements are rendered by some simple soy templates and backed by an array of model.ToDoItem beans. The controller/application logic is contained in main.js, this is primarily logic which takes events from the UI and pushes the values back into the model. Unfortunately Closure doesn’t feature any in-built binding framework so this is a very code heavy implementation.
I’ve shared my implementation with the project and you can see the Closure demo in action here and you can grab the code here.
This entry was posted on Friday, February 17th, 2012 and is filed under Blog.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site .
Nice, thanks for that Chris.
I’ve often been tempted to dive into google closure and build a few apps, but keep getting put off by a general lack of adoption in the face of the hype of frameworks like Backbone etc.
Putting aside the ‘ choose something fit for purpose’ arguments, would you recommend it as a good framework to learn?
Cheers, glad you found it useful!
I’m sorry to answer your question in the way you explicitly asked me not to but it really does depend on the situation…let me explain -
Pros -
It powers about half of Google’s sites, so is well tested and will be around for the foreseeable future
Modularity (with dead-code-elimination) and a server render/client decorate model, features rarely found in other frameworks, which give the fastest possible performance
Type-safety!
One cohesive suite of tools that work very well together, but can be used separately or together with other frameworks
Cons -
There is a lot of configuration/boilerplate involved in getting Closure setup as part of your build process, and integrated into your server-side components.
The annotations can be laborious to add (templates can help) and often add redundant information e.g. @extends versus goog.extends (there’s a good reason for this but it is annoying to maintain).
The library is incredibly vast and there is a pretty steep learning curve when first starting out.
There isn’t much high-level documentation to help you get started, compared to say GWT (I would recommend reading Closure-The Definitive Guide though).
For larger projects, the pros definitely outweigh the cons, the initial setup time should be dwarfed by the long term benefits. However, for small projects I think the cons outweigh the pros, you’ll spend more of your time setting things up than just cracking on and getting stuff done. I think it is these smaller projects, that are far more plentiful on the web, where frameworks like backbone and knockout excel.
FWIW the library itself is very well documented (with jsdoc) and so is a great place to find inspiration for the best ways of tackling common problems, oh and also playing spot the control from Gmail!
I hope that goes at least someway to answering your question,
Chris
Really appreciate your fantastically erudite answer Chris. I can see now, you’re quite right on the fundamental need to evaluate the situation/project/requirements in hand and base a framework decision on that.
I think that is at the core my current flip/flop in deciding on a framework to invest time in… I don’t have a specific project at the moment that might help me decide a basis of requirements.. Might be a waste of my time to delve into a steep learning curve (Google Closure) when I really just want to potter about with some new tools!
KnockoutJS is a good shout, I’ll investigate that.
Cheers, Allan
You picked a good time to ask the question! I’m currently writing a series of posts to help desktop developers get started on the web (http://www.scottlogic.co.uk/2012/03/moving-to-the-web/) and the answer above is a sneak preview of part II
Good luck with knockout, I think the tutorials are excellent http://learn.knockoutjs.com/.