Knockout 3.1 ships
knockoutjs.com
knockoutjs.com
I just wish it had proper API documentation. There are no real docs, only examples/tutorials, this can be quite frustrating.
If you've never used data bindings in HTML/JS, you HAVE to give this a try.
If you're still using jQuery & other manual event handlers to change the state of your UI, you GOTTA try it!
What is missing from http://knockoutjs.com/documentation/introduction.html in your opinion?
BTW, I think Knockout is just prescriptive enough to get a pretty tight maintainable codebase, but without causing another layer of wrapping/complexity when you want to use existing JQuery components.
Your app can out grow knockout and then your stuck rolling your own location provider,dependency injection and more.
2-3 years ago knockout was a breath of fresh air but know its just old and dated technology.
And compared to the bloat that is angular and especially ember, I find knockout strikes with simplicity and 'keeping-it-simple'.
I'm building a large enterprise SaaS system single handedly and while I'm a competent to good backend developer my front end skills are weak (mostly ancient JS and then jQuery stuff up to writing jQuery plugins) and Knockout has saved my bacon (when combined with Bootstrap 3).
It took me a weekend to get my head around the approach (and force feed some JS knowledge I was weak on) into my head and then on the Monday I wrote my first custom binding handler to allow me to do async file uploads (think Gmail attachments) as easily as
<input data-bind="ajaxfile: { property: 'photo', url: '/ajax/upload', maxsize: 8388608, image: true}" type="file">
The actual architecture is multi-page with each page been bound to it's own view model (as the vast majority of pages are either forms, editing forms or showing tables) this has worked out really well so far (I also have a custom binding to bind a knockout property directly to a jquery datatable 1.10 instance which has made life somewhat easier but it's hairy code (on the limit of what I'm capable of with javascript)).
An example, we have an app that so far consists of about 25 individual SPAs. It was originally an SPA, but we ran into tons of problems with routing issues that cropped up, and realization that when the user uses the apps, in any given session they'd probably only use 20% of what it offers. Developers get to work quickly on their modules, there's no up front initialization/download of the entire apps. Some of the apps are more prototype quality to get the job done, some have been refactored several times. But they all form a cohesive experience. It's also nice when you're developing a group of functionality that you don't have to start the app at the beginning.
Most users won't even know when their in a SPA vs Multi-page SPA.
I have a simple state observable and then I wrap my 'views' in a if: state() == 'x' knockout comment. This moves the entire view out of memory until the state changes.
In addition I have a fixture loader that loads the view files in as they are needed. This speed things up nicely as my base html file is much smaller.
TL;DR: "This release focuses mainly on performance and stability/compatibility improvements, plus small enhancements to existing functionality (yes, we're saving the big new features for v3.2). [...]"
We use it in our production single-page app at sendwithus, and while AngularJS is tempting, Knockout is so lightweight and nimble that it lets us move really quickly on front-end features.
I also love how the ko.observable doesnt feel as magical as the angular binding. It makes me feel alot more in control
var myViewModel = {
personName: ko.observable('Bob'),
personAge: ko.observable(123)
};
myViewModel.personName() //get
myViewModel.personName('Mary') //set
Also, if you really prefer angular.js style of tracking dependencies, this plugin makes the trick http://blog.stevensanderson.com/2013/05/20/knockout-es5-a-pl...
I know it sounds pedantic but it's not 'prefer', it's that the properties as methods is fundamentally changing the way the language works and is very brittle.
In short, it doesn't matter which it is - a method or an attribute - as long as it's consistent.
What fundamental changes to the language you see when using methods instead of plain attributes? Aside from the fact that setter and getter methods in JS are bindable while attribute access is not.
Every time you have an object you have to remember whether it's a normal JS object or a properties-as-methods object. Using knockout to handle your view models doesn't magically change the rest of your code. All the other code you write and libraries you use will be using properties the standard way.
Secondly, the uniform access principle (which you seem to misquoting? It's not about consistent access by type, it's about all types having identical methods of access).
It comes across as something an academic would propose because it's intellectually enticing but practically detrimental.
Think of it like changing a, it, the, we, you, our, etc. all to be o. Yeah, now you can change nouns freely, but the syntax is a signal and the difference is useful.
A method is conceptually supposed to be different to a property and so it should look different.
Javascript's bad enough for readability with everything being a function.
Whether you agree with it or not, in the end it's simply not how javascript works. Methods and properties are accessed differently.
At least with knockout you know you are always out of context and have to use the getters/setters.
And i have to say, i'm amazed by it.. It's pretty awesome to create my first EditableHTML :)