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

Re: To boldly go where Node man has gone before

#21

Post by vito » Wed, May 16, 2012, 7:21 PM UTC

jlarocco wrote: post #17

paufernandez wrote: post #10

Earlier quoted context omitted.

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 somethin…

I hit this a while ago. The first thing I tried to install failed, because it depended on something that depended on something that moved its repository location (renamed itself from foo.go to foo).

It's a convenient hack but nothing more.

Re: To boldly go where Node man has gone before

#22

Post by tomjen3 » Wed, May 16, 2012, 7:21 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…

The amount of traffic has nothing to do with it.

A crud app would properly share relatively little code between the server and the client. A multiplayer game would share much, much more.

Re: To boldly go where Node man has gone before

#23

Post by jsprinkles » Wed, May 16, 2012, 7:21 PM UTC

tomjen3 wrote: post #19

kbd wrote: 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?

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.

Alternatively, there's an argument that one should not validate on the client to avoid this exact scenario (split-brain validation).

Re: To boldly go where Node man has gone before

#24

Post by jay_kyburz » Wed, May 16, 2012, 7:21 PM UTC

samdk wrote: post #12

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?

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: No…

Yeah, I agree, I'm using node right now to build a big web game and there are huge benefits to being able to run the same code on the sever and client.

I wouldn't use node if it wasn't for this because I don't particularly like javascript.

All my other games have used Python on the back end and you can really feel how clunky and painful javascript is when you have to switch between the two five times a day.

Re: To boldly go where Node man has gone before

#25

Post by KaoruAoiShiho » Wed, May 16, 2012, 7:22 PM UTC

kbd wrote: post #8

veemjeem wrote: 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?

Check out stuff like meteor or firebase. They barely even differentiate btwn client and server code.

Rolling your own framework based on the same ideas is not hard.

Re: To boldly go where Node man has gone before

#26

Post by phoboslab » Wed, May 16, 2012, 7:25 PM UTC

kbd wrote: post #8

veemjeem wrote: 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?

I'm currently working on the next major version of my JavaScript game engine[1]. The main new feature will be real time multiplayer. Being able to run the same game code server and client side is invaluable.

[1] http://impactjs.com/

Re: To boldly go where Node man has gone before

#27

Post by jsprinkles » Wed, May 16, 2012, 7:25 PM UTC

tomjen3 wrote: post #22

jsprinkles wrote: post #18

Earlier quoted context omitted.

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…

The amount of traffic has nothing to do with it. A crud app would properly share relatively little code between the server and the client. A multiplayer game would share much, much more.

And which do you think is more prevalent in the world, a CRUD app or a multiplayer game?

Re: To boldly go where Node man has gone before

#28

Post by christkv » Wed, May 16, 2012, 7:27 PM UTC

you know what both platforms are great, I'll use them both thank you.

Re: To boldly go where Node man has gone before

#29

Post by bdr » Wed, May 16, 2012, 7:27 PM UTC

The point of Node is that it uses JavaScript, and browsers only speak JavaScript. You have three choices: (1) use Node, (2) duplicate code client- and server-side, or (3) use server-side code that compiles to JS. Right now 3 is the least popular (and 2 is the most) but I think it will end up being the accepted solution in a couple years.

Re: To boldly go where Node man has gone before

#30

Post by paufernandez » Wed, May 16, 2012, 7:27 PM UTC

jlarocco wrote: post #17

paufernandez wrote: post #10

Earlier quoted context omitted.

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 somethin…

If I wanted a specific tag or release, I would just download that revision in the GOPATH directories, and refer to the package directly, instead of through the github URL.