NodeQuery is a realtime server-side DOM API

Are there examples of this paradigm for another framework or in another language?<p>We think of js as being of paramount importance in web development because it's the only way to interact with the DOM, so we've mostly come to terms with it and its flaws (which are manifold, even though I happen to think it's a nice language in lots of ways). But if we put all DOM manipulation on the server-side with a very thin client-side javascript communication and manipulation layer, this isn't necessary.<p>You could write your entire application in Ruby, Haskell, Forth, whatever floats your boat, against a standardized, cross-browser, and improved DOM.<p>This is powerful and intriguing.

Why would you want to add 100-500ms of latency to every single DOM manipulation? Realtime means I click on something and something else happens, immediately, not a 1/2 second later.<p>All this to just save having to load jQuery in the client? Not sure I get the advantage.

This appears to solve a major problem with web apps - exposing your entire front-end code to everyone. Very exciting.<p>Is it production ready? (Edit: Duh, says "beta")

can somebody provide a real-world example where you'd want to manipulate the DOM from the server?<p>I'm not sure I really see the benefit of this. Not to say it isn't cool, just wondering where it would be useful over client-side DOM.<p>My understanding of node is that the benefit is in the lack of thread locking, not specifically that it runs javascript.

Initial reaction: issuing server-side calls to manipulate client-side DOM is a gross violation of the principles of separation of logic/duties. Why is this desirable?

What is limiting this to be jQuery/Zepto specific? Is it possible to write a generic server-side remote control so that other libraries can be used?

Thank you for this. jsDom was the only other server side DOM implementation, and it's garbage (buggy).