Ruby, Let's Take a Break. I Want To Date Node For a While.

http://grantmuller.com/ruby-lets-take-a-break-i-wanna-date-node-js-for-a-while/

by gmuller • 14 years ago

16 29 14 years ago

davemo• 14 years ago

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• 14 years ago

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.

ootachi• 14 years ago

Er... you want expressiveness, so you ditch JavaScript and use Java?

crazygringo2• 14 years ago

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.

switz• 14 years ago

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• 14 years ago

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

gphil• 14 years ago

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.

bascule4• 14 years ago

BrowserQuest, which is written in Node, put their inventory tracking system client side. Brilliant!

http://www.raymondcamden.com/index.cfm/2012/3/28/How-I-cheat...

crazygringo2• 14 years ago

I haven't in a huge way, but I have definitely shared constants, utility functions, and some application logic that are used identically server-side and client-side.

It's probably not a HUGE boost in productivity, but it does feel really, really nice. And just knowing you can take your server-side data structures, trivially insert them into client-side scripts with JSON.stringify() or Ajax calls, and have the same helper libraries you use server-side be able to operate on them client-side, makes it so easy and flexible.

(I'm working on a project that uses IcedCoffeeScript both server-side and client-side, which lets us use the same async event-handling model on both sides as well -- another plus.)

AdrianRossouw3• 14 years ago

Yes, we built [1]tilemill and [2]mapbox hosting using this technique. It's pretty awesome when it works, but can be quite tricky in other ways.

The first is a hybrid desktop/web application to design maps using a CSS like descriptor language. The desktop app downloads actually bundle a local node server in an os specific wrapper, with a web view. The application works just as well hosted and accessed by multiple user.

The latter is a cloud service that allows you to host rendered map layers and remix/share them. Foursquare recently switched to using mapbox for all their browser based maps.

I'd estimate at least 90% of the code is shared between the server and the client, with the server side generally only differing when you need to access resources not available to the client (databases, files on the server etc). The user interfaces can be rendered on either the client or the server (w/ jsdom) as needed.

[1] mapbox.com/tilemill [2] mapbox.com/hosting

lowglow• 14 years ago

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.

gmuller2• 14 years ago

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.

bascule4• 14 years ago

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• 14 years ago

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.

gmuller2• 14 years ago

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.

StavrosK6• 14 years ago

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?

bascule4• 14 years ago

> 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

StavrosK6• 14 years ago

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

michaelfairley• 14 years ago

There are also threads, which are typically much easier to program for than an asynchronous system, but will still let you have more than 1 request per process.

StavrosK6• 14 years ago

I don't know, it seems that greenlets are basically exactly as easy to program with as threads, from a quick skim of the docs.

mikeryan• 14 years ago

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.

AdrianRossouw3• 14 years ago

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

Ruby, Let's Take a Break. I Want To Date Node For a While.

Related Stories