4 ms·

We used knockout on a recent project and it has been a disaster. Maybe for trivial UI's it's fine, but for anything complex you spend a lot of trouble hacking

by LargeWu 15y ago

We used knockout on a recent project and it has been a disaster. Maybe for trivial UI's it's fine, but for anything complex you spend a lot of trouble hacking around knockout's way of doing things, resulting in a completely unmaintainable mess. I think the plan is to rip out knockout and switch to backbone at our earliest convenience.

prasunsen 15y ago
Same here. Many things didn't work at all, other were very painful to do. The project end up nowhere.
deleted 15y ago
[deleted]
- exogen 15y ago
  Hmm, if you're binding every view in your app to a single view model, you're doing it wrong. You're "supposed" to have a model for each view/type/whatever and bind only the necessary markup — not bind the whole page to one big view.
  - deleted 15y ago
    [deleted]
  - Que 15y ago
    I deleted my original comment and the response to your reply; upon review I found them not to lend anything helpful to the conversation but rather to promote argumentative behavior.
ErrantX 15y ago
Yep; feeling this pain. I was casting around for a simple way to implement a responsive UI in our latest application and Knockout appeared to be a good option (I'd not come across Backbone at that point). Now it just feels like more work... I have written so many custom bindings it is unreal! (I realise this is, as the author notes, mostly my failing in writing JS :))
- exogen 15y ago
  I use Knockout heavily at work and agree that it can become a mess. But most of the ugliness I've seen is when people try to be too clever, not really understanding what Knockout can already do (e.g. writing custom bindings to do lots of 'dynamic' stuff, when each binding is already essentially a dependentObservable and perfectly capable of doing what they want). I actually find writing custom bindings pretty enjoyable. That's where the nice separation and reusability come from.
IanDrake 15y ago
Strange. I've used it for forms heavy apps and glamour apps with no forms and had great experience with both. Yes, I have a lot of custom bindings, but most are very reusable, and many have saved my butt (like wrapping bindings to include JQM's markup enhancements). That said, I wasn't new to MVVM when I first came across Knockoutjs, so I used it efficiently from the get-go. If you don't like MVVM, you won't like Knockoutjs.
ghusbands 15y ago
I can appreciate that that (and the similar stories in reply) would happen. I recently successfully developed a complicated application using Knockout, but it involved fully committing to the rather strict computation model that is implied. I also had to modify and extend the core of the library. I'd say that Knockout can be suitable for large applications, but that you need to handle having an unusual computational model pervade your code. If you're interacting with existing code, it can be tricky to get inputs and outputs mapped correctly, but the knockback library mentioned in the article probably solves that for backbone users. One rule of thumb that might be useful is that any (non-event-handler) function you give to Knockout must handle being called an arbitrary number of times at arbitrary times, with some inputs being potentially outdated. If it cannot, you're not using the computational model the library essentially requires.

by LargeWu 15y ago

prasunsen 15y ago

Same here. Many things didn't work at all, other were very painful to do. The project end up nowhere.

deleted 15y ago

[deleted]

exogen 15y ago
Hmm, if you're binding every view in your app to a single view model, you're doing it wrong. You're "supposed" to have a model for each view/type/whatever and bind only the necessary markup — not bind the whole page to one big view.
- deleted 15y ago
  [deleted]
- Que 15y ago
  I deleted my original comment and the response to your reply; upon review I found them not to lend anything helpful to the conversation but rather to promote argumentative behavior.

ErrantX 15y ago

Yep; feeling this pain. I was casting around for a simple way to implement a responsive UI in our latest application and Knockout appeared to be a good option (I'd not come across Backbone at that point). Now it just feels like more work... I have written so many custom bindings it is unreal! (I realise this is, as the author notes, mostly my failing in writing JS :))

exogen 15y ago
I use Knockout heavily at work and agree that it can become a mess. But most of the ugliness I've seen is when people try to be too clever, not really understanding what Knockout can already do (e.g. writing custom bindings to do lots of 'dynamic' stuff, when each binding is already essentially a dependentObservable and perfectly capable of doing what they want). I actually find writing custom bindings pretty enjoyable. That's where the nice separation and reusability come from.

IanDrake 15y ago

Strange. I've used it for forms heavy apps and glamour apps with no forms and had great experience with both. Yes, I have a lot of custom bindings, but most are very reusable, and many have saved my butt (like wrapping bindings to include JQM's markup enhancements). That said, I wasn't new to MVVM when I first came across Knockoutjs, so I used it efficiently from the get-go. If you don't like MVVM, you won't like Knockoutjs.

ghusbands 15y ago

I can appreciate that that (and the similar stories in reply) would happen. I recently successfully developed a complicated application using Knockout, but it involved fully committing to the rather strict computation model that is implied. I also had to modify and extend the core of the library. I'd say that Knockout can be suitable for large applications, but that you need to handle having an unusual computational model pervade your code. If you're interacting with existing code, it can be tricky to get inputs and outputs mapped correctly, but the knockback library mentioned in the article probably solves that for backbone users. One rule of thumb that might be useful is that any (non-event-handler) function you give to Knockout must handle being called an arbitrary number of times at arbitrary times, with some inputs being potentially outdated. If it cannot, you're not using the computational model the library essentially requires.