5 ms·

Out of curiosity, where's the love for knockout? It's mature, and works well, but gets no press anymore.

dustingetz 13y ago
Knockout and Ractive take opposite approaches to managing the DOM. There is value in understanding all approaches and then choosing the best fit.
- emn13 13y ago
  They do? It looks superficially similar to me anyhow. What's the difference? I mean, the syntax is different, but unlike other templating systems they try to be "smart" about what needs rerendering by tracking dependencies.
scott_karana 13y ago
There's actually an aside in the article that specifically thanks Knockdown.js and Backbone.js for their contributions :)
- rich_harris 13y ago
  Absolutely! We're all standing on the shoulders of giants like Steve Sanderson (KO creator).
stoodder 13y ago
I've got a library called Falcon.js (https://github.com/stoodder/falconjs https://github.com/stoodder/falconjs) that essentially provides a Model, Collection, View framework on top of Knockout that I've been using for over a year now on internal and client projects. It works really well for single page and mobile web hybrid apps, it's completely unit tested, and I'm currently in the works of getting the documentation finished up. It's only dependency is jQuery and it comes bundled with Knockout 2.2.1 built in. Feel free to take a look at what I have so far, I'd love your feedback. Again, I apologize for the incomplete state of documentation at the moment but I promise everything'll be wrapped up sooner than later!
- Contra 13y ago
  The readme is empty and the only url on it is broken
  - lh7777 13y ago
    Link just worked for me. Looks interesting; I'd love to see an example -- even just a hello world.
    - stoodder 13y ago
      Thanks for the quick feedback! As a quick update, I threw together a todo app that also describes some of the basic functionality of Falcon. Check it out: http://jsfiddle.net/stoodder/2ZX52/20/ http://jsfiddle.net/stoodder/2ZX52/20/
scrabble 13y ago
I've noticed the same. I really like Knockout. It seems to be perfect when I need to add MVC into an existing code base slowly.
ww520 13y ago
Guess not much PR or marketing from the Knockout folks. I have used knockout in couple projects and it has work well.
msutherl 13y ago
The website is an eyesore (literally).
- msutherl 13y ago
  Sorry, this was too terse. I'm inclined not to use Knockout because I find the branding unappealing and a bit too visually intense. I think backbone.js[1] has been so successful in no small part because the website is excellent. Very simple, easy on the eyes, explains itself, and gets right to the point: documentation. Angular's too[2]. [1] http://backbonejs.org/ http://backbonejs.org/ [2] http://angularjs.org/ http://angularjs.org/
  - boubiyeah 13y ago
    What. Choosing a framework/library because it has a nice website is a bit... Superficial.
    - msutherl 13y ago
      Choosing a product because you liked the commercial, choosing a book because you like the cover, choosing a bottle of wine because you like the label, choosing a computer because you like the design, choosing clothes because you think they look good is a bit... Superficial, no? When you choose a technology with a bad website, you have to actually look at that website for hours and hours reading the documentation. This can be incredibly frustrating for people who are sensitive to such things. But more importantly, there's a subtle biasing. People usually do not make rational decisions about technology. The design of the website is a more significant factor than you might think, at least in my experience of watching people make such decisions. If it wasn't, then why would anybody bother to make a good website?
curveship 13y ago
I've been using knockout heavily for a project recently and have come to really like it. This is a small to mid size website, about 6 engineer months of effort and somewhere in the mid 10klocs of custom javascript. Some strengths of knockout: - it builds on the "Good Parts" of javascript, in that KO observables are just closures. You can pass them around or attach them to different objects however you feel like. For instance, we built a standard UI widget for entering currency values. Anywhere we need to accept currency, we instantiate one of these widgets and pass it the observable that holds the value. Clean, easy, encapsulated. - Some people have a distaste for the "()" syntax: obj.prop() rather than obj.prop. There's some truth there, but the "()" syntax has one big benefit that overrides the slight ugliness in my experience: it catches naming errors immediately right at their source. If you've ever had to refactor a fairly big piece of JS, you know that one difficulty is correcting all the changed references. And if you miss one, the bug may be subtle, as the old reference doesn't except but quietly returns undefined. With knockout, the old reference blows up immediately, as undefined isn't a function. This is a big win. We had some growing pains with knockout. Lessons learned: - don't build anything but a small web app the way the knockout examples demonstrate. The reason is that while knockout claims to be MVVM, their examples are really just VVM -- there're no distinct model classes. They store data directly in the viewmodel classes. Bad things follow as your app grows: since the data is in the VM, any view that needs the data (i.e., all of them) needs to be bound to that same VM, meaning that your one VM ends up needing to feed several views. You find yourself annotating your viewmodel into sections -- "// these properties are used by view X ... // these properties are used by view Y" etc. Yech. Much better to have true model classes, then build a VM class on top of the model for each of your views. - we now make heavy use of named templates to decompose large views into more manageable pieces. We wrote a simple custom binding to make this easy: since each VM is designed to work with a single view (see prior note), we put the #id of the view's named template into a .Template property of the VM class. The custom binding inspects this property and binds the VM class to its named template.
- aforty 13y ago
  Oh how I wish you had written that 6 mons ago. Learned those same lessons in a painfully slow way. I've been using knockout for the last 3 years, mostly for small projects but the last one has been a big one. Growing pains but its working out great. Knockout needs more love.

Knockout and Ractive take opposite approaches to managing the DOM. There is value in understanding all approaches and then choosing the best fit.

emn13 13y ago
They do? It looks superficially similar to me anyhow. What's the difference? I mean, the syntax is different, but unlike other templating systems they try to be "smart" about what needs rerendering by tracking dependencies.

scott_karana 13y ago

There's actually an aside in the article that specifically thanks Knockdown.js and Backbone.js for their contributions :)

rich_harris 13y ago
Absolutely! We're all standing on the shoulders of giants like Steve Sanderson (KO creator).

stoodder 13y ago

I've got a library called Falcon.js (https://github.com/stoodder/falconjs https://github.com/stoodder/falconjs) that essentially provides a Model, Collection, View framework on top of Knockout that I've been using for over a year now on internal and client projects. It works really well for single page and mobile web hybrid apps, it's completely unit tested, and I'm currently in the works of getting the documentation finished up. It's only dependency is jQuery and it comes bundled with Knockout 2.2.1 built in. Feel free to take a look at what I have so far, I'd love your feedback. Again, I apologize for the incomplete state of documentation at the moment but I promise everything'll be wrapped up sooner than later!

Contra 13y ago
The readme is empty and the only url on it is broken
- lh7777 13y ago
  Link just worked for me. Looks interesting; I'd love to see an example -- even just a hello world.
  - stoodder 13y ago
    Thanks for the quick feedback! As a quick update, I threw together a todo app that also describes some of the basic functionality of Falcon. Check it out: http://jsfiddle.net/stoodder/2ZX52/20/ http://jsfiddle.net/stoodder/2ZX52/20/

scrabble 13y ago

I've noticed the same. I really like Knockout. It seems to be perfect when I need to add MVC into an existing code base slowly.

ww520 13y ago

Guess not much PR or marketing from the Knockout folks. I have used knockout in couple projects and it has work well.

msutherl 13y ago

The website is an eyesore (literally).

msutherl 13y ago
Sorry, this was too terse. I'm inclined not to use Knockout because I find the branding unappealing and a bit too visually intense. I think backbone.js[1] has been so successful in no small part because the website is excellent. Very simple, easy on the eyes, explains itself, and gets right to the point: documentation. Angular's too[2]. [1] http://backbonejs.org/ http://backbonejs.org/ [2] http://angularjs.org/ http://angularjs.org/
- boubiyeah 13y ago
  What. Choosing a framework/library because it has a nice website is a bit... Superficial.
  - msutherl 13y ago
    Choosing a product because you liked the commercial, choosing a book because you like the cover, choosing a bottle of wine because you like the label, choosing a computer because you like the design, choosing clothes because you think they look good is a bit... Superficial, no? When you choose a technology with a bad website, you have to actually look at that website for hours and hours reading the documentation. This can be incredibly frustrating for people who are sensitive to such things. But more importantly, there's a subtle biasing. People usually do not make rational decisions about technology. The design of the website is a more significant factor than you might think, at least in my experience of watching people make such decisions. If it wasn't, then why would anybody bother to make a good website?

curveship 13y ago

I've been using knockout heavily for a project recently and have come to really like it. This is a small to mid size website, about 6 engineer months of effort and somewhere in the mid 10klocs of custom javascript. Some strengths of knockout: - it builds on the "Good Parts" of javascript, in that KO observables are just closures. You can pass them around or attach them to different objects however you feel like. For instance, we built a standard UI widget for entering currency values. Anywhere we need to accept currency, we instantiate one of these widgets and pass it the observable that holds the value. Clean, easy, encapsulated. - Some people have a distaste for the "()" syntax: obj.prop() rather than obj.prop. There's some truth there, but the "()" syntax has one big benefit that overrides the slight ugliness in my experience: it catches naming errors immediately right at their source. If you've ever had to refactor a fairly big piece of JS, you know that one difficulty is correcting all the changed references. And if you miss one, the bug may be subtle, as the old reference doesn't except but quietly returns undefined. With knockout, the old reference blows up immediately, as undefined isn't a function. This is a big win. We had some growing pains with knockout. Lessons learned: - don't build anything but a small web app the way the knockout examples demonstrate. The reason is that while knockout claims to be MVVM, their examples are really just VVM -- there're no distinct model classes. They store data directly in the viewmodel classes. Bad things follow as your app grows: since the data is in the VM, any view that needs the data (i.e., all of them) needs to be bound to that same VM, meaning that your one VM ends up needing to feed several views. You find yourself annotating your viewmodel into sections -- "// these properties are used by view X ... // these properties are used by view Y" etc. Yech. Much better to have true model classes, then build a VM class on top of the model for each of your views. - we now make heavy use of named templates to decompose large views into more manageable pieces. We wrote a simple custom binding to make this easy: since each VM is designed to work with a single view (see prior note), we put the #id of the view's named template into a .Template property of the VM class. The custom binding inspects this property and binds the VM class to its named template.

aforty 13y ago
Oh how I wish you had written that 6 mons ago. Learned those same lessons in a painfully slow way. I've been using knockout for the last 3 years, mostly for small projects but the last one has been a big one. Growing pains but its working out great. Knockout needs more love.