Steve - I'm trying to work in time for reflection on so many levels - even problem solving at work. I saw a great video recently <a href="http:// (http://bit.ly/mOCZpW)" target="_blank"> <a href="http://(http://bit.ly/mOCZpW)" target="_blank">(http://bit.ly/mOCZpW) by the creator of a recent language called Clojure - in which he challenges his audience (of guys like me) "When was the last time spent an hour thinking about a problem? Or a day? Or week?" I've been making the habit at work to step away from the desk, go to whiteboard and *think* through things. It's really paid off. Now I hope that I can translate that to other areas of life! You give me too much credit on WWF. Clearly my prowess is only noticeable because of all the training that your defeats foisted upon me. :-)

Toby - my apologies for taking so long to respond to your comment (things have been a bit hectic schedule wise for me). I checked out your git repo and have a couple of thoughts. Sure, it's certainly possible to do things the way you are, but I believe you're making some assumptions and trade-offs that aren't worth the risk. First, if you were to build a Knockoutjs app like this, you now effectively have two entry points for templates - the manual route you're taking, plus what KO provides. KO is by no means the perfect framework, but the point of a framework is to provide a consistent abstraction over the problems it's attempting to solve. By handling templating outside KO core, you are forced to apply bindings each time you load a template. You've also ruled out the option for nested templates - unless you manually recurse them, and apply the bindings on each one. Ultimately, by then time you write the code to handle all these issues, you will have solved the same issue Steve Sanderson has already solved in context of working with templates inside KO. While I'm not crazy about the sync call to get an external template, it's a one-time hit per template, and you have the option to time it out - I consider those far less of a disadvantage as having to solve the same problems in my own code that KO already solves for me, and still lose the advantages that templates have working through a template engine that has been implemented for KO specifically (like the stock one, or the one I created, or any of the others out there). It's also a reasonable course of action to fork KO and submit a pull request with changes that allow for a callback to be invoked prior to retrieving a template, that takes a 'continuation callback' as an argument. I've voiced this frustration before - if that were possible, then a sync call wouldn't be necessary. As it stands, though, KO was written with the assumption that template retrieval would be synchronous. Anyway - I think it's good that you're exploring this, but I don't think I would go the route you're recommending. If you're going to work with a framework like KO, I would either fork and modify to extend it to do what I want it to do, or abandon it and roll my own (or go with another) - rather than code a large of part of a separate framework and run it along side one that already has the facilities to do what I've coded as well. Hopefully that makes sense! Thanks a ton for giving me your feedback and for visiting the blog...

Great questions - thanks for the response! When I left the 'comfy job' in 2008, we knew it was going to be tight for a bit financially. It put things on hold that we hated to delay. But I'm blessed with an understanding spouse who saw me dying a bit each day inside, and was ready for me to get into something more fulfilling. Who knew the new company would collapse 2 years later? But learned valuable skills from that - learning to balance between commitment to a job, and commitment to my career. I know any company is going have it's bad days (if not seasons!), so I try to not to jump to conclusions, but I'm not a blind loyalist either. That doesn't rule out the very real chance of working for another idiot, but it might lessen the damage (and limit the length of exposure). This is also a driving reason behind why I'm trying to be more involved in OSS. I read a bit of your thoughts on OSS and certainly understand your frustrations (I used to have a lot of the same ones!). But I'm finding that OSS involvement has sharpened my skills more than I had expected, and has exposed me to other developers that I've learned a ton from (as well as providing a relationship-network for the next time I'm looking for work). I agree about Nashville - tons of great talent there (I was sad to leave!). There are great companies (like Firefly), but they're not getting the name recognition they deserve, IMO.

Diego - thanks for the comment. I read through your blog entry. I can understand your points regarding mixing HTML and JS - but when it comes to binding, it's going to happen at some point. Even if you use templates with Backbone, you still have to write a render method. The main difference (and this is what I think drives the decision for what most devs are comfortable with) is declarative vs imperative binding. You also brought up an interesting point about how Knockout.js doesn't directly address the model. This is because it's entirely situational. The model is the most malleable and fluid piece in MVVM, since it's the domain model effectively. Some MVVM frameworks might provide a level of 'scaffolding' for models, but too much and it becomes too prescriptive, making the model less expressive. I think you're right in suggesting the KO could benefit from additional infrastructure for save/validate, etc. (I'm actually working on a validation framework to plug into it.) I've used amplify.js for request/communications in my KO apps thus far and have been very happy with it. I also agree that there's much less overhead in changing template engines for Backbone - hopefully as other developers write template engine plugins for KO, this will improve. I've actually written one for KO - http://www.ifandelse.com/?p=100. (still jQuery templates, but allowing for them to be loaded externally). Thanks for sharing the link to your site. I look forward to checking out more of the work you're doing there!

Thanks for the info - I will check it out!

Joel - thanks! I've been meaning to check out javascriptMVC as well but hadn't had time yet. I agree on KO having a much quicker learning curve. The main complaints I've heard leveled at KO are things like "It doesn't have a built in way to talk to a RESTful server" or "It doesn't have built in validation", etc. Those things really don't bother me, since there are js projects out there than can be adapted to KO without much pain. One of my friends at appendTo recently told me about amplify.js - a library they're working on to abstract request, storage and pub/sub functionality. Something like amplify has been a great fit in my own tests in coming up with a consistent & clean way to have my KO projects talk to servers and storage, etc. I'm also working on a rough idea for a validation framework that will plug into KO (it will be viewmodel driven, and notify any subscribers in the UI of the results). I mention all that to say that I love how easy KO is not only to learn, but to extend!

Ryan - thanks for the input. I *love* the idea of just adding a hook to KO core and passing a callback. I'm going to mull that over this weekend and try to get something submitted early this week. It's funny you mentioned the idea of adding an 'init' function - I started to go that route twice and stopped myself (and can't for the life of me remember why I stopped). I hear you on forcing the ajax call to be synchronous! It left a queasy feeling in my stomach - but I didn't see a way in the existing code base to handle it asynchronously (without significant forking). I think a great thing for all of us KO devs to consider long term would be re-factoring key pipelines to operate async - it would probably provide an easier way to extend the core via injected callbacks (like your idea above). Also - just wanted to say that when I first stumbled onto Knockout.js, I read through a lot of your discussion board posts, and some of your site and I've seen the commits you've made on github - GREAT work man!

Andrew - thanks so much for the comment! My preference would be to use templates to avoid any html-embedding if I were to move forward with a project using backbone. I purposefully made one of the render functions use concatenated html to reflect the frequency with which I saw other backbone examples take that approach. I definitely see your point in arguing that the Knockout approach is no better in separating the concerns, but I disagree primarily because most web developers are already used to, for example, hooking DOM events up to js handlers via element attributes - and this fits that paradigm closely. Another reason why it's less intrusive to me, admittedly, is that declarative bindings are the norm in WPF and Silverlight - and I spent a good amount of time in WPF at my last job. When you have views driven primarily by declarative code, attribute bindings seem to be a more natural fit (in that they are readable, and provide a concise way of saying "Hey - I'm hooking this view into your model *here*.") than sifting through the behavior of a imperative-based view to see what declarative elements get emitted (or are referenced, in the case of templates). Of course - that's just my opinion. :-) While I personally lean towards frameworks like Knockout, I'm impressed with what I've seen done with Backbone - and I agree, the auto-REST loading & saving (plus the history features) are strong points for Backbone.

I haven't tried using view engine templates yet - but I think that will make for a great post after I talk about the template engine plugin!

Agreed - I'm not a fan of emitting (or embedding) any more HTML into JS than is absolutely necessary. This is one of the reasons the declarative binding approach of KO is so compelling. It feels (and looks) cleaner & helps separate the concerns.