- Understanding the interpreter
- Understanding the language
- Getting to know all major micro frameworks </ul>
- Lack of proper IDE and debug tools – for .Net engineers this is a great shock
- Unfamiliarity with the web architecture – JQuery, minification, CSS, HTML, browser tools etc’
- We had a time constraint to figure this all out </ul>
- Sprout Core </ul>
After writing all the available micro frameworks on the board I could easily get most of them out of the way, and separate between various DOM frameworks, like prototype, DOJO, JQuery and alike and micro frameworks (see list below). We narrowed it down to the following list, depended on JQuery as our DOM library (don’t see any point explaining that). Here is the list:
Yes, there are many more out there (sammyJS, spine, YUI etc’ and check out the following comparison) but we figured out that we couldn’t go wrong with any of the above and probably achieve the same result with more or less same amount of effort.
So we decided to give a dedicated test to Ember and knockout. We devided into two teams with the same task: building a module/widget application that communicate with REST services. Both teams got to the ending line with complete working applications.
Why not Ember?
The Ember documentation is still lacking. We had a hard time to figure out the default “html input fields” binding. The simplest thing took us a half day to figure it out since there is no proper documentation for that common task. The handlebars templating is just great, but it lakes a designer support, unlike its ancestor sprout core that comes with a dedicated server, this one had us wrapping all templates with script tags (same as knockout), and even without the script tags it still looked weird in the designer. Unlike knockout that had the binding in the tag attributes.
Ember is still a young project, as young as JS micro frameworks can be, much of its documentation is copied from sprout core project. The project road map seems promising (ORM integration for ruby) and the community seems dedicated to complete the work – and still, it felt like we were missing something: the spirit of HTML 5. The spirit that keeps you lite, not oblige to any FW, not religious about your tools, feeling free like a bird in the great cause surrounding you. And that spirit exists when you add bits from here, take some bits from there and then compose a framework of your own. We/I felt this task was easier to accomplish with knockout that only gives us binding engine and seemed to be enough to tackle this job. The binding are so easy. They are non-obtrusive, easy to get along with if you are coming from XAML (after all this FW is written by MS employee), well documented all over the web and not just in knockout site and most important of all – Feels very light weight.
I’ll just give a quick example, as a coworker of mine noted, working with bounded properties (getting and setting values):
You can see clearly that Java notation like of Ember vs the intuitive notation of knockout.
I’m not sure if we will stick to knockout alone, or maybe trade our sole for something commercial, since after all we are building a LOB application that needs to scale to mobile, tablets, have annoying-not light-weight-controls like grids and so. But for now – knockout won our hearts with ease