
Knockout v3.0.0 released - johnny_reilly
http://knockoutjs.com/upgrade-notes/v3.0.0.html
======
jcutrell
Knockout certainly doesn't get as much attention as it should. For those of
you reading this comment feed to find out if you should try Knockout, I'd
recommend trying it. It is fairly simple to pick up in a weekend, especially
with their interactive tutorials:
[http://learn.knockoutjs.com/](http://learn.knockoutjs.com/)

Looks like this version makes what I believe to be Knockout's biggest strength
(the data binding) that much stronger.

~~~
prottmann
But the same you can say about many other frameworks.

Knockout got attention, but there are so many frameworks that it is not so
easy to see the big advantage of one.

~~~
TheAnimus
I like knockout, I'm using it on a big project at the moment. Compared to say
Angular it is definitely much easier to learn.

My complaint (probably more relevant to hardwaresofton) is that I like my MVVM
to have a type resolution system, ok in javascript this is hard, but if I've
got one ViewModel for the NavBar, it would be nice to be able to better state
the one for the MainContentArea. ko.ApplyBinding(vm, someJQuery) just doesn't
strike me as elegant!

~~~
jasallen
I would argue its only easier to learn than Angular because it is smaller.
_Just_ data binding in AngularJS is much easier to me.

That said, I liked knockout when looked at it, I just looked at Angular
shortly after and fell in love. Annnd, I haven't looked at the new version, so
grain of salt.

------
krosaen
One thing I love about knockout is how focused it is at doing one thing really
well without forcing a full blown single page application. It makes it easier
to sprinkle in the data-bound rich interactive UI to the pieces of your page
that need it and leave the rest as normal server side rendered content.

One key area of performance where js rendered UI helps a lot is in customizing
an otherwise uniformly served (and cached) page. 95% of the page is uniform to
everybody, so render that server side and cache the heck out of it (varnish or
whatever). Then, bind the pieces of the UI after page load and customize them
based on the user - their login status, their location, etc. We use this
approach at food52.com and food52.com/provisions.

~~~
taude
I'm am/was big Angular fan, myself....

However, I came to a team that couldn't GROK the scope of Angular, and
Knockout.JS was so much, easier for them to approach. They are now into the
whole reactive UI thing, have their code organized into view models. Now, over
time, I can start sprinkling in Q library, and other Angular-esqe libraries
and they'll be a lot happier. Another nice thing about Knockout.JS that I've
come to appreciate is that it's about 10x easier to make custom binding
handlers than it is to create Angular directives. And we had to write a custom
service layer anyway, so it's not like we needed that from the Angular
library.

------
api
A great and unfairly ignored framework. I love it for its simplicity and
speed. Do everything with HTML and CSS and use Knockout to bind that to your
data, and then just use this for AJAX and other utilities:

[http://minifiedjs.com](http://minifiedjs.com)

Now you have a full stack in like 50k.

~~~
moystard
Minified does sound interesting, especially in term of size, but what about
the performance in comparison to jQuery? Also, in term of browser support, the
range of browsers officially supported is quite small (plenty of mobile
browsers/platforms missing for example).

~~~
api
In my experience it works on just about any modern browser. It's just that
it's a smaller project and hasn't been rigorously tested on all of them.

I always check my web work on as many browsers as possible anyway, since
quirks abound at all levels of the stack.

------
notdonspaulding
Maybe I'm just starting to get old, but the "we take backwards compatibility
very seriously" line has become a lot more attractive to me in recent years.

------
scrabble
I love Knockout. This is awesome news.

The thing I really like about Knockout is that I don't find the complexity to
ramp up as much as it does in Angular. It's also super easy to just insert it
into any page and use just the functionality I need. It's also got great
performance when it comes to 2 way binding.

~~~
paperwork
I agree as well.

I built a small, single page app,
[http://fixparser.targetcompid.com](http://fixparser.targetcompid.com) using
knockout. I use knockout fairly heavily and it was easy to pick up for someone
like myself, who is not a front-end/web developer.

Since my plan was to overhaul the site, I tried to use angular but found that
it was much more difficult to use. Knockout provides the functionality I need
and provides it very well. Their core members are extremely helpful on their
own newsgroup as well as on stackoverflow.

If I was doing a large app, with a bunch of developers, I suppose I would take
another look at angular. For now, I'm happy to stick to KO for the foreseeable
future.

------
themightykevdog
In addition to the love being given here, I'd like to throw in that if you are
updating an existing web app, nothing beats KO. You can add it incrementally
to a page without turning your whole app upside down.

~~~
taude
You can do this with other frameworks, like Angular, too. FYI. This is
definitely a great way to introduce some change to a codebase.

~~~
ibrahima
You can, but Angular imposes a little more structure to your code so the
learning curve is slightly higher. I prefer Angular's syntax and overall
capability but Knockout is a lot easier to just incrementally add to your
application. I'm glad I learned Knockout first, it made Angular much easier to
grok later on.

------
benmorris
I'm a big fan of knockout. Learned it about a year ago and it has saved me
from writing a lot of code. I can't see going back to the old way at this
point. It doesn't try to be everything, but what it does, it does well. For
SPA I use Durandal, knockout runs the declarative binding so you can get up
and going with a full blown SPA pretty quickly.

~~~
candl
Durandal and Knockout make a great combination for SPA applications. My only
gripe about Knockout is that some of the useful built-in utilities (ko.utils)
are not officially documented anywhere and of course the observable syntax can
get unwieldy at times (parentheses) and difficult to maintain (this can be
remedied by durandal.observable plugin if we target newer browsers, though).

~~~
benmorris
Absolutely agree with all of that. Parentheses was my biggest hurdle in
learning Knockout. Refactoring is a bit of a challenge also if you go from
unobservable -> observable because of all of the parentheses.

------
EdgarVerona
Having worked with Knockout on a fairly large project, I personally liked it
as a normally server-side developer - however, it got mixed reviews from our
purely frontend developers.

For me, there are several things I like about Knockout as someone who's not a
primarily frontend developer:

1) Obviousness of purpose. The thing I hate the most about frontend
development is the lack of visibility into what is actually bound to an
object. When I run into UI code that's not using some kind of framework like
Knockout, inevitably the UI interactions are typically performed with jQuery
bindings, and often they aren't terribly straightforward to find for anyone
who didn't initially develop it ("what, you bound a mouseover action to
everything that fits '.mouseoverable > li > ul > li > .mousey'?")

2) Clearly defined interaction models. I like creating and populating the
ViewModel, and thus having a very clear place in the Javascript where I know
the business logic and data for the frontend are going to live. When I create
the ViewModel as its own Javascript object, I can define the full contract of
what data the application needs and what operations can be done against it in
a manner that I can quickly locate and fix up later.

3) Syncing of frontend state with data state. (of course, this is an obvious
benefit, but...) I love that, once I've defined these obvious bindings, I can
then focus more on my model and less on what is bound to that model. It gives
me the ability to separate out my concerns, at least more than a scattering of
one-off jQuery bindings would.

Knockout provides an obviousness of binding not only because all interactions
between the UI, the user, and the model are supposed to happen through these
bindings, but because the bindings are supposed to live on the element being
interacted with/displayed itself. This made a huge difference for me, as
someone who likes to see an obvious relationship between the view and the
underlying logic that's modifying or creating that view. The concept of
observable properties also felt natural to me, and I didn't mind taking the
time to make rich ViewModel objects that had methods attached to them
representing actions, and "ko.computed"s when I had more complex scenarios in
which I wanted to watch for (or perform) an update.

However, our frontend guys hated it, and I can understand why they feel that
way (though I disagree with them on many of these points, and would like to
win them over). For them:

1) "We're moving backwards." It's a dramatically different approach that feels
counterintuitive - in fact, for frontend developers who've been told their
entire career to never put event handlers on the attributes of an element
itself, it feels like a step backward evolutionarily. It feels, to them, like
you might as well be going back to "onclick=''" bindings.

2) "More upfront work." It's a more upfront work to create and maintain solid
and coherent ViewModel objects, particularly when Knockout provides the
tempting - but often fragile - alternative of calling "ko.mapping.fromJSON" or
"ko.mapping.fromJS" that will essentially make a dumb ViewModel for you, but
will also make everything observable and won't give you any of the benefits of
creating your own ViewModel with reasonable business logic, computeds, etc...
This not only ends up making the bindings feel messy as they start performing
complex logic directly in the binding where a computed or method would do, but
it reinforces that bad "onclick=" binding feeling that they hate.

3) "We have to surrender control of the DOM." The real killer for them is
that, once the DOM is being managed by Knockout, you essentially have to give
your control of the DOM over to Knockout. If you start fiddling with DOM
elements with your own custom jQuery handlers instead of through custom (or
built in) bindings, Knockout is going to inevitably run over your changes in
unexpected ways as it itself modifies the DOM. Asking the frontend developers
to make custom bindings is, unfortunately, asking for more work (and less
intuitive work) than just making a jQuery binding, and thus it presents itself
as a lot of additional code.

4) "The path for mixing 'common' ViewModels with 'page specific' ViewModels is
not clear." This is one I still struggle with in trying to help find a clear
path for them. Let's say that a page loads with a bunch of sections that are
common to every page, and there are also page specific data and operations
that need to be loaded. Knockout only lets you bind one ViewModel object to a
given set of DOM elements at a time, which makes this difficult. My gut is
that, if we were to create these ViewModel objects in such a way that a common
"binding" Javascript block of code - run after all ViewModel objects for the
page were both created and combined into a single over-arching object -
existed, then they could all live together. This solution is fragile, however
- that means every binding would need to be bound to some object off of that
single ViewModel object, which could be prone to breakage as these models
change. Essentially, bindings (or DOM elements with appropriate "with:"
bindings to scope out what part of that larger ViewModel you cared about)
would have to be created with this larger overall ViewModel in mind. The
proposals don't sound great when I talk to people about them, and I can
understand their hesitation. (if any of you have good alternatives, I'd love
to hear them)

5) "We dislike having 'logic bindings' or 'placeholder bindings'." Frequently,
the data for the ViewModel isn't actually loaded yet by the time you need to
bind. The way of preventing the bindings that require that data from breaking
is to have boundary bindings wrapping them, such as checking if the object is
loaded or the data you want isn't null... but now you've got essentially
boundary checks sitting in the DOM. They dislike those - understandably - and
they dislike "with" bindings as well. It all feels like fluff that they
shouldn't have to worry about, and that crowds up the view. This is another
one for which I don't have a good response or alternative.

Anyways, Knockout definitely has both good and bad elements to it. I encourage
everyone to give it a try. You may love it - as I do - despite its flaws, or
you may hate it! But give it a shot, it may be a handy tool for you.

~~~
GundersenMarius
I'm both a frontend and backend developer, and I love knockout.js. I want to
reply to some of the issues you brought up, not just for you but for others as
well.

1) the pendulum is currently swinging backwards from the "no logic in the
HTML" and is heading towards the "all logic in the HTML". Knockout, angular
and ember all use declarative bindings, which is the complete opposite to what
jQuery code was like. I think it is a good idea, as it makes it easy to
understand how a dom element is supposed to behave. But the pendulum will
probably swing back in the other direction again in a few years, and somewhere
in the middle is likely the optimum.

2) fromJS and fromJSON are dangerous and should be avoided. It might be more
work to manually write things out field by field, but it makes things a lot
easier to debug and understand later on (just like data-bind makes interactive
dom easier to understand than jQuery magic). Easy to write does not equal easy
to read or maintain.

3) jQuery should be forbidden in a knockout.js project, except (maybe) inside
custom bindings. This does make some things which are easy with pure
javascript difficult, and that is unfortunate. I still haven't found a good
solution to this.

4) shameless plug: I'm working on a framework which solves this, called
ordnungJS ([http://ordnungJS.com](http://ordnungJS.com)) it is not well
documented yet, but I have used it in production code and it works well. I'll
improve the documentation when it reaches a more stable version, and write a
short tutorial on how to use it.

~~~
jbigelow76
Concerning #3, I've only done one small project with Knockout and I used
jQuery for ajax calls, what would you suggest in lieu of it. I'm trying to
decide between KO and Angular for a larger project.

~~~
shawkinaw
I've used both and I would highly, HIGHLY recommend Angular over Knockout,
especially for a large project. Angular is very modular and lets you separate
your concerns nicely, while with KO I basically ended up with one mega-JS file
and one mega-HTML file with a lot of ugly inline templates.

That being said, my KO education is not as good, so it's highly possible that
I made design mistakes that made the project more painful than necessary.
Nevertheless, I don't hesitate to recommend Angular; I normally dislike web
development but Angular is quite a lot of fun to use.

~~~
ibrahima
I think the blessing and curse of Knockout as compared to a more complete
framework like AngularJS is that it's incredibly easy to get started and
doesn't force you into any sort of structure, but at the same time if you're
not forced into a structure it's pretty easy to go down the "one mega JS file"
route. I felt like AngularJS is more annoying to get started with because you
have to follow its conventions but in return it gives you a nice structure to
organize your code.

I also personally prefer how Angular doesn't force you to use getters or
setters, although it does involve more "magic" behind the scenes stuff which
can be confusing.

------
ww520
I like Knockout, and have used it in several production systems. It has been a
tremendous help in getting rich interactive UI on web apps.

Having said that, the mistake I made early was to use ko.mapping.fromJSON and
fromJS to blindly generate the view model, which turns every field into an
observable. It was very easy to get going and get it working fast, but I ran
into performance problem later on with hundreds or thousands records. The
advice to take the time to build your own view model and decide which field
needs to be observable and which field can stay plain old Javascript object is
very sensible.

------
Bahamut
As someone who uses AngularJS pretty hardcore, can anyone give me a good high
level summary about Knockout or point me in the right direction?

~~~
ganarajpr
[http://blog.nebithi.com/knockoutjs-vs-
angularjs/](http://blog.nebithi.com/knockoutjs-vs-angularjs/)

~~~
Bahamut
Thanks!

I actually was looking more for articles that gave the philosophy behind
Knockout though, not a comparison with Angular - I mentioned that more as a
reference to my experience with client-side MVC. I would like to understand
other frameworks independently from anything else - I want to know what they
are trying to accomplish without any opinions.

~~~
notdonspaulding
I think it's fair to say that Knockout's philosophy is:

"Knockout is a library that binds Javascript objects to DOM nodes."

It accomplishes _that task_ amazingly well. It essentially takes this DOM
node:

    
    
        <a data-bind="attr: {href: link()}, text: title()"></a>
    

And let's you bind a JS object like this to it:

    
    
        var my_view_model = {
            link: ko.observable("#foobar"),
            title: ko.observable("A link")
        }
    

Then, knockout watches the `my_view_model.link` and `my_view_model.title`
attributes for changes. When it "observes" a change of their value, it updates
the DOM.

That's about all you need to grok to see value out of Knockout. If you can get
your data into JS objects, Knockout can do a bang-up job of keeping your DOM
in sync with your data. As a "backend guy" that eliminates a whole lot of
boilerplate JS I used to write whenever my data changed or I needed to keep
track of state.

Knockout does more, of course, but from then on it's mainly about adopting it
to your use case (Do I mix it with Django templates? Do I just go with a
static-only frontend? How do I manage AJAX requests to keep my JS objects data
up-to-date?)

------
Nekorosu
I've used this framework to build an html5 video player. I really liked how
easy it was to move from jQuery based prototype to fully "knocked out"
version.

The other thing I adore is a lack of magic. This means more code but this also
means I can understand what's going on after a long break from the project.

------
shaydoc
Its simple, elegant and extendable. Been using it for 2 years, and see no
reason to change. This is my SPA setup

[http://anexiledderryman.com/post/50565922110/javascript-
sing...](http://anexiledderryman.com/post/50565922110/javascript-single-page-
application-architectural)

~~~
jbigelow76
That looks like a very clear structure, I like it.

Off topic, but would mind sharing what you used to create the diagram?

~~~
shaydoc
Of course, the wonderful d3.js

------
wldlyinaccurate
I couldn't find a full changelog, but GitHub's compare system makes generating
a changelog fairly trivial:
[https://github.com/knockout/knockout/compare/v2.3.0...v3.0.0](https://github.com/knockout/knockout/compare/v2.3.0...v3.0.0)

~~~
randlet
There's a release page for the 3.0 beta & RC here:
[https://github.com/knockout/knockout/releases](https://github.com/knockout/knockout/releases)

------
dugmartin
I did a fairly large Knockout app a couple of years ago and while the MVVM
pattern worked pretty well after a while the interactions between all the
bindings on the page crossed my cognitive threshold (and also ran slowly on
mobile browsers).

I haven't done a single page app again until a few weeks ago when I started
playing with a side project. After looking at the options now available I
settled on backbone + bacon.js (baconbone?). Once I got my head around
functional reactive programming using the bacon.js eventstreams and properties
vastly simplified my frontend code. At least for me changing the
representation of the frontend from a static state to one of a stream of
changes where the state is an intrinsic value of the event stream clicked.
YMMV.

------
deckiedan
I've been using knockout.js for a while on some flask (python) projects, most
of the time I've been doing simple server-side logic for stuff, and HTML based
views. Then for more complex UI interactions, using knockout. It works very
well.

It doesn't force any kinds of rigid conventions on the code, which is good if
you're adding it to a already existent project.

It is kind of fiddly having multiple layers of observables

ListOfPeople -> ListOfDetails

where both sets of lists are updated in real time to the server in JSON, but
overall I found it remarkable easy to get into.

------
aymeric
After struggling with finding a good way to structure my knockout.js SPA
[http://weekplan.net](http://weekplan.net), I finally found something I am
happy with, inspired by the angular.js framework.

Beware, if you are thinking of using Knockout.js for a mobile friendly app,
the binding / events can easily slow down your app.

~~~
shaydoc
Can you quantify this statement, because performance has greatly improved in
recent releases!

~~~
aymeric
On my app, it takes 2s to render 174 tasks on my desktop. Imagine on a mobile
phone...

------
rekoros
We (kato.im) found Knockout to be a remarkable framework.

We evaluated a number of options and found Knockout to deliver the fewest
number surprises.

Knockout's primitives make it possible to design elegant solutions to problems
that frequently seem to result in unmaintainable code.

Kudos to the Knockout team!

------
skilesare
I use knockout + backbone router to build most of my apps. It is a great
framework without a ton of the infrastructure overhead of angular. I wouldn't
use it to build a component library I was trying to sell, but for my clients
it works really well.

------
jlu
Might worth having a look at backbone.rocks too, does a lot on top of backbone
for what knockouts has to offer.

[https://github.com/devmatters/backbone.rocks](https://github.com/devmatters/backbone.rocks)

------
aforty
Great framework but are those all the changes in 3.0.0?

~~~
stevensanderson
No, that page is just info on behavior changes for people upgrading from KO
2.x.

We haven't published the official 3.0 announcement yet, but you can find an
overview of what's new on my Release Candidate/Beta blog posts:

* [http://blog.stevensanderson.com/2013/10/08/knockout-3-0-rele...](http://blog.stevensanderson.com/2013/10/08/knockout-3-0-release-candidate-available/)

* [http://blog.stevensanderson.com/2013/07/09/knockout-v2-3-0-r...](http://blog.stevensanderson.com/2013/07/09/knockout-v2-3-0-released-v3-0-0-beta-available/)

~~~
gwely
Where can I report tests failing here?
[http://knockoutjs.com/spec/runner.html](http://knockoutjs.com/spec/runner.html)

~~~
stevensanderson
Thanks for flagging this.

The version of the specs published to knockoutjs.com didn't match the final
release. I've just updated them. Please let us know if anything is still
failing, preferably at
[https://github.com/knockout/knockout/issues](https://github.com/knockout/knockout/issues)

~~~
gwely
Nice, everything is passing now. Thanks!

------
petrohi
Great framework! Imho best at having powerful yet non-leaky and clear
abstractions. We use it to build kato.im web app.

