Performance aside, being able to write both client and server code in the same language has a lot of advantages. After seeing how well the NodeChat worked at twich.me, I am definitely interested in trying it out. I think building a real-time networked game entirely in JS would be kinda fun.
>being able to write both client and server code in the same language has a lot of advantages.
Instead of html + css + sql + js + (python, ruby, [FotM]) its just html + css + sql + js? I would not be surprised to see html + css + sql + js (dom manipulation) + js (server side). The only benefit I see is that one could re-use their input validation.
Are there any examples of this in the wild? I have heard many claim that using JS on both sides is a big win, but have yet to come across anyone actually doing it (genuine question, it is something I would like to take notes from).
I use it on both sides (client and server). There's some code sharing between server and client side, but it's not a huge productivity boost that one should switch to a language they may not be comfortable with on the server side.
Organizing your code into smaller modules is probably more important in Node.js than most other frameworks if you want to keep your sanity. Otherwise you'll end up with crazy arrow code due to all the callbacks.
The speed that you gain from sharing the same language, you lose in the inability to write shorter code (Python/Ruby) and debugging callbacks. I think it's good to be language agnostic and have some sort of http rpc interface system to communicate between the languages.
I have some experience with sharing js libraries between server side and client side. It can be nice but comes at a price:
you'll bring all the problems of client side javascript to the serverside without any of the nice client side js-frameworks that makes cross-browser coding more sane.
We're using rhino serverside with the latest CSV version giving us full ECMAScript 5 compatibility on the serverside - but for the parts that are also used clientside we can forget about all the nice features of Rhino. For our clientside code we're using jQuery, but again, when sharing with the server we can forget about all of jQuery's utility methods and so on...
It's worth doing but it is not at all as smooth as it could be...
I'm using Rhino + jQuery + env.js + Postgres for processing html and it works great. None of the code will ever need to run on the client so being in total control of the environment is liberating.
Oddly, jslint.js is just fine on either end of the spectrum, but probably isn't intended for your end-user.
