
Tell HN: Why node will win, and why you need to use it. - jeswin
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.<p>Well, none. Except Javascript.<p>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.<p>As a result, some of the logic to render the page needs to be on the client side.<p>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.<p>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.<p>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.<p>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.<p>Javascript is the language of the web. You should evaluate it for your start up.
======
kls
_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_

This is the only way to flatten the technology stack, anything else just
created a bigger ball of technical debt. The advantages of REST and JavaScript
applications over the old model are not apparent until you make this mental
leap. Once a person does the simplicity of the architecture becomes apparent.

 _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._

This is not a concern if you do a little browser sniffing, if you run into a
search bot, you send it to a server that has a headless web-browser script on
it, that pulls the content from the primary server, and delivers it to the bot
as a single unified page. Further most of the major search engines are fairly
far along in their ability to index client side dynamic content, some you have
to give a little help with #! and such, but for the most part, search is not a
valid reason to hang on to the legacy of server side views.

------
drcode
_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._

Why can't you just have the server serve up the raw data using a simple
(RESTful) interface, then place all your logic in the client?

The search engines can index the restful interface... All the rendering
intelligence can live in the client. If you do this, the server code doesn't
need to be javascript and hence doesn't need to be node.js.

The real evil, IMHO, is server-side html templating, which I think people will
move away from in a few years.

