Less context switching probably means two things:

* Mental context switch between server/client languages.

* Better code reuse, i.e. the same model class can be used on the server and client side.

Those things you're talking about are just protocols: storage protocol, transfer protocol, etc.

> * Mental context switch between server/client languages.

Not sure I follow. The client-side Javascript you write will probably interact with the DOM API. The server-side Javascript will probably interact with the filesystem of the server, it is BYOD (Bring Your Own DOM). Plus, no matter what, you will always have that switch between client/server because that switch is what defines client/server.

> * Better code reuse, i.e. the same model class can be used on the server and client side.

Does anyone actually do this? True, it is the same language, but it is not the same environment.

> ...it is the same language, but it is not the same environment.

It is for me. I'm building a framework and enterprise app that just targets V8 (Node server, Chrome client). It's very liberating, to say the least. I still use Firefox (Firebug) for experimental stuff though, as Chrome's dev tools aren't up to par yet.

I'm surprised to hear WebKit's DOM Inspector being compared unfavorably to Firebug. What's missing?

At least when I last used it, the error reporting was lacking. Errors'd hang the page and wouldn't give accurate messages/line numbers.

Sharing models makes doing some form validations MUCH easier. My template language also runs on both server and client making progressive enhancement pretty trivial (in terms of updating dom elements when models change)

As for context-switch on server/client... if you use something like underscore on both ends, lots of things end up looking the same.

I think that the example you give is actually a very good example of a set of context switches that people regularly deal with poorly, even though they are, as you note, very common.

How many server side web developers do you know who can output standards compliant HTML/XHTML that also works on IE6? (In fact, I suppose this is one major reason why templating is so common---so you can separate the web development experts from the web design experts.) How many web developers will have a database enforce their integrity constraints rather than having the logic in their program? How many know how to write PL/SQL? How many compilers are there now from some source language down to JavaScript in order to reduce the number of languages that a developer needs to know and control interactions between?

The danger of these sorts of context switches seems to be difficult project coordination, code redundancy, performance bugs, and logic errors.

(On a side note, it's not that I think that developers are stupid, it's that writing code well in a given language seems to require not just familiarity with that often idiosyncratic language, but it also requires continued knowledge of standard idioms, libraries, frameworks, and sources of answers to common problems.)

> Isn't there something more exciting you can do with node.js?

My goal for node is to push my apps client side. Once you go all the way client side, the server only needs to serve up the static application files so that I can have them application cached, to backup/distribute/contain the localStorage, and to act as a communication channel. Node has the potential to excel at the last two while remaining widely comprehensible since most developers can at least read javascript.

I don't see the need for a django or rails on the platform, but I don't have a problem with the current major efforts of a database abstraction layer or simple DSLs like sinatra.