Why?
Server-side javascript has been a hot topic for awhile now, especially since node.js was announced. But after reading about it here and there, a big part that I felt I was missing was the “why”.
I mean, for those of us who really enjoy javascript (which I do), enough said. Javascript on the server? Hell yes!
I realize, though, that most of the world doesn’t share my love of this particular programming language. 
So, while at jsconf this past weekend, I tried to collect some reasons why everyone should consider javascript on the server.
1. It lets you write things once instead of twice.
The more logic that you’re running on the client-side, the more code you have to write twice: once in your server-side language of choice, and once again in javascript. The classic example here is validation code. You want to validate on the client-side for a good user experience, but you have to validate on the server for security reasons. As a result, you have two whole different sets of validation rules to be written, updated, and maintained over time.
Now wouldn’t it be great if that could be just one piece of code? You’d cut your codebase in half, and make maintenance a lot easier.
2. It could make progressive enhancement easier.
Server-side javascript has the potential to make progressive enhancement a lot easier, by requiring you to do less special planning for it. With a hijax-type approach, which seems to be the current best practice for supporting non-scriptie users, you have to create your site first without javascript, and only then add all of the dynamic stuff in.
In a world of limited budgets and tight deadlines, this may seem like a lot of extra work to support a very small number of users. But with server-side javascript, there’s the potential that for those users, you could just run the javascript on the server-side instead and return the page in its new state.
I’ll be honest, this would probably be a pretty slow experience with a lot of extra page reloads, but it may still be better than the unusable state of many current sites with javascript turned off. (There was a fab talk at jsconf by Philly’s own Jenn Lukas on the sad state of no-script support on major sites.) At least this way people could get what they to wanted, even if the experience was slow.
This isn’t a topic I’ve heard discussed very much yet, but if there was a way to make progressive enhancement basically automatic, that could turn out to be a big win.
3. It lets you stay in one headspace.
Ok, this could be considered a weaker reason, which is why I put it third. But it’s well-known that switching between tasks harms productivity, and it’s much better to focus on just one thing at once. Now consider that many developers are generalists who do some server-side and some client-side code, and as a result have to hold (at least) two different languages in their heads, with two different sets of APIs and quirks and syntaxes and styles, switching between them all of the time.
I know that I personally try to use console.log in Objective-C, trace in a javascript file, or echo in a Flex app at least once a week. And that doesn’t even get to the subtler traps of forcing one language into another’s paradigm.
Now imagine that you could take a large portion of that brainspace and devote it to just one thing. One language, one syntax, one set of patterns, one set of common bugs. Wouldn’t it make you more efficient? Wouldn’t you get so awesome and productive and ninja-esque at that language?
Because.
I’m sure using js on the server has its downsides as well, but I don’t really know enough yet to speak to what they are. But I’m convinced now that it’s more than just a toy, and is worth at least a look from people who care about the good things above.
