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

Re: To boldly go where Node man has gone before

#31

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

jsprinkles wrote: post #23

tomjen3 wrote: post #19

Earlier quoted context omitted.

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

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.

Re: To boldly go where Node man has gone before

#32

Post by vibrunazo » Wed, May 16, 2012, 7:32 PM UTC

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.

You can compile Go to js with gwt. You can reuse code that way. I personally even reuse Java code between Android, front end Web and server. Because of gwt.

I don't think there are many people who choose js because they like it. It's usually because they feel forced. Javascript is a terrible language, I always prefer one of the compilers.

Dart can't come fast enough.

Re: To boldly go where Node man has gone before

#33

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

sim0n wrote: post #31

jsprinkles wrote: post #23

Earlier quoted context omitted.

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

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 make a change, you're seeing people make ridiculous leaps of programming ingenuity by choosing a server-side language that allows them to not have to update two places at once, and Javascript absolutely sucks for server programming. Every time I have to do any client-side Javascript I, quite literally, hate my life. People that love Javascript and want to apply it to everything have arguments about the stupidest things, like using semicolons, which is telling about how awful of a programming environment it can be.

Easier: Just don't validate on the client, and make a round trip. If you're doing mobile or on a high-latency link, there's an argument for doing client-side validation but then you just need the discipline to update both sides at once, which hopefully integration tests should help with.

Re: To boldly go where Node man has gone before

#34

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

KaoruAoiShiho wrote: post #20

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 .

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.

Re: To boldly go where Node man has gone before

#35

Post by peterwwillis » Wed, May 16, 2012, 7:43 PM UTC

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…

Re: To boldly go where Node man has gone before

#36

Post by petercooper » Wed, May 16, 2012, 7:43 PM UTC

vibrunazo wrote: post #32

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.

You can compile Go to js with gwt. You can reuse code that way. I personally even reuse Java code between Android, front end Web and server. Because of gwt. I don't think there are many people who choose js because they like it. It's usually because they feel forced. Javascript is a terrible language, I always prefer one of the compilers. Dart can't come fast enough.

You can compile Go to js with gwt. You can reuse code that way.

This makes me wonder.. and this is totally off the cuff, non-researched pondering.. could there be merit to a JavaScript dialect that would compile to Go?

Re: To boldly go where Node man has gone before

#37

Post by mustafaakin » Wed, May 16, 2012, 7:46 PM UTC

The main problem is Go uses every core, while Node does not if you do not use clustering. And with clustering performance scales up linearly, try if you wish.

Re: To boldly go where Node man has gone before

#38

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

"medium" means I don't have personal experience of how the percentage scales to large applications.

as for sharing: data sources, domain models, utilities and templates can be shared. its the io handling (HTTP and dom) that can not be shared.

Re: To boldly go where Node man has gone before

#39

Post by ConstantineXVI » Wed, May 16, 2012, 7:57 PM UTC

paufernandez wrote: post #30

jlarocco wrote: post #17

Earlier quoted context omitted.

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.

Kind of a clunky way to handle versioning though. In Lein (for example), adding

    [noir "1.2.0"]

ensures I'm always grabbing the same version. In Go, appears the only way to guarantee this is to check in the full source of the library alongside your own in your repo.

Re: To boldly go where Node man has gone before

#40

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

chc wrote: post #15

paufernandez wrote: post #14

Earlier quoted context omitted.

'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?

I don't think so, but I could be mistaken. (btw, someone pointed that out as a drawback on another thread.)

What I've done sometimes is just clone the repo within a directory that appears in the GOPATH, maybe checkout a specific revision, and that solves the problem.