Angular Vs Knockout Final Thoughts(blogs.lessthandot.com)
blogs.lessthandot.com
Angular Vs Knockout Final Thoughts
http://blogs.lessthandot.com/index.php/WebDev/UIDevelopment/angularjs-vs-knockout-final-thoughts-9
3 comments
dirty-checking (angluar) is always better than change listeners (knockout), here is why: http://stackoverflow.com/questions/9682092/databinding-in-an...
Try to do something complicated in Knockout like nest a bunch of complex models and you will very quickly abandon knockout. Angular isn't all roses either but at least its possible to do complex views.
Try to do something complicated in Knockout like nest a bunch of complex models and you will very quickly abandon knockout. Angular isn't all roses either but at least its possible to do complex views.
I've tried both on a side project I've been noodling with for most of the year.
What I liked about Knockout is that it was very quick to get started and it did what it said it would do on the tin. The documentation was fairly straightforward, unlike than the markov chain generator stuff that is passed off as documentation by the AngularJS crew.
However, Knockout's technique for watching state requires you to wrap everything of interest. The actual model becomes thoroughly comingled with calls to ko.observable( yourVariableOfInterest ), often in multiple places in the call stack when KO fails to follow the flow of execution.
And this spreads into your testing too. You can't just test your own model in isolation, you have to bring KO along for the ride.
I reached a high-water mark and decided to move off Knockout onto something else.
AngularJS was shiny and trendy, the tutorial impressive, so foolishly I switched.
Angular at least allows me to leave my model code largely unannotated. I recently radically refactored the model code and I only needed small changes on the Angular bits. The Angular method is that you build a mapping between your own model and what Angular knows about. So instead of your own code being comingled with Angular annotations, you have your own code in one place and the Angular mappings in another place (in a Controller with $scope.variableOfInterest = model.yourVariableOfInterest).
On the downside, Angular's documentation is notoriously terrible. I was at a tech interview last week at a place which uses Angular, and everything about Angular that has stumped me has stumped teams of people who are better than me. And just like me, they spend more time reading the Angular code to explain the docs than relying on the docs.
I think that for CRUD apps with swooshiness, Angular is great. And that's what the tutorial shows. But for more difficult applications the documentation and weak tooling is very frustrating indeed.
What I liked about Knockout is that it was very quick to get started and it did what it said it would do on the tin. The documentation was fairly straightforward, unlike than the markov chain generator stuff that is passed off as documentation by the AngularJS crew.
However, Knockout's technique for watching state requires you to wrap everything of interest. The actual model becomes thoroughly comingled with calls to ko.observable( yourVariableOfInterest ), often in multiple places in the call stack when KO fails to follow the flow of execution.
And this spreads into your testing too. You can't just test your own model in isolation, you have to bring KO along for the ride.
I reached a high-water mark and decided to move off Knockout onto something else.
AngularJS was shiny and trendy, the tutorial impressive, so foolishly I switched.
Angular at least allows me to leave my model code largely unannotated. I recently radically refactored the model code and I only needed small changes on the Angular bits. The Angular method is that you build a mapping between your own model and what Angular knows about. So instead of your own code being comingled with Angular annotations, you have your own code in one place and the Angular mappings in another place (in a Controller with $scope.variableOfInterest = model.yourVariableOfInterest).
On the downside, Angular's documentation is notoriously terrible. I was at a tech interview last week at a place which uses Angular, and everything about Angular that has stumped me has stumped teams of people who are better than me. And just like me, they spend more time reading the Angular code to explain the docs than relying on the docs.
I think that for CRUD apps with swooshiness, Angular is great. And that's what the tutorial shows. But for more difficult applications the documentation and weak tooling is very frustrating indeed.
If you don't care about IE8 you can get rid of the observables on your models with the ES5 plugin.
http://blog.stevensanderson.com/2013/05/20/knockout-es5-a-pl...
"The actual model becomes thoroughly comingled with calls to ko.observable ... I reached a high-water mark and decided to move off Knockout"
+1, this is exactly my experience too. my app is the enterprisey type with lots of really complex and dynamic views
+1, this is exactly my experience too. my app is the enterprisey type with lots of really complex and dynamic views
I just finished a large project with Durandal that went great. I fell in love with it. I'm eager to try Angular on the next one to see how they stack up.