Hacker News Reader

Comment by jessedhillon | Hacker News Reader

> Using the same language at both the client and server end has some serious benefits.

What are these benefits? Are they really exclusive to Node? (or if not exclusive, then vastly simpler with Node)

Here's a case study: an open source project I made with node.js; https://github.com/node-bus/node-bus

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.

The Google Web Toolkit (GWT) is a widely used Java-to-JavaScript compiler:

http://code.google.com/webtoolkit/

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.

have a look at dnode: https://github.com/substack/dnode bidirectional remote method invocation. Oh, and a complimentary robot free of charge: http://substack.net/browse/2010-11-08%2022:16:39 :-)

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.

That's cool! I was doing something like that at KnowNow in 2000 and 2001 (eventually open-sourced as mod_pubsub), but it never took off.

I agree that JS-on-server is a nicer way to share code than compiling other languages into JS.

Off the top of my head benefits:

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

> Seems like you write a few little functions...

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.

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.

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.

Reply on news.ycombinator.com