Hacker News Reader

Comment by jimsteinhart | Hacker News Reader

Does anyone have any idea why it is that Knockout is often neglected in these comparisons?

I think it is seen as different, because Knockout brands itself as MVVM, whereas other frameworks are usually mentioned in MVC context

Anti-Microsoft bias is my guess.

I've been using Knockout for months and I had no idea it was built by a Microsoft employee. And why should anyone care?

I've dropped Knockout simply because it is the easiest way to paint yourself in the corner. Its magic is ok for the simplest cases. Went with backbone, less magic, but solid foundation.

I'm working on a pretty major project with Knockout, and that's not really been my experience.

The "magic" is basically "it has two-way data binding". Which is magic, but no more so than the same feature in Angular, Ember.js, or the relevant Backbone plugins. Two-way data binding is pretty magical; if you need it that's probably good, if you don't really need it, it's bad.

Comparing vanilla Backbone to Knockout seems a bit odd; they have almost no overlap, and they don't really solve the same problems. Conversely, if you are using Backbone to solve a Knockout-style problem, it's either not really the sort of problem Knockout is designed for (ie, no need for two-way data binding) or you've added a bunch of magic onto Backbone (either through writing it yourself or using one of the many plugins for Backbone).

I just don't think you can use Backbone, solve the sort of problems that Knockout is good for, and have less magic. Two-way data binding is magic, and it's like...90% of what Knockout does. Either your stack includes that magic, or you can't compare yourself to Knockout.

Probably because it is chief maintainers are Microsoft employees?

Would that be considered negative? In any case, KO is not a Microsoft project, and only one of the core team members (me) works for MS.

Anyway, many projects are built with KO, and its 3500+ watchers on GitHub suggests it's something like 7 times as widely used as one of the libraries in the article, so it's perhaps inaccurate to say that nobody considers it!

I don't think it is, but others might. I've often sung KO's praises but it always seems fall to the wayside.

Personally I think KO would greatly benefit from more architectural guidance (as i mentioned above). You're left on your own architecturally and structurally, with little guidance or higher level constructs to assist. This is much like backbone, but with backbone there is a lot of guidance out there, and even frameworks built atop of it (e.g. Marionette) which aim to instil best practices.

Things I'd like to see, which might quell other's trepidation:

* A large-scale demo app, with a detailed run-through of the how's and why's

* A guide to unit testing ko apps

* Drop IE6 (maybe even IE7?!) support to make it super lightweight. It's never going to be backbone lightweight, but imagine being able to say the tiniest front-end framework with no dependencies - that's a powerful message

Best practices and a large-scale app would be awesome!

The people in the IRC channel are very helpful (and will happily tell a cleaner way to do it than the KO examples on their website), but to have all this written up would be excellent.

Thanks for the tip about the IRC channel, didn't realise there was one out there. I assume it's on freenode?

But for most, hitting up an IRC channel is a barrier to entry they just won't have the enthusiasm to overcome. Such advice should be front and center, easy to access, up to date and canonical.

Freenode indeed :)

Knockouts documentation is fantastic, but geared at a very novice level. The lack of any guidance on unit testing is a particular frustration.

I agree. The documenation is awesome. Concise, accurate and not confusing (i'm looking at you angular). And the interactive online tutorial is the icing on the cake. I posit that a complete beginner could get up and running with KO within a few hours.

But again, for non-beginners, I'd like to see more in-depth stuff.

In some circles it would be considered negative.

For example, I have spent most of my career using Microsoft developer tools building LOB applications. I think the MS dev toolset is great.

At one point I was involved in building a consumer web app and attended various "startup" community events. I would start chatting to people (generally Rails/PHP devs) and as soon as I mentioned I was building a web app using MS tech they would look at me as if I was mad. Sometimes they would even make excuses to stop chatting and find somebody else to talk to - I concluded from this that there is definitely some anti MS feeling within the startup community.

Anyway, this has gone off topic, but thought it was worth mentioning. BTW, one of my colleagues has just started using Knockout and thinks it is great!

I think it's dismissed because it is "just" a view/model binding library IMO as opposed to "full" MVC frameworks (with routing etc).

Personal opinion: I used knockout before switching to Angular, I woudn't switch back, why bother with observables when you can just use plain JS?

Since you asked, from my experience, there is one very good reason for KO-style functional observables rather than plain JS: immediate naming errors. If I type obj.prop when I should have typed obj.Prop, it simply returns undefined. But if I said obj.prop(), it excepts. This means that naming errors are diagnosed right at the site and immediately. I've found this a significant advantage to KO-style observables, particularly when refactoring code.

Naming conventions is usually enough for me. Not having to wrap every declaration/get/set (with Ajax data in particular) still outweight this little side effect IMO.

Reply on news.ycombinator.com