Tell HN: Why node will win, and why you need to use it.

In my job as a freelance consultant, I get to review about four or five web applications in a month. Most of them are written in Java, Python, .Net or less often Ruby. I have been doing this for a few years now, and I have seen different types of challenges faced by teams while building these applications. What made me write this post is that these challenges are slowly changing in a way that most programming languages aren't equipped to handle. Well, none. Except Javascript. When Django or Rails were conceived, the web was less demanding. AJAX was simpler and expectations were low; if the user performs some action on the page, do a POST and refresh the relevant section of the page. Today though, an increasing number of applications have more demanding interactivity requirements. Here are some common examples. 1. Interactions which do not require connecting to the server. Such as adding new entries to a list. The transformation of the view as a result of the user action needs to be done in the browser itself. 2. Many applications now hold contextual data in browser memory; and it may not be possible to refresh a section of the page without this data. As a result, some of the logic to render the page needs to be on the client side. This is where problems begin. Sizable applications start having rendering logic written in (say) a Python/Django template for the initial state of the page, and rendering logic written in JavaScript for all the client-side interactions that happen subsequently. After doing this for a while, we begin to realize that we should just get rid of the server side templates and handle rendering on the client. We could send JSON to the browser, and JavaScript handles the rendering. This may seem like an acceptable result, since we aren't duplicating any rendering code on the server and client. And the responsibilities are well divided too; server side code fetches data and client side code renders it. Well, not so fast. Not all pages should be rendered client side. Some pages need to be indexed by search engines, and they need to be rendered on the server. Stuck. With a non-JavaScript framework, duplication of code is inevitable. A problem that will only worsen as the browser capabilities evolve to handle even more tasks currently executed on the server. People raise some valid concerns about Node.js, such as scalability. But those aren't insurmountable, and people are working on them as you read this. Besides, if your application got to a point where those problems begin to bother you, it would be pretty easy to hire the expertise to sort them out. Some people complain about the language itself. Those are mostly little personal preferences. Most dynamic languages are have always been more or less equivalent. All of them have basic things that matter; classes, closures, lambdas. And if you know one, you can pick up another quite easily. I didn't really get it a few years back when many people started talking about Javascript on the server. It was only after writing a few thousand lines of code with Node that I began to realize that this is a very fundamental shift. It wasn't about Javascript the language at all. It was about Javascript the platform. Write Once, Run Anywhere. Javascript is the language of the web. You should evaluate it for your start up.