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:
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).
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
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.
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).
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.
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.
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.
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.
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.
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.
Yes, but the same is true of Knockout - it has no server-side ajax functionality. I'm looking at the code on the example pages and it's solving essentially the same problem as Knockout (there's even a shout out to Knockout on the homepage).
The main difference seems to be that in Knockout has 'observables' that are part of your view model, whereas with Ractive you interact with your view model via Ractive's functions.
Sorry I think of knockout as more of a library than a framework. It's called a framework (and often the smallest/lightest one), but most of the real work is really only done in one or two places
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!
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.
I like the way Angular manages nested $scopes a lot better than the ko.ApplyBinding paradigm. We are constantly have to add wrapper DIVs and clobbering each others ViewScope in Knockout.JS. It's not the end of the world, by any means.
I use a single viewmodel with multiple objects and the "with" binding to deliver that pretty effectively. You still get the ko.applyBinding(view) call but can have common HTML.
We went to that after hell with pages littered with applyBinding calls.
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.
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.
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.
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.
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.
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?)
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.
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 ...
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!
I understand what you are saying. Convincing people about new styles that are alien to their traditional style is difficult.
Consistency and maintainability of a codebase is a big factor for me. If I have a large project with knockout I can nearly guarantee a fairly similar style across the codebase.
Time spent being the owner of a large project convinces me that a framework like knockout is important.
So for the life time of the project it gives new developers coming onboard a good idea what to expect from the outset.
I totally agree with you, 100%. I can't lie, it made me sad when I saw the team starting to turn against Knockout, as the benefits it brings in the points I made above (as well as consistency and maintainability, as you brought up) are real - and often frontend projects suffer greatly for want of these very benefits.
I've never been good at convincing people of things, however, so it's been an uphill battle - one that I lost a lot of ground on early, and I feel like a lot of our frontend codebase suffered as a result. I do feel like they're slowly starting to warm up to the benefits of it now that they've had some maintenance problems with the current approach, but that's similar to sending an innocent man to prison for several years before discovering he's innocent - it'll take a while to undo what's been done, if it can be undone.
Now, none of this is to say that they're bad developers. They make amazing UIs that I couldn't even conceptualize (me being a backend jockey who is terrible at making things look good). It's hard for someone to hear about an entirely new approach to what they've been doing for 5-10 years and to accept it off the bat, so I don't blame them at all. I do still hope that they'll come over entirely to the concept. We'll see what happens. :)
Seems like the frontend developers who are told to never use onclick= handlers have never used a more advanced UI framework before, like Apple's Interface Builder for example. In more advanced js frameworks like Ember.js, all the click handlers are essentially onclick= style. "this is the right way of doing things"
I feel like many of your team's complaints are due to the fact that they are old school web developers who have probably never wrote apps on the desktop before, where 2-way bindings are standard. The jQuery style of event binding is extremely brittle because it requires the DOM to have a specific structure.
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.
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.)
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.
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. :(
>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. ;) )
Yes, it is worth the effort to check out. While you can mash several things like sammy and other frameworks to make your own SPA type solution, Durandal already has done it for you (built on require.js, sammy, and knockout)
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.
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.
I looked at the source code for jQuery Ajax, and saw that it is basically a wrapper for the xmlhttprequest object. So I made my own wrapper, one where I don't have to specify the same parameters every time.
But the solution we use is something completely different which is hard to explain in a single post. It is based on CQRS and provides not only a way to communicate with the server, but validation of parameters. This works very well with Knockout observables, since you can create an object once and then execute it multiple times, when the observables have changed.
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.
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.
It's also not fair to compare angular to knockout, check out durandal, now that's a full blown framework built over knockout and requirejs, and can match any needs.
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.
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.
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.
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.
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.
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.
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.
74 comments
[ 4.2 ms ] story [ 65.6 ms ] threadhttp://minifiedjs.com
Now you have a full stack in like 50k.
I always check my web work on as many browsers as possible anyway, since quirks abound at all levels of the stack.
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...
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
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.
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.
Looks like this version makes what I believe to be Knockout's biggest strength (the data binding) that much stronger.
Knockout got attention, but there are so many frameworks that it is not so easy to see the big advantage of one.
The main difference seems to be that in Knockout has 'observables' that are part of your view model, whereas with Ractive you interact with your view model via Ractive's functions.
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!
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.
We went to that after hell with pages littered with applyBinding calls.
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.
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.
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.
"Knockout is a library that binds Javascript objects to DOM nodes."
It accomplishes that task amazingly well. It essentially takes this DOM node:
And let's you bind a JS object like this to it: 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?)
http://stackoverflow.com/a/9693933/20003
http://anexiledderryman.com/post/50565922110/javascript-sing...
Off topic, but would mind sharing what you used to create the diagram?
Beware, if you are thinking of using Knockout.js for a mobile friendly app, the binding / events can easily slow down your app.
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 ...
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!
Consistency and maintainability of a codebase is a big factor for me. If I have a large project with knockout I can nearly guarantee a fairly similar style across the codebase. Time spent being the owner of a large project convinces me that a framework like knockout is important. So for the life time of the project it gives new developers coming onboard a good idea what to expect from the outset.
I've never been good at convincing people of things, however, so it's been an uphill battle - one that I lost a lot of ground on early, and I feel like a lot of our frontend codebase suffered as a result. I do feel like they're slowly starting to warm up to the benefits of it now that they've had some maintenance problems with the current approach, but that's similar to sending an innocent man to prison for several years before discovering he's innocent - it'll take a while to undo what's been done, if it can be undone.
Now, none of this is to say that they're bad developers. They make amazing UIs that I couldn't even conceptualize (me being a backend jockey who is terrible at making things look good). It's hard for someone to hear about an entirely new approach to what they've been doing for 5-10 years and to accept it off the bat, so I don't blame them at all. I do still hope that they'll come over entirely to the concept. We'll see what happens. :)
I feel like many of your team's complaints are due to the fact that they are old school web developers who have probably never wrote apps on the desktop before, where 2-way bindings are standard. The jQuery style of event binding is extremely brittle because it requires the DOM to have a specific structure.
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 <!--ko stopBindings: true--> syntax.
(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.)
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
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. :(
Yes, it is worth the effort to check out. While you can mash several things like sammy and other frameworks to make your own SPA type solution, Durandal already has done it for you (built on require.js, sammy, and knockout)
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.
But the solution we use is something completely different which is hard to explain in a single post. It is based on CQRS and provides not only a way to communicate with the server, but validation of parameters. This works very well with Knockout observables, since you can create an object once and then execute it multiple times, when the observables have changed.
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.
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.
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...).
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.
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.
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.
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.
https://github.com/devmatters/backbone.rocks
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!
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.