Knockout v3.0.0 released

http://knockoutjs.com/upgrade-notes/v3.0.0.html

by johnny_reilly • 13 years ago

158 74 13 years ago

api2• 13 years ago

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

Now you have a full stack in like 50k.

moystard• 13 years ago

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).

api2• 13 years ago

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.

aforty• 13 years ago

Great framework but are those all the changes in 3.0.0?

stevensanderson2• 13 years ago

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/07/09/knockout-v2-3-0-r...

gwely2• 13 years ago

Where can I report tests failing here? http://knockoutjs.com/spec/runner.html

wldlyinaccurate• 13 years ago

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

randlet• 13 years ago

There's a release page for the 3.0 beta & RC here: https://github.com/knockout/knockout/releases

benmorris4• 13 years ago

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• 13 years ago

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).

benmorris4• 13 years ago

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.

skilesare• 13 years ago

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.

scrabble• 13 years ago

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.

macNchz• 13 years ago

I love Knockout for the same reason. I can integrate it into my existing architecture very quickly, and it doesn't have any opinions on the rest of my application structure. I find myself coming back to it on almost every project, because it's so handy when I need it, and out of the way when I don't.

paperwork• 13 years ago

I agree as well.

I built a small, single page app, 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.

jcutrell• 13 years ago

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/

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

prottmann2• 13 years ago

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.

hardwaresofton2• 13 years ago

If you like frameworks that do one thing, and one thing well, then you'll like knockout. Amazing data-binding system

TheAnimus• 13 years ago

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!

1qaz2wsx3edc• 13 years ago

Knockout is more of a library then a framework.

I tend to use Angular, but recently I jumped onto a project and crunched through some work by dropping Knockout into it. The learning curve is small, and I was able to finish off the feature quickly.

Nekorosu• 13 years ago

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.

themightykevdog• 13 years ago

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.

taude3• 13 years ago

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

ibrahima2• 13 years ago

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.

Bahamut2• 13 years ago

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• 13 years ago

http://blog.nebithi.com/knockoutjs-vs-angularjs/

Bahamut2• 13 years ago

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.

dustingetz• 13 years ago

Angular uses dirty-checking, KO uses change listeners (which is why KO is objectively worse because change listeners cause a lot of problems)

http://stackoverflow.com/a/9693933/20003

shaydoc5• 13 years ago

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...

jbigelow762• 13 years ago

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

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

shaydoc5• 13 years ago

Of course, the wonderful d3.js

aymeric2• 13 years ago

After struggling with finding a good way to structure my knockout.js SPA 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.

shaydoc5• 13 years ago

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

aymeric2• 13 years ago

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

EdgarVerona6• 13 years ago

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.

shaydoc5• 13 years ago

Knockout is architecturally sound and the DOM is very much available to the developer. Disagree with much of this.

EdgarVerona6• 13 years ago

It sounds like you're finding faults with things I'm not saying.

First, I wasn't questioning the architectural soundness of Knockout. I think it's very sound, and I like it.

Second, I also agree with you that the DOM is available to the developer - however, if you go about blowing away and re-creating DOM elements that should have bindings on them (for example), you're going to have a bad time. This was something counterintuitive to our Frontend developers. In situations where you want to create or remove DOM elements with Knockout bindings, you really should be using Knockout's bindings (or your own custom Knockout bindings) itself to do it, otherwise you're working pretty hard against the grain. I don't personally see a problem with that - so I agree with you that the DOM is available for change - but that was hard to sell to others. :shrug: maybe I'm just a bad salesman.

EDIT: Ah, I think I can see why you feel this way. I should put the counterpoints I put above in quotes, as they don't actually reflect how I feel. I can see how someone skimming would think I actually believe them to be true. I personally have a very favorable opinion of Knockout. I can, however, see why it's a hard sell for some frontend developers. I can't blame them for feeling that way given their points above, though I would like to believe that I can win them over with my counterpoints to it over time. Whether that actually happens... we'll see.

I could also use some more ammunition in that fight, so if you have good alternatives or approaches that I'm ignorant of, I'd be extremely glad to hear them!

scriby• 13 years ago

In response to your #4, check out the stopBindings option. It provides a pretty simple pattern where you can wrap your knockout bound components in a stopBindings, then you don't have to worry about other binds on the page interfering with them.

See here: http://stackoverflow.com/questions/9254632/how-to-stop-knock...

Also note that you can configure it as a virtual element, so you can use the  syntax.

EdgarVerona6• 13 years ago

Ah, that is useful! I never knew about that binding - good to know!

(Though the Frontend guys will complain about another 'logic binding' in their Views... I don't know what I can do about that other than to point out that the benefits are worth having those in the views. Virtual elements or not, these kinds of bindings annoy them. I see it as the price you pay for all of the benefits personally, but I'm a person who can't stand hunting for arbitrary jQuery bindings to figure out why a behavior occurred.)

benmorris4• 13 years ago

A few random comments: 2) This certainly can get messy in my experience, a complex nested viewmodel is nasty to selectively create observables. I haven't figured a clean way to do this.

3)I found binding handlers in the beginning to be more work to write, but in the long run the code is less brittle and much more reusable (not tied to a specific element). Although pitching to front end folks may not care about this.

4) If I'm understanding what you are saying this sounds to me like you are hitting the limits of Knockout. Durandal has a much better structured system for models/views and nested bindings. The compose syntax in Durandal also comparable to the template binding in knockout, although a lot more flexible. Durandal is built on knockout so much of what you already know will just work.

5) Agreed

EdgarVerona6• 13 years ago

Oh, I've not even heard of Durandal, I'll have to check that out! (Strangely enough, the word "Durandal" has an historic importance at our company, so it'll be humorous to present this to them if it turns out to be useful for us. ;) )

Indeed, my solution for (2) is to say "hey, let's make a real set of ViewModel objects". I have an internal-only project that I built myself, which was basically a fairly complex experiment in using Knockout - and making the ViewModel objects myself really made a difference in how the whole application felt, it felt great. But it was a hard sell - one that I lost - when I tried to sell them on it in general.

And indeed, I don't know if I'll ever find a solution around (5). I feel like it's a small price to pay for the benefits personally, but it is a price to be paid. :(

GundersenMarius2• 13 years ago

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) 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.

jbigelow762• 13 years ago

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.

TonyAlicea• 13 years ago

This is just typical push back from trying to make someone do something in a way that is different from what they're used to . Sounds like they are mostly jQuery devs who throw lots of explicit DOM manipulation around to get done what they want.

Knockout (and other libraries like it) turn manual DOM manipulation into something stateful and object-based.

That said, unobtrusive event handling that comes packaged with knockout might make the transition easier for them (http://knockoutjs.com/documentation/unobtrusive-event-handli...).

krosaen• 13 years ago

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.

taude3• 13 years ago

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.

notdonspaulding2• 13 years ago

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.

dugmartin• 13 years ago

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• 13 years ago

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.

jlu• 13 years ago

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

petrohi• 13 years ago

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

rekoros• 13 years ago

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!

ww520• 13 years ago

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.

Knockout v3.0.0 released

Related Stories