To boldly go where Node man has gone before • Hacker News Board

Re: To boldly go where Node man has gone before

#51

Post by zzaman » Wed, May 16, 2012, 8:31 PM UTC

hack_edu wrote: post #46

xxbondsxx wrote: post #7

Choosing Node.JS isn't just a performance / scaling decision for me -- one of the main draws to Node is the huge community and wealth of awesome modules. Socket.io, Now.js, cradle, redis, and dozens of other modules abstract away the tedious work and let me build functionality _really_ fast. Go is really promising but it won't win over the majority of casual developers until there's a community around it. I might as…

> one of the main draws to Node is the huge community and wealth of awesome modules. Socket.io, Now.js, cradle, redis Really? In my experience, all but the most mature modules are hardly beta-quality and in constant flux. Find a good module for your job? Too bad it only runs on 0.4. Find another to get around that; oops, too bad your version of gcc needs to be patched and re-built. The language and its entire package…

In my 6ish months of programming in Nodejs full-time, I have yet to run into a library that only runs on 0.4 only or requires my version of gcc to be patched and re-built. Which Node libraries were you trying to use?

Re: To boldly go where Node man has gone before

#52

Post by rodw » Wed, May 16, 2012, 8:40 PM UTC

jsprinkles wrote: post #18

Raynos wrote: post #13

Earlier quoted context omitted.

In a medium sized web application, 50-70% of server-side code can be re-used verbatim between server and client.

Well, whatever "medium sized" means, I work on a high-traffic Web application that reuses 0% of code from the client; in almost everything I've worked on, I've found reuse between client and server nearly impossible, enough that they're almost always segregated repositories. There's an argument for models existing on both sides (which is reiterated below), but I have a hard time seeing models as 50-70% of any applica…

For what it's worth, here's one counter-example:

I've recently been working with a team that is developing a content management system for which the display side of things (responsible for routing requests to models and views, fetching model content, rendering, etc.) is about 500 lines of non-comment CoffeeScript code.

Nearly 100% of the server-side code is re-used on the client, and perhaps 80% of the (non-library) client-side code is shared with the server.

In this case the exceptions are:

- Things like HTTP-level request handling and reading from local files rather than over HTTP are used on the server-side only.

- Things like DOM-manipulation and interacting with browser events are used on the client-side only.

I wonder if a significant factor may be how much functionality you're actually replicating on both the client and server. In our case, browser-permitting, the entire display engine runs equally well on the client or on the server. If we had a lot of JQuery kind of stuff happening in the client-side JavaScript the ratios might be a little different, but "also-run-the-app-on-the-client" is a good example of a use case that leads to a lot of reuse of the server side code.

Re: To boldly go where Node man has gone before

#53

Post by jff » Wed, May 16, 2012, 8:44 PM UTC

kbd wrote: post #2

So does Go's net/http module really provide basically exactly the same programming model as Node? If so, why use Node? One thing the author didn't mention is that Go will use multiple cores in this example, whereas Node is single-threaded. Right?

Writing http servers with Go really is pretty easy; here's one I wrote while at SC11: https://bitbucket.org/floren/goblog

It's for an older version of Go, and has only been tested on Plan 9, but it shows a static content + blog server, with JSON config files and templated HTML for the blog pages.

Re: To boldly go where Node man has gone before

#54

Post by KaoruAoiShiho » Wed, May 16, 2012, 8:51 PM UTC

paufernandez wrote: post #34

KaoruAoiShiho wrote: post #20

Earlier quoted context omitted.

npm is awesome, this direct import doesn't seem like a feature, more like a lack of a feature.

It works very well for me. If I want someone to install a Go program I've developed, in Ubuntu 12.04 they can just: $ sudo apt-get install golang $ go get github.com/pauek/garzon/grz That's it, and it takes a few seconds.

How's that any faster than

  npm install express

Not only do npm handle versioning for you, you also don't have to remember the host or username. Obviously Go is a younger community, and could make a package manager some day, but I'm puzzled by how you're comparing this positively with npm.

Re: To boldly go where Node man has gone before

#55

Post by KaoruAoiShiho » Wed, May 16, 2012, 8:52 PM UTC

paufernandez wrote: post #34

KaoruAoiShiho wrote: post #20

Earlier quoted context omitted.

npm is awesome, this direct import doesn't seem like a feature, more like a lack of a feature.

It works very well for me. If I want someone to install a Go program I've developed, in Ubuntu 12.04 they can just: $ sudo apt-get install golang $ go get github.com/pauek/garzon/grz That's it, and it takes a few seconds.

Oh I get it, you're talking about from a package developer's standpoint. Not having to register your package with a central directory does save a bit of time for you I guess.

But when installing packages, I have to say, npm is fantastic.

Re: To boldly go where Node man has gone before

#56

Post by vectorpush » Wed, May 16, 2012, 8:54 PM UTC

jsprinkles wrote: post #33

sim0n wrote: post #31

Earlier quoted context omitted.

Why not validate on both? Validate on the client to give a nicer and quicker notice if something is wrong (good UX) and then validate on the server for actual security.

To avoid a split-brain validation scenario. Update your model? Don't forget to update your validation in both the client and server. Otherwise, you'll validate something on the client but not the server (bad UX), invalidate something on the client but not the server (bad UX), or corrupt your data slowly when validation entirely fails (bad UX). Since it's a pain in the ass to remember to update two places when you mak…

Proper unit testing makes split-brain validation a non-issue. Client-side validation does feel more responsive, it also saves bandwidth, and prevents impatient users from spamming the server with invalid requests.

Re: To boldly go where Node man has gone before

#57

Post by david_k » Wed, May 16, 2012, 8:58 PM UTC

I can personally vouch for the maturity of Node especially Socket.io. We're building a web-based email client that relies heavily on real-time communication with a Node-based email importer. See http://philterit.com. I've found Node to be faster and more lightweight than Rails 3, which we initially used for our prototype. With JavaScript being the lingua franca on the client-side, specializing in it as a team has permitted us to master it and offer a far better user experience.

Re: To boldly go where Node man has gone before

#58

Post by moocow01 » Wed, May 16, 2012, 9:02 PM UTC

If there is one thing I've learned its to ignore benchmark tests on relatively established technologies.

You'll drive yourself into the looney bin if you hop from one thing to the next based on these comparisons that inevitably popup every month or so.

If you enjoy programming in JS with Node use it - if you enjoy programming with Go use it. Your enjoyment will far outweigh performance differences that will be minor in 99% of real world cases.

Re: To boldly go where Node man has gone before

#59

Post by IsaacSchlueter » Wed, May 16, 2012, 9:08 PM UTC

moocow01 wrote: post #58

If there is one thing I've learned its to ignore benchmark tests on relatively established technologies. You'll drive yourself into the looney bin if you hop from one thing to the next based on these comparisons that inevitably popup every month or so. If you enjoy programming in JS with Node use it - if you enjoy programming with Go use it. Your enjoyment will far outweigh performance differences that will be minor…

Yes, exactly.

Re: To boldly go where Node man has gone before

#60

Post by arturadib » Wed, May 16, 2012, 9:18 PM UTC

Node is popular not only because it's very fast (yes, it's still pretty darn fast even if there might exist faster alternatives), but because it's JavaScript.

That's an enormous advantage for startups as (a) the JavaScript hiring pool is much larger than most other languages (particularly in comparison to nascent ones, like Go), and (b) the ability to write client- and server-side code in the same language means small teams can be far more integrated and collaborative than otherwise (and if the startup has a single coder, the point is even stronger).

Assuming these benchmarks are accurate and translate into similar results for more complex applications, I'd gladly pay the 10-20% performance penalty to get the above benefits. Node is fast enough for most startups.