Agree with suggestions above – more step by step guidance/recipes/patterns dealing with common web development scenarios will help get ko the adoption it deserves. As it stands, you’re left on your own in a lot of places, so I can understand why people would be reluctant to commit to it with so few pieces of a web app “in the box”. Our experience is that, compared to alternatives, ko doesn’t make a lot of easy things particularly easy. But that can be remedied with better collateral.
At the same time, improving the newbie experience won’t necessarily promote adoption, given that good alternatives with huge communities exist for common CRUD situations. What’s also needed is material that will showcase ko’s unique strength: the way templating, databinding, and dependency tracking work together to make complex UIs that are understandable and maintainable. The examples on the website such as the shopping cart and contacts editor are great at hinting at what’s possible with ko, but they have a toy-like feel. A more complex example with realistic quantities of data would capture people’s imagination and lessen their worries about ko scaling to real word scenarios.
For example, we’re using ko for a budget and performance management app that will replace one developed using Winforms. The legacy app uses an embedded spreadsheet to handle totals and formulas at various levels, conditional formatting, validation, etc. ko, together with newer browsers, will let us duplicate most of this behavior. You couldn’t do this until recently. If there is another library that would be more help, I don’t know what it is. For now, ko doesn’t need to make all this easy; it just has to make it possible.
So I’d just suggest that alongside material for new users, you also develop a tutorial around an app that takes Knockout to the limit of what it can do, and really gets people’s attention. Even if the code will likely be incomprehensible to newbies(!), it will show them what’s possible if they start down the road of learning ko. A groundbreaking app would also attract expert client side developers to ko, which would be a win for the community.
You just need to grow the ko community from tiny to small; it’s probably never going to be that big, but it has a niche to fill. It’s like F#, as opposed to C# or VB, and that’s great – thanks for all your work!
The examples on the website such as the shopping cart and contacts editor are great at hinting at what’s possible with ko, but they have a toy-like feel.
it’s probably never going to be that big, but it has a niche to fill.
sent from an internet enabled device
I can at least help you with the parameters problem (but they should
be made consistent on the page itself, I did note that as a problem
when I read through the page myself).
arguments). They have an arguments "array", with some of those
arguments being given a name (these are the arguments that you see).
When you call a function you give it some parameters which fill in the
places in the array, and if you leave some out, then those named
parameters have the value undefined. Now if you have a case where you
define less named arguments than you call the function with, no
problem, that just means that some parameters are hidden (but still
accessible through the special array named "arguments").
This also means that there is no dynamic dispatch of functions based
on the number/type of arguments so you cannot have function
overloading unless you implement the machinery yourself.
> On Jun 21, 11:58 am, Steven Sanderson <st...@codeville.net> wrote:
>> Stacey - thanks for the feedback about custom bindings. I'll be writing a
>> new tutorial about those soon, so maybe that will help to clarify things for
>> you. If you were able to say which specific part of the existing
>> documentation you weren't able to understand (please start a separate thread
>> if so), I'm sure one of us could help!
Definately I agree knockout docs assume you are more than a casual js
Hope that helps,
Sent from my iPhone