When I was evaluating client-side frameworks, I liked lots of the pieces, but wanted to "mix and match" the best features. I started with Backbone.js and really loved the Models and Collections, and used Brunch to get me up and running quickly.
After a while, I found the view coding too slow so I wrote Mixin.js to extract out reusable aspects of my views. When I was looking for my next productivity increase, an ex-work colleague suggested Sproutcore, but at the time, it wasn't yet micro-frameworky enough meaning I would need to learn something big and "to throw the baby out with the bathwater" as they say (it is hard to give up Backbone models and collections!). Then, I discovered Knockout and knew it was for me!
Knockout provided just the right building blocks for a layer between my templates and data. As I used it more, I built additional functionality like Backbone.ModelRefs for lazy model loading, localization helpers for truly dynamic views, and most recently, an easier way to sync collections and their model's view models.
So here it is...the refactored and shareable version of my Backbone bindings for Knockout: Knockback.js
I really appreciate KnockOut too, because it can really be added gradually to an app without much assumptions nor getting in the way. For those who do not know it, make sure to have a look at the interactive tutorial at http://learn.knockoutjs.com/.
It also seems that Angular.js is a natural progression from KO to something more full-featured (when needed).
In all honesty, I think that the way javascript apps are created needs to be rethought when you have to combine your MVCs with your MVVMs to change a View that's somewhat like a Controller into a ViewModel that can maintain state and pass it to a View.
I'm going to propose the FuckThis paradigm until I can come up with something that makes some sort of sense.
ViewModels differ from Views exactly in this: they own states, methods and properties allowing the views to be logic-less.
If you consider, in Backbone.js, that your templates are the views, then the Backbone Views are a kind of controllers. What are the advantages of Knockback.js here? I'm sure there are but it's not clear to me given the description.
Alternatively in backbone.js you can create object models related to View but that are not part of your business logic.
Main benefit of Knockback.js over Backbone.js is that:
- It makes a clear distinction between Views and logic by providing ViewModels. You don't need to have the a single class rendering data and processing logic also.
- Provides the data-bind based templating which cleans up the backbone.js render function that requires DOM manipulation through libraries like jQuery.
I've tried both Knockout and Backbone with Circle (https://circleci.com), I can totally see the use case here. Knockout is great for syncing between the client and server, and does history and routing well. However, it's not great at model form synchronization.
However, Knockout really excels at that, and allows you to do great live updates.
In the end, we chose Knockout + Sammy.js (history and routing) + manual templating (pretty easy really).
Am I right in saying backbone and knockout do not solve the same problem? I fancy dipping my toes into a javascript framework, and being primarily a .net dev I'm being pushed towards knockout. However backbone seems to be better adopted and more mature. Is knockback the best of both?
Can another provide examples of where one would be superior over the other?
From what I've seen of both (and having used Backbone professionally), while backbone has more documentation on the web, the problem is it's a very flexible framework and it doesn't force much upon the developer, which is great. However, it does mean that a lot of tutorials talk in different paradigms.
As a .NET guy, I'd go for Knockout. I also like what I'm seeing with Angular.
If you're from .net background you'll (probably) already be familiar with MVVM (Knockout's approach)... its how the Silverlight framework is designed to function (and its no accident that MS got behind Knockout for this reason).
Unfortunately I can't comment on backbone as I haven't used beyond tutorials, someone else might be able to assist though.
That's too bad, I had bookmarked it as a really good explanation of the difference between ko and backbone... Sorry for the bad link. I'll see if I can find the original text tomorrow.
When I was evaluating client-side frameworks, I liked lots of the pieces, but wanted to "mix and match" the best features. I started with Backbone.js and really loved the Models and Collections, and used Brunch to get me up and running quickly.
After a while, I found the view coding too slow so I wrote Mixin.js to extract out reusable aspects of my views. When I was looking for my next productivity increase, an ex-work colleague suggested Sproutcore, but at the time, it wasn't yet micro-frameworky enough meaning I would need to learn something big and "to throw the baby out with the bathwater" as they say (it is hard to give up Backbone models and collections!). Then, I discovered Knockout and knew it was for me!
Knockout provided just the right building blocks for a layer between my templates and data. As I used it more, I built additional functionality like Backbone.ModelRefs for lazy model loading, localization helpers for truly dynamic views, and most recently, an easier way to sync collections and their model's view models.
So here it is...the refactored and shareable version of my Backbone bindings for Knockout: Knockback.js