

Ruby, Let's Take a Break. I Want To Date Node For a While. - gmuller
http://grantmuller.com/ruby-lets-take-a-break-i-wanna-date-node-js-for-a-while/

======
lowglow
The problem with the internet is that people now have the ability to affect a
larger amount of opinions than ever before, for better or worse.

I think node is cool, and definitely has its place. I think it's a bit
premature when people start talking about it being a full stack replacement. I
certainly believe under some circumstances node really shines, but you need to
pick your battles using the right tool for the right job. Stay educated and
understand why something works to solve a particular problem well.

~~~
gmuller
Whoa, who said anything about full stack replacement. I use a variety of
stacks, I was simply pointing out that since I'm using Javascript all over the
place anyway, I might start using it on the server side as well. Things I use
Ruby for generally amount to one-off jobs or shell-scripts. I constantly have
to remind myself of the syntax, since all I use all day long are variants of C
syntax(C#, java, javascript). It'll take me 10 minutes to whip up what would
take me 30 in ruby, simply because I don't use ruby often enough to
internalize the syntax. node provides me with a way to write the same shell
scripts in javascript.

------
bascule
I'm confused, what does this post have to do with Ruby, other than a brief
mention about how Ruby's syntax is different from other languages?

~~~
ramblerman
I'm confused about what it has to do with node.

project euler stuff is just javascript, might as well run it in the browser.

~~~
gmuller
That's true ramblerman, and actually I wrote some of this in the console
window of Chrome. The real point I was trying to prove (mostly to myself) is
that javascript can work as a server-side scripting platform to quickly create
short scripts. Node is simply my interpreter for it (and more). That actually
points out another bonus. I can POC something in javascript in a browser
window, and if I want to graduate it to a server side script its mostly a
copy-and-paste operation.

The post is mostly about convenience. I use javascript all the time. Now I can
use it more. I love ruby, I just end up having to relearn it every time I use
it because I don't use it often. Node is just the vehicle of that convenience.

------
switz
The ability to share models/code between the client side and server side is
magic at first. Javascript on every level with the data encoded in JSON? Yes,
please.

~~~
judofyr
I keep hearing about this, but has anyone actually done this?

~~~
gphil
And furthermore, what are the security ramifications of doing this?

At first glance, it seems attackers would be able to forge JSON objects
resulting in "mass-assignment" style vulnerabilities (unless there is lots of
protection logic) when sending JSON objects back to the server side.

However, going in the other direction (sending JSON from server to client) is
a very common pattern.

~~~
sespindola
This. Most tutorials of Backbone/Ember js apps I've seen have thin backends
that commit any json objects the clients send them.

Data sanitization and validation on the backend should be as thourough as that
of the client, if not more.

~~~
StavrosK
Who in their right mind does data validation on the client? However, there are
(very easy) ways to store data on the client and be sure they haven't been
tampered with. Just HMAC it along with a secret and check it next time.

~~~
tfb
My startup uses node to handle all database operations and essentially only
serves JSON via AJAX, while the most HTML it sends is basically <script
src="script.js"></script>. The entire app itself along with user-generated
content depends on a few large (highly variable) objects sent as JSON where
the DOM is manipulated based on this minified data.

As a bit of a backup measure (mainly to prevent XSS), the client-side
javascript sanitizes (which is what I believe you partly mean by data
validation) all objects sent to the client when as they receive it. So anyone
using the intended client-side script should never be susceptible to XSS.

But if by "data validation" you were referring to concepts like whether or not
a user has permission to access/modify some part of the database, of course
that is checked server-side.

~~~
StavrosK
The latter is more what I meant, yes. Basically, we all know you shouldn't
trust the client ever.

------
AdrianRossouw
i do node all day every day, but i've actually found it sub-optimal for shell
scripts / one-off jobs. For me these tend to take the form of import scripts
or batch files that have to process various different files and stick it in a
database. There's a lot of conceptual overhead that comes with asynchronous IO
for these kinds of tasks. However, some of the things that node allows you to
do is kind of spectacular too.

On a recent project I had to parse data from a set of csv files, while pre-
processing the data and pushing it into a Couch database. At the same time I
needed to generate a sqlite database with spatially aware geographic indexes
using parts of the data, so we could build maps from the data. I ended up
having a situation where the data was streaming into the couch database waaaay
faster than the sqlite db could write the records, which resulted in the
process growing in memory bogging the entire application down (the csv files
could be uploaded via a form as well).

The solution ended up being that because my csv parser was building on the
stream classes in node, i could literally pause/resume the stream based on the
state of the buffer(s). This is exactly the same technique you would use when
building an http proxy or limiting the transfer rate of file uploads. This is
some pretty low level stuff to have to get into for a simple import script,
and if I were to do it in something other than JS I would probably have used
temporary files or separate processes or whatever. Debugging and testing this
kind of problem is not really straightforward either.

As always YMMV, but I have become more appreciative of plain bash scripting as
of late.

edit: formatting

------
davemo
A friend who is wrapping up the last year of his computer science education
asked me last night "so what's this node.js stuff all about?". I thought about
it for a few seconds and then told him the value of writing a web-app in node
was the ability to use 1 language from top to bottom.

In my experience, most of the detractors of node seem to miss the value that a
homogenous programming environment can bring. I'm interested to see how your
courtship with node pans out over the long term; good post :)

~~~
andrewvc
I've used node, and I just don't see it.

You can share fragments of code, but for reasons of both security and logic
not much more. In my view, the evented nature of node negates most of the
pluses of one language.

Additionally, javascript is a shitty language if what you want is a large
amount of business logic. Python and ruby are much more concise and
expressive. This is a huge win that a lot of people overlook.

Now, if you need to throw together a chat service or push service really
quickly, I see the value, but that's about it. Of course for that, I'd just
use clojure or java.

~~~
crazygringo
I suggest trying CoffeeScript with node for more conciseness and expressivity,
and one of the async helpers to mitigate the complexity of the "evented nature
of node" -- letting you avoid huge nested callbacks.

These two things together completely transform Node, so much that I can't even
imagine coding without them.

------
mikeryan
The strange thing about this is that I've found that both make great additions
to my toolbox, and when making my language choice I don't pick JS or Ruby so
much as I pick Node or Rails/Sinatra and I don't do the same things with each
stack.

I've long gotten past worrying too much about languages Ruby and JS are so
close to each other that switching between the two is a frictionless process.

------
StavrosK
I don't know, I want to make an HTTP spider and I don't want to have one
process per request, so the obvious thing was to use something asynchronous.
Still, Python+gevent sounds better than node, so I don't see the advantages of
using Javascript for that.

What does it get me over Python+gevent, which has a more natural asynchronous
programming syntax?

~~~
bascule
> I don't want to have one process per request, so the obvious thing was to
> use something asynchronous

There's these amazing things called threads you can use too

~~~
StavrosK
Why would I do that when 99% of the time is spent waiting on the http call to
return?

~~~
bascule
Because unless you have an unusually high (>1000) concurrency level for your
HTTP connections, threads are a more than adequate solution to the problem.

