Hm. In my case, I would have had to invent something like ko.observable anyway, so I guess it works for me. Maybe I'll learn better when things get more complicated.
I'm not saying that it's wrong. KO's approach is a defensible architectural alternative. I guess I took an unnecessarily snotty tone in my previous comment.
However, KO's design it didn't sit well with how I wanted things to work. Basically I want plain javascript for my own core logic and then to have round-trip binding to the user interface with a minimum of fuss.
For simple cases, Angular does that reasonably well. More complicated cases require a much more intimate engagement with Angular's design and architecture, which is where my gripe about the docs becomes relevant.
No offense taken. I did find that my "model" code was basically the same as the viewmodel. I'm not sure how much that matters or how hard it will be to change, hence "maybe I'll learn better".
However, KO's design it didn't sit well with how I wanted things to work. Basically I want plain javascript for my own core logic and then to have round-trip binding to the user interface with a minimum of fuss.
For simple cases, Angular does that reasonably well. More complicated cases require a much more intimate engagement with Angular's design and architecture, which is where my gripe about the docs becomes relevant.