Live data from Hacker News

To boldly go where Node man has gone before

blog.jgc.org

11–20 of 124 posts

Re: To boldly go where Node man has gone before

#11

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…

Go has a growing number of packages for things that you might want to interface with: http://go-lang.cat-v.org/pure-go-libs and http://golang.org/pkg/ There are already packages for most databases, data interchange formats, crypto, etc. that most people want to use.

Another draw of Go that you didn't mention is the language and toolchain design itself. I know Javascript better than Go, but would rather write servers in Go than JS.

Re: To boldly go where Node man has gone before

#12
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?

I don't program in Node very much or in Go at all, but I think there are reasons to use Node that aren't "Node is fast". I think the "Node is fast" mantra was originally really meant as a comparison to Ruby/Python/PHP, not as a comparison to lower-level languages like Go. (I personally wish Node would just abandon speed as a selling point altogether--I think it'd lead to many fewer misunderstandings.)

In any case:

Node lets you reuse the same code on both the client and server. This can be very valuable if you're writing a JS-heavy webapp. In my experience, the most useful bits of code are the in-code data representation (models in an MVC world). Being able to have identical functionality client- and server-side can save a lot of time.

Node also has Socket.IO, which is very useful if you want to use websockets. (Go has a library for it, but it hasn't been updated in a long time.) The vast majority of the Node ecosystem revolves mostly around building interaction- and communication-heavy webapps. I don't know Go or its community at all, but I don't believe they have the same kind of single-minded focus that Node has. If you're trying to do the things Node does well, you will likely benefit from the community support.

There are, of course, many downsides to Node as well, but much as I dislike Javascript, I still think it's one of the best choices for writing highly interactive webapps right now.

Re: To boldly go where Node man has gone before

#13
post #8
post #6

I'm sure the reason why users pick node is probably similar reasons why one picks ruby/python -- it's not for the speed. The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. I seriously doubt people would pick Go over node because of a micro-benchmark.

> The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. Do people really get that much code re-use between client and server that using Javascript on the server provides a large benefit?

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

Re: To boldly go where Node man has gone before

#14
post #9
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?

> So does Go's net/http module really provide basically exactly the same programming model as Node? If so, why use Node? Well, for starters, Go is much more awkward for working with JSON than JS is (which is to be expected since JSON is literally a subset of JavaScript). More importantly, Go lacks the ridiculously vibrant ecosystem for Web development that Node has — no NPM, no Connect, no Jade, no Stylus, etc.

'npm' is covered by the Go tools themselves. You can import packages using their github/bitbucket/code.google.com URL.

Re: To boldly go where Node man has gone before

#15
post #9

Earlier quoted context omitted.

> So does Go's net/http module really provide basically exactly the same programming model as Node? If so, why use Node? Well, for starters, Go is much more awkward for working with JSON than JS is (which is to be expected since JSON is literally a subset of JavaScript). More importantly, Go lacks the ridiculously vibrant ecosystem for Web development that Node has — no NPM, no Connect, no Jade, no Stylus, etc.

'npm' is covered by the Go tools themselves. You can import packages using their github/bitbucket/code.google.com URL.

That is really interesting. Thanks for pointing that out. Can you specify specific version dependencies like you do with a full-blown package manager?

Re: To boldly go where Node man has gone before

#17

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…

As we are commenting here, the community is assembling by the minute... Go allows you to import "github.com/user/package" and will download and compile the code, so creating a new project is even easier than with node, no need to "npm install ..." first. For a taste of what's out there, see: http://go.pkgdoc.org/index .

The GitHub thing was neat the first time I saw it, but then I thought about it some more, and I'm not sure it's such a good idea.

I couldn't find any way to specify a specific tag or revision, so it's basically always getting the bleeding edge developer build of the library code. That might be nice in some situations, but for getting work done I almost always want the most recent stable release.

Am I missing something?

Re: To boldly go where Node man has gone before

#18
post #13
post #8

Earlier quoted context omitted.

> The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. Do people really get that much code re-use between client and server that using Javascript on the server provides a large benefit?

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

Just not my experience that this is the case. Though I might be old-fashioned.

Re: To boldly go where Node man has gone before

#19
post #8
post #6

I'm sure the reason why users pick node is probably similar reasons why one picks ruby/python -- it's not for the speed. The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. I seriously doubt people would pick Go over node because of a micro-benchmark.

> The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. Do people really get that much code re-use between client and server that using Javascript on the server provides a large benefit?

For small apps, no.

For complex ones yes. The actual code shared may not be that much, but consider the advantages in sharing validation code between the client and server -- you never accidentally forget one requirement on the server side, leaving you vulnerable to an attack.

Re: To boldly go where Node man has gone before

#20

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…

As we are commenting here, the community is assembling by the minute... Go allows you to import "github.com/user/package" and will download and compile the code, so creating a new project is even easier than with node, no need to "npm install ..." first. For a taste of what's out there, see: http://go.pkgdoc.org/index .

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