I know both and I take Node seriously. Using the same language at both the client and server end has some serious benefits. And web servers are mostly shared-none, so not having first-class support for communication between Node processes is not that big of a deal. Node has its niche.
> Using the same language at both the client and server end has some serious benefits
Like what? I hear this argument all the time, but it's always unsubstantiated.
In my experience, the choice of language is less important than the programmer's understanding of facts that have little to do with the language itself.
If you are developing client-side browser code, for instance, then you have little choice but to use Javascript.
But learning JavaScript is not the hard part: mainstream programming languages, in and of themselves, are rarely difficult to master.
On the contrary, the skill that separates the superior engineers from the inferior ones is the mastery of the environment that the program operates in.
For front-end developers, it is an intricate understanding of how browsers work (i.e., the DOM and supported events) and some good understanding of how to optimize requests back to the server. (There is probably much more they know than this, but I'm not a front-end developer.)
Similarly, back-end developers have much to learn about how to efficiently and reliably serve (hopefully) many thousands of requests per second. They need to understand the limitations of their servers, how to manage memory and storage effectively, and build reliable, operable services.
For both types, these skills often take many years to master, and they are hardly interchangeable. Consider that developers themselves often describe themselves as "front-end" and "back-end" people. The fact that you can now use JavaScript on the server side does little to disturb this reality; and things wouldn't change much if you could run Perl or Python or Ruby in the browser tomorrow.
> Like what? I hear this argument all the time, but it's always unsubstantiated.
Have you ever done it? It's very comfortable. It reduces one element of friction in the daily thought-work of the programmer.
By the same token, a comfortable chair or nice text editor won't turn an amateur into an all-star programmer in the absence the other important stuff (smarts, work, etc.) It can be a huge waste of time to fret over your editor or your chair adjustments. But that's not going to make me less likely to sit in a nice ergonomic chair and use vim rather than notepad.
Comfort isn't everything, but it's certainly not nothing.
It's a distributed pub-sub engine, so one client can publish an event, and the others on the server will receive it. Probably about half the code is shared between the server and client. That means less bugs and easier maintenance.
Technically there are tools that will convert, say, Haskell to Javascript so that you can have shared code between a client and server. In practice, I don't know anyone who does that. I'm sure for most it feels like a bit of a hack. So for practical purposes, the only way to share code between the client and server is by using javascript (or coffeescript) on the server-side as well. Node.js IMO is the best server-side javascript engine.
I looked through your shared/util.js and, while I don't want to take anything away from your project, it doesn't seem to me that there is much of a case for significant and useful code sharing in Node. When I think of code sharing, I expect something like Luna, from Asana http://asana.com/luna/
Instead, the examples of shared code in Node are always simple utility functions, validators and the like. While it helps not to have to rewrite those, it's not groundbreaking. Facilitating the sharing of state between client and server -- hopefully irrespective of the server-side language -- would be a much better goal, IMO.
The code itself might not be significant, but the implications are. It defines standard interfaces for interacting with the library. Thus people can write plugins on top that work at both the client and server end.
-No mental context switch when working on both ends
-Easier serialization (though JSON is pretty portable...)
-Sharing code
They aren't exclusive to Node and JS, but browsers run JS and will continue to for the foreseeable future. Since the front end can't budge its language at the moment, the back end has to.
I see the "sharing code" claim a lot but I haven't really seen it substantiated. Seems like you write a few little functions but it's not like you sharing the same framework which would be the real benefit.
Seriously? A very common problem in web apps is validation logic is usually duplicated in JS and Server side language.
Node allows the same logic to be used in both cases. These are not a 'few little functions'. Validation is a central part of most business applications.
Given the potential to template html with javascript, and to code exclusively in javascript. You could end up with webapps written entirely in one language.
Whether that is a good thing or not remains to be seen, but it is something that we should pay attention to.
In my experience, most validation on the server is a superset of what's required on the client (or disjoint).
For example, validating a user's name on the client merely checks if the name's length is in a certain range and doesn't contain invalid characters. On the server it requires a query to the database -- possibly more.
I also reject the notion that there is a significant context switch involved in going from one language to the other.
Validation is not a central part of most biz applications. Validation on the client side is a UX convenience, but not strictly necessary because anyone with two brian cells to rub together is going to ignore any client side validation and run the real input validation on the server.
The functionality implemented is mutually exclusive
Sorry, but what is that supposed to mean?
The functionality on either end of a client/server application is usually not "mutually exclusive". They're two sides of the same coin and could indeed benefit tremendously from code sharing. Just because the potential has barely been realized so far doesn't mean it doesn't exist.
I'm working on a distributed app that shares code between the client and server, and there are already a multitude of open-source libraries that are designed to run in any JS environment.
Math (significant math), encoding and hashing being done on the client sounds like a poorly designed application. Same for templating on the server -- which I assume you mean manually compiling templates using a library, and sending the result to a client, perhaps as a property of a JSON object.
