I've now shipped an Ember.js application and a knockout.js application. I enjoyed ember quite a bit but feel that knockout gives me all the magic with half the complexity.
It is true as the author mentions that it doesn't aim to fix the UI/statefullness issue, but I slapped on Backbone Routing on to my knockout code and it made capturing 'state' and urls a breeze.
The last time I used ember was 0.9.6 and I don't think this routing stuff was even in it so I was excited to see talk about it. Unfortunately it looks to be even more complicated then I expected it to. :(
Knockout may be creating some massive memory footprint in the background that will bite me down the line, but I'm writing significantly less code than I was with Ember. For example, In ember you have to create view objects and if you want your view objects to sync data with your controller you have to explicitly define them:
In knockout just have to do:
App.UserController = {
content = ko.observable(new content());
}
ko.applyBindings(App.UserController);
And now I get to do a knockout template inline with my html:
<div data-bind="text: content.firstName"></div>
It just seems like there are fewer steps with knockout and I'm getting more done. The html is a lot uglier, but it also clearer what is going on when I read it.
The ember guys have come a long way on their doc and they should be commended on it. I like the patterns they are talking about I'm just not sold that it has to be done the way they are doing it. Thanks to the author for putting together such an in depth post to me in the right direction in getting back into Ember.
I've also shipped an Ember app and a Knockout App. To me, there's no comparison: Ember development was easier and produced a faster app and a better organized code base.
Once my app grew complex, Knockout grew increasingly hard to reason about how it's view updating was working. It also grew slow.
Also, Knockout lacks any legitimate data laye (knockout-mapping isn't a data layer). Ember has ember-data.
It's a little hard to take the example seriously when you've clearly padding the Ember version with code you don't have (but would need) in the ko version.
Hmmm..I guess my point was that I don't need that code n the knockout version. In knockout the 'view' is my html template, in ember I have to have a separate class to the bind to my html. The author has pointed out that I'm using the wrong app style so I need to look back at what the are suggesting.
It is true as the author mentions that it doesn't aim to fix the UI/statefullness issue, but I slapped on Backbone Routing on to my knockout code and it made capturing 'state' and urls a breeze.
The last time I used ember was 0.9.6 and I don't think this routing stuff was even in it so I was excited to see talk about it. Unfortunately it looks to be even more complicated then I expected it to. :(
Knockout may be creating some massive memory footprint in the background that will bite me down the line, but I'm writing significantly less code than I was with Ember. For example, In ember you have to create view objects and if you want your view objects to sync data with your controller you have to explicitly define them:
App.userController = Ember.Object.create({
});App.UserView = Ember.View.extend({
});Now I get to do my handlebars template <script>
<div>{{firstName}}</div>
</script>
In knockout just have to do: App.UserController = {
content = ko.observable(new content());
}
ko.applyBindings(App.UserController);
And now I get to do a knockout template inline with my html:
<div data-bind="text: content.firstName"></div>
It just seems like there are fewer steps with knockout and I'm getting more done. The html is a lot uglier, but it also clearer what is going on when I read it.
The ember guys have come a long way on their doc and they should be commended on it. I like the patterns they are talking about I'm just not sold that it has to be done the way they are doing it. Thanks to the author for putting together such an in depth post to me in the right direction in getting back into Ember.