Learning resources for Knockout

[fla...@gmail.com]

Hey all

I've been pretty quiet on here lately, which is because I've been
putting my Knockout time into building some new resources to help
people learn how to use the library. This will continue for a week or
two, then hopefully I'll have a very cool new thing to show you :)

As part of this, I'm collecting ideas for tutorials and patterns that
KO developers should know about. Currently I'm thinking of starting
with:

Introductory tutorials
===============
1. Understanding observables and the MVVM pattern
2. Working with lists and templates
3. Navigation on single-page applications
4. Loading and saving data
5. Creating custom bindings

Intermediate-level recipes/patterns
=========================
1. Validation
2. Detecting when an object graph has been modified
3. Using Knockout with CoffeeScript
4. Using Knockout with ASP.NET MVC
5. Using Knockout with Ruby on Rails

I'd be interested if you have any feedback about these topics. What's
missing from these lists?

- For "introductory topics" I'm looking for the top few most
universally essential concepts that every newcomer should start by
learning about. These will be written and presented very nicely, which
means that the number that I/we can produce is limited.
- For "intermediate-level recipes/patterns", however, I'm looking for
a possibly wider range of topics that might be more subjective and
possibly rely on external plugins. These might be set up more like a
wiki so we can source contributions from the community.

Thanks for any suggestions!
Steve

[Nate]

Cool Steve. I would say that many of the Jsfiddle references point to
topics that are often raised here. Searching this forum for JsFiddle
examples may help define the topics and solutions.
I would definitely like a list of the utility functions with example
of how and why I would use them.
Validation for dynamic controls is also important. Andrew provided a
good example for this.

[gaffe]

One thing that would be useful to me at least would be a simple example (both client and server side code with MVC3) of making an ajax call that POSTs a viewmodel object to the server and gets a reply and then updates that viewmodel object (by object I mean {firstname, lastname}).

[gaffe]

If you have an example where that object is nested within another object that would be useful since I have had trouble correctly updating viewmodel objects from classes passed back from MVC3, and saw some questions from others along these lines in the past. Perhaps a good example is buried in the fiddles somewhere on here even, but I have not found it yet ;)

[Andrew Booth]

Hi

Perhaps more on the "recipe"/subjective spectrum, some possible topics might be below. These are ones that touch on my day-to-day commercial development scenarios, using client side scripting.

[1] Knockout and Dates (formatting, binding, date picker, serializing)

[2] Knockout with sorting (jQuery UI) and drag and drop (HTML5)

[3] Knockout, bindings and jQuery Animate

[4] Knockout and the Facebook Javascript SDK (login, logout, profiles, Graph API)

[5] Knockout, infinite scroll and streams

Andy

[Scott Messinger]

+1 to all of Andrew's suggestions. I think these would be very useful and show how knockout.js solves common js problems.

Also, regarding the tutorials Steve suggested, I like them all! I suggest starting with a tutorial which walks through all the parts of a client side app. Specifically:

1) Syncing data to a server

2) Routing (responding to hash changes)

3) Responding to events

4) Updating the view

Comparing backbone and knockout, backbone has 5 times the number of github watchers as backbone. Why is this? Knockout is more capable and does the hard stuff (updating the view) while backbone leaves updating the view to the developer. I think backbone took off despite it's obvious shortcomings because it solves all the significant problems of client side development (see the list above). It's very light and leaves much to be desired in complex apps. However, because it addressed all the problems, developers used it as a framework to add new features and develop cool apps. 

By comparison, knockout's documentation beautifully addresses issues 3 and 4 but gives scant attention to problems 1 and 2. For instance, the mapping plugin (which is amazing!) is a PLUGIN, not a core part of the app. Is there a better way to tell developers that knockout.js isn't about creating rich client web apps than relegating server communication to a plugin? (NOTE: I don't care whether it's a plugin or not...I think it's a messaging issue, not a code one)

Because knockout didn't address problems 1 and 2 in the documentation, I didn't initially use it. I started using backbone but backed away once I faced the complexity of updating the views. I came back to knockout to see if I could make rest calls in an organized way...fortunately, I figured out how to do this and fell in love with knockout. I also stumbled across a message in the listserve about responding to hash changes (https://gist.github.com/970636). Knockout CAN address problems 1 and 2--it just needs to be communicated. 

I think Knockout.js needs the Rail's "Blog in 15 minutes." I recommend creating a tutorial which walks through the four problems above (and others I missed) of client side development. The tutorial should shows developers how knockout can form the basis for rich, client side apps, not just nifty view updates. Specifically, I have something like this in mind: http://www.jamesyu.org/2011/01/27/cloudedit-a-backbone-js-tutorial-by-example/

The tutorial does more than just walk through creating a backbone app--it demonstrates solid conventions around organizing code and functions. I'd like to see something similar for the knockout.js community: an overview of an app that demonstrates solid conventions I can use as I build my own app.

In an overview tutorial, not all the concepts are fully explained. IMO, this is okay. Developers are smart enough to figure some of it out and can wait for the more in depth tutorials. Giving developers the big picture helps them have a mental framework to hang the other concepts you'll write about. I know I would have appreciated it and I reckon a good number of other developers would as well.

Steve, thanks for doing these tutorials! I'm excited to see them come out!

Thanks!

Scott

[tarlano]

+1 for Knockout w/ CoffeeScript !!!!

[Roy Jacobs]

I agree with Scott's suggestions. I think the most important tutorial we can have for Knockout is a tutorial that shows the "blog in 15 minutes", complete with history management, server communication, etc.

The fact that you need knockout plus maybe a bunch of other plugins is not relevant, it should just show that this is a powerful combination of technology that is really useful!

Roy

[oldman]

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!         

[Scott Messinger]

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.  

I completely agree. In fact, before I figured out how to integrate ajax in an organized way, I described KO as a nice toy.

it’s probably never going to be that big, but it has a niche to fill.  

I disagree. I think KO could be huge if it presents itself as a client side framework, instead of presenting as a nifty toy. As I see it, the main competition is Sproutcore 2.0 (http://blog.sproutcore.com/sproutcore-2-0-beta-1-released/). SC is about the same size as KO and also does the sweet view updating. The downside to SC is its templating: you have to use handlebar.js helpers. The helpers are, imo, more complex than using data-binding. Personally, I hate them. The upside to SC is the framework aspect--you can use it to do the whole client side (routing, server syncing, etc). KO can compete as the simpler SC if it articulates a clear, obvious way to do routing and server communication.

[gaffe]

Actually an excel-type spreadsheet app example for knockout would be awesome.

There are tons of grid components out there, but none can support excel formulas with dependencies between the cells, etc, very well. Even google couldn't do  client side excel very well, for example, the excel in google apps is terrible on an ipad or iphone. If knockout could do this well it would be huge.

For a lot of business apps, excel is bread and butter, and many of these apps are not even web based because all the web grid components out there are just that bad. I have yet to see a client side component that someone can cut and paste a bunch of cells from excel into with rich excel-like functionality like cell validation, formulas, etc.

I predict that as soon as someone builds an input form front-end that looks and acts like excel and isn't a pain to work with they will be wildly successful. 

[oldman]

Well, I hope I'm wrong and Knockout catches on in a big way. 

Seems like broad adoption would to require the kind of things you suggest. But I like the fact that ko is kind of a "bag of tricks" and not a complete client side framework that makes some things easy and other things difficult or impossible. It gives you a minimal architecture that solves some hard problems and leaves you on your own in a lot of areas - which I'm fine with.

Maybe you're right. We're still waiting for a "full stack" client platform - and at it's center will be something a lot like Knockout.        

               

       

[oldman]

KO has a lot of the basic building blocks of a spreadsheet. So it would probably be possible to generate a KO app by turning editable cells into observables, formula cells or conditional formats into dependent observables, etc.   

[Entity Spaces]

EntitySpaces, MVVM, JSON, and Knockout, A Great Way to Write
Javascript code @ http://tinyurl.com/5w5qyn2

[Stacey Thornton]

Grids are neat, sure. I don't know, you can call me cynical or rude -
perhaps I am just too much of an amateur programmer to understand how
common grids/spreadsheets really are in the echelon of coding you guys
are working on. I am a small person, with a small business, and I've
never had to utilize a grid or spreadsheet code framework in a project
yet. I am personally very tired of seeing them as the default
examples. They don't mean a lot to me and they usually leave me just
confused.

Seeing the documentation for the utils functions would be a great
start. I am very fond of RPN's blog post about jQuery UI's sortable
feature (since I was the one who asked so much about it last year)

The other thing I'm going to say something that may be a bit rude. I
in no way mean it to be hurtful, rude, disrespectful, or even angry.
I'm just stating it the best way I know how.

The documentation for custom bindings confuses me like nobodies
business.
I just don't get it. It makes no sense to me.

I attribute 50% of that to the fact that I am a javascript newbie. I
attribute a bit more to the fact that I am also a Knockout newbie. But
I really think the documentation on custom bindings makes a lot of
assumptions about the programmer that narrow its audience.

If I may, before the community tells me how inconsiderate I am and how
you do this project in your free time, I discount none of that. You've
done a spectacular job, I love your framework, and as you can see from
my posts in your forums I very heavily support it - but I really think
the documentation approach to custom bindings could use some
reconsideration.

http://knockoutjs.com/documentation/custom-bindings.html

I realize you try very hard to explain what everything is on this
page. But this example is pretty much one of the only ones on the
site, and trying to apply it to something far more complicated (like
jQuery UI in general) was exceptionally confusing. You are an
exceptionally brilliant person, and your documentation sometimes fails
to realize that many of us, like myself, are just not on the same
level that you are.

Perhaps it is just me - but most of my peers that I know in real life
that have looked at knockout all agree with me on this. The
documentation itself is what needs some of the most improvement. You
have one of the best frameworks out there, and with that comes the
weight of having a level of complexity that has to be documented more
heavily.

[Andrew Goodnough]

I'm very impressed with what I've seen of Knockout so far.  I think more recipe style examples as documentation would be great.  For me, seeing something used in an example makes me aware of it, then I can search out that method or technique to get more information.  I don't think having a working back-end is necessary or even desirable as the server-side is by definition a black box.  My back-end is Scala and Lift but I notice a lot of MS developers here.  That said, there should be some pretty solid recipes showing data access through AJAX to show the flow of data back and forth, using stubbed out JSON or an echo endpoint.  I've also seen the power of JSFiddle in the last few days so maybe some embedded JSFiddles could help with the live recipes.  From what I've seen a search through my gmail account for 'rpn' would get us half the way there. :-)  I'm still finding my way, but for my part, I'll keep track of the kind of recipe style examples I'd like to see and keep a list and try to work through them and share as I go.

Andy

BTW, I've ajaxified the Meal Upgrades example from the documentation.  http://jsfiddle.net/agoodno/UPQjE/ 

[smurfke]

The fact that Knockout focuses on one thing (MVVM) and does that one thing very well covers the main part of its strengths.

Knockout does not force you to write code in a certain way. Code can be organised at will, and can therefore be combined with the framework(s) one chooses.

Making Knockout better does not equal making Knockout bigger per se. It's a decision to be made by the author. We might see integrated support but since you're not bound to a single framework, I believe a lot of developers are satisfied with the freedom of picking the best tools for the job.

Investing time and effort in writing valuable documentation is the focus at the moment and that's an often overlooked process in software development.

[Peter S]

This sounds like a great idea. On a bit of a tangent, something else
that I think would be useful is to have an extensions / techniques
gallery. People have posted some really cool extensions to ko on here,
but the nature of a basic forum like this means they get pushed off
the topic list pretty quick. It would be really useful to have a
permanent reference to see how people have solved problems, so
newcomers aren't having to reinvent the wheel.

[Jeff Sheldon]

That list grows and changes on a daily basis though, maybe if we had a Wiki that some of the more trusted community members could moderate.

[Steven Sanderson]

Hey

Thanks for all the feedback! Lots of good points raised - some of the commonalities I picked up:

* It's important to have a few end-to-end examples that show KO working with server-side technologies. Even though KO remains server-agnostic, just showing a few patterns for sending and receiving JSON data would help people getting started.

* The recipes/patterns are a popular idea (thanks Andrew for your ideas!). Like Jeff suggests (and like Peter S is asking for), a wiki is probably the best format for this. Can anyone recommend a good wiki service (something I/we can just sign up for and don't need to host myself)?

* There are differing opinions about whether to think of KO as a flexible toolkit or as an all-encompassing platform. I think time will tell which direction the evolution goes (my personal interest is more on the flexible toolkit end, BTW). 

* There should be a "wow cool" example (Scott & Roy mention "blog in 15 minutes"). I totally agree and have some ideas for a 15-minute-type example that would show off KO pretty well.

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!

Regards

Steve

[Jeff Sheldon]

I investigated the hosted Wiki topic not too long ago, I still had some bookmarks of what I found so I'll go ahead and share them.

An old SO topic about it.
http://stackoverflow.com/questions/143321/best-hosted-wiki-solution-for-private-wikis


A site dedicated to finding wiki's (Surprisingly enough)
http://www.wikimatrix.org/


And I believe these were the (so far) top 5 wiki's I had settled on.  (In no particular order)
http://cospire.com/
https://plans.pbworks.com/academic/
http://www.intodit.com/
http://www.netcipia.com/xwiki/bin/view/Main/WebHome
http://www.wikihost.org/


I have zero actual experience using any of these, I was simply looking them up for a different endeavor, and bookmarked them for future use.  But I haven't had the chance to actually try any of them out.  I ended up hosting my own. :)

[Mark Bradley]

There is also the github wiki if you enable it on the repository.

--
-barkmadley
sent from an internet enabled device

[Roy Jacobs]

This is probably the best way to go. Sure, it won't match the style of the knockout pages, but the Github wiki seems the most convenient.

[Stacey Thornton]

That is a bit difficult to elaborate as the fact that I do not
understand makes it hard to state why I don't get it.But I'll do my
best.

One of the big problems for me is that you do break apart a
demonstration showing how to use the bindings, but that's where it
stops - breaking it apart. It actually isn't very intuitive how to
bring it all together. Even in the last part of the page, It's a
little bit confusing how to make the given example run start to finish
and actually function.

The scope of valueAccessor() is confusing. The purpose of it, rather.
It wasn't until I read RPN's blog on
http://www.knockmeout.net/2011/05/dragging-dropping-and-sorting-with.html
that I was able to grasp what was really going on.
The purpose of the viewModel object is misleading a bit, as from the
get-go with knockout's documentation, we're naming practically
everything 'viewModel' - so is this the name of the parameter, or are
we supposed to substitute the specific viewModel object somewhere?

You have the line "<input data-bind="hasFocus: editingName" />", which
tells me "okay, this must be where it binds to whatever I declared.
But where is it declaring the parameters that were expected?"

Your first example gives 4 parameters, your second only two
parameters. This leaves it even more confusing. On top of the
declarations having different parameters, the implementations still
look the same, so it continues to leave the reader unclear as to what
is actually going on and what is being passed through these methods.

[Mark Bradley]

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).

Javascript functions don't technically have an arity (number of
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!
>>
>> Regards
>> Steve

--

[Enis Pilavdzic]

There is a really good book called javascript: the good parts, that
helped me a lot get up to speed with javascript enough to learn
knockout.

Definately I agree knockout docs assume you are more than a casual js
programmer.

Hope that helps,
Enis

Sent from my iPhone

[Jeff Sheldon]

Well sure, if you want to do it the easy way.  :)

I completely forgot about github's wiki.

[Andrew Goodnough]

I think the github wiki's the best idea, too.  As long as Steve doesn't mind sorting through pull requests for updating it or possibly delegating the documentation maintenance to someone else.

Andy

[Steven Sanderson]

Excellent ideas - the GitHub wiki does sound ideal assuming it can be
edited online (without a pull/push cycle) and allows for multiple
contributors. I'm out on vacation at the moment, so next week I'll
look into setting this up, and hopefully you can all contribute a bit
of your expertise to building up a repository of techniques and
reusable code snippets!

Thanks
Steve