8 ms·

Knockout v3.0.0 released

158 points by johnny_reilly 13y ago

api 13y 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 http://minifiedjs.com Now you have a full stack in like 50k.
- moystard 13y 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).
  - api 13y 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.
wldlyinaccurate 13y 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 https://github.com/knockout/knockout/compare/v2.3.0...v3.0.0
- randlet 13y ago
  There's a release page for the 3.0 beta & RC here: https://github.com/knockout/knockout/releases https://github.com/knockout/knockout/releases
aforty 13y ago
Great framework but are those all the changes in 3.0.0?
- stevensanderson 13y 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-release-candidate-available/ http://blog.stevensanderson.com/2013/10/08/knockout-3-0-rele... * http://blog.stevensanderson.com/2013/07/09/knockout-v2-3-0-released-v3-0-0-beta-available/ http://blog.stevensanderson.com/2013/07/09/knockout-v2-3-0-r...
  - gwely 13y ago
    Where can I report tests failing here? http://knockoutjs.com/spec/runner.html http://knockoutjs.com/spec/runner.html
    - stevensanderson 13y ago
      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 13y ago
        Nice, everything is passing now. Thanks!
benmorris 13y 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 13y 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).
  - benmorris 13y 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 13y 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 13y 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 13y 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 13y ago
  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.
jcutrell 13y 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/ 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 13y 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.
  - hardwaresofton 13y ago
    If you like frameworks that do one thing, and one thing well, then you'll like knockout. Amazing data-binding system
    - prottmann 13y ago
      But for only one thing i would not use a framework, a library like http://ractivejs.org http://ractivejs.org is enough for that.
      - dminor 13y ago
        That looks pretty similar to Knockout - I don't think you can really claim that one is a library and the other a framework.
        dodyg 13y ago
        Ractive.js just cares about the view - everything else is up to you.
        13y ago
Nekorosu 13y 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 13y 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.
- taude 13y 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.
  - ibrahima 13y 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.
Bahamut 13y 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 13y ago
  http://blog.nebithi.com/knockoutjs-vs-angularjs/ http://blog.nebithi.com/knockoutjs-vs-angularjs/
  - Bahamut 13y 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.
    - notdonspaulding 13y ago
      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?)
- dustingetz 13y ago
shaydoc 13y 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-single-page-application-architectural http://anexiledderryman.com/post/50565922110/javascript-sing...
- jbigelow76 13y ago
  That looks like a very clear structure, I like it. Off topic, but would mind sharing what you used to create the diagram?
  - shaydoc 13y ago
    Of course, the wonderful d3.js
aymeric 13y ago
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 13y ago
  Can you quantify this statement, because performance has greatly improved in recent releases!
  - aymeric 13y ago
    On my app, it takes 2s to render 174 tasks on my desktop. Imagine on a mobile phone...
EdgarVerona 13y 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.
krosaen 13y 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.
- taude 13y 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.
notdonspaulding 13y 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 13y 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 13y 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 13y 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 https://github.com/devmatters/backbone.rocks
petrohi 13y ago
Great framework! Imho best at having powerful yet non-leaky and clear abstractions. We use it to build kato.im web app.
rekoros 13y 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 13y 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.

158 points by johnny_reilly 13y ago

api 13y 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 http://minifiedjs.com Now you have a full stack in like 50k.

moystard 13y 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).
- api 13y 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.

wldlyinaccurate 13y 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 https://github.com/knockout/knockout/compare/v2.3.0...v3.0.0

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

aforty 13y ago

Great framework but are those all the changes in 3.0.0?

stevensanderson 13y 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-release-candidate-available/ http://blog.stevensanderson.com/2013/10/08/knockout-3-0-rele... * http://blog.stevensanderson.com/2013/07/09/knockout-v2-3-0-released-v3-0-0-beta-available/ http://blog.stevensanderson.com/2013/07/09/knockout-v2-3-0-r...
- gwely 13y ago
  Where can I report tests failing here? http://knockoutjs.com/spec/runner.html http://knockoutjs.com/spec/runner.html
  - stevensanderson 13y ago
    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 13y ago
      Nice, everything is passing now. Thanks!

benmorris 13y 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 13y 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).
- benmorris 13y 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 13y 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 13y 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 13y 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 13y ago
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.

jcutrell 13y 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/ 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 13y 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.
- hardwaresofton 13y ago
  If you like frameworks that do one thing, and one thing well, then you'll like knockout. Amazing data-binding system
  - prottmann 13y ago
    But for only one thing i would not use a framework, a library like http://ractivejs.org http://ractivejs.org is enough for that.
    - dminor 13y ago
      That looks pretty similar to Knockout - I don't think you can really claim that one is a library and the other a framework.
      - dodyg 13y ago
        Ractive.js just cares about the view - everything else is up to you.
        13y ago

Nekorosu 13y 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 13y 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.

taude 13y 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.
- ibrahima 13y 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.

Bahamut 13y 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 13y ago
http://blog.nebithi.com/knockoutjs-vs-angularjs/ http://blog.nebithi.com/knockoutjs-vs-angularjs/
- Bahamut 13y 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.
  - notdonspaulding 13y ago
    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?)
dustingetz 13y ago

shaydoc 13y 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-single-page-application-architectural http://anexiledderryman.com/post/50565922110/javascript-sing...

jbigelow76 13y ago
That looks like a very clear structure, I like it. Off topic, but would mind sharing what you used to create the diagram?
- shaydoc 13y ago
  Of course, the wonderful d3.js

aymeric 13y ago

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 13y ago
Can you quantify this statement, because performance has greatly improved in recent releases!
- aymeric 13y ago
  On my app, it takes 2s to render 174 tasks on my desktop. Imagine on a mobile phone...

EdgarVerona 13y 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.

krosaen 13y 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.

taude 13y 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.

notdonspaulding 13y 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 13y 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 13y 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 13y 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 https://github.com/devmatters/backbone.rocks

petrohi 13y ago

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

rekoros 13y 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 13y 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.