Shouldn’t this be “visible: todoLists().length > 0″?

Durandal looks pretty interesting and potentially useful. Do you know what the name of the course you’re using it for on Pluralsight will be? That way I can keep a look out for it.

View composition is an important topic and you can try t load on demand using templating libraries or require.js (the text plugin). But before you solve that problem, just make sure it is an issue. I agree in larger apps with more screens and things flying around that it makes sense. But before I tweak performance, I always test to make sure its an issue first. Otherwise, YAGNI

I do recommend looking into Durandal.js. Its brand new and in pre-release, but I’m using it for my next course as it has a lot of upside and is built by the creators of Caliburn Micro.

Thanks for this post; really interesting.

I’m very keen on what I’ve seen on SPA’s but so far I’ve held off going fully down that route as I wasn’t sure whether I was happy about the implications for a very large application of having each “screen”s template loaded up when the app fires up for the first time. Also I wasn’t certain how to best facilitate individual edit screens within the context of a SPA. Inside some kind of modal dialog? If so which one? etc etc.

I’ve just started working my way through both your SPA course on Pluralsight and I’m hopeful I’ll find answers to some of these questions as I watch this (the later module titles certainly sound like they’ll be addressing some of these topics).

Before I sign off I wanted to say fine work on the TypeScript course – loved it!

I use HATEOAS whenever I can to avoid having to know what the URLs need to look like on the client. That means, for example, that in my representation of a list of Todos I would include, for each todo, only a minimal set of data needed to show in a list and a location of where the resource is of the individual Todo is located. The list and the individual item also wouldn’t be sharing the DTO (which I would name TodoResource). It’s a preference, and I’m sure I wouldn’t want to force this onto anyone who doesn’t like it.

But the second thing that I miss is the use of client side templates to avoid having to look at a flash of unbound HTML before knockout kicks in and hides all the irrelevant stuff. Now, when your page is being loaded and the initialization script is about to be executed we’ll be looking at all the unbound HTML that flashes before our eyes. Especially when you have a larger SPA with multiple views you’ll be seeing a lot of HTML being loaded and especially on slower connections/mobile browsers this might be irritating.

When the views themselves are put in a client side element, they’re not readily visible, nor even handled as DOM, until Knockout decides to put the relevant parts in DOM based on the view model.

Any chance on beta video sooner