
Why we are switching from Ruby/Sinatra to Node.js - duck
http://groups.google.com/group/urug/browse_thread/thread/519f1f0d570d88e0?pli=1
======
mhd
Oh my. I like node, but that's a bunch of weird arguments. Most of them
contain a kernel of truth, but jumping from that to node comes as some kind of
non sequitur.

1) Version hell: No up-to-date packages on Linux distributions? As compared to
the packages they have for a fictional stable node version?

2) Rails 3: I thought you were talking about sinatra? Where did Rails come
into this?

3) Again with the versions. It would be nice to give a good reason why for him
the push to 1.9 would be so important.

4) Speed: Yes, the V8 engine is quite fast. This won't matter for most of your
work, though. Most of the heavy lifting for Node's event system is done by
libev (written in C), the same that's underneath Eventmachine. Compared to
I/O, it will hardly matter. And if it will, then moving to a compiled or JVM
language will probably still be better.

5) Mobile: What's wrong with JRuby? It's closer to Dalvik than anything else.
And again, what's the connection to node? You're not much better of there,
never mind that it uses the same engine as in the (Froyo) browser.

6) Familiar frameworks: Not that familiar, as event-driven code has to be a
bit different. But yeah, you've got a sinatra clone...

7) Javascript: Finally a good point. A single implementation language is
usally quite nice, and not everyone wants to go the Seaside/Parenscript route.

Don't get me wrong, it might as well be a good decision, but these arguments
are a bit immature, especially all the blabbing about Ruby 1.9, which isn't
exactly the complete and utter miraculous revolutionary step.

~~~
tptacek
Since when was EventMachine written in terms of libev? EventMachine, last time
I looked (which is recently --- we write a _lot_ of EM code here), has its own
idiosyncratic event library.

~~~
mhd
Don't know with what I mixed that up (POE, probably. I know, libev is only an
option there). Not that libev is a rather huge software, it's basically a
wrapper around whatever the host OS provides (select, epoll, kqueue). From
looking at it, eventmachines's C extension does the same. So my main point
stands: A big part of the performance characteristics of node come from a
lower-level C functionality. I guess that having an infrastructure that's
mostly asynchronous comes second. Pure V8 speed won't matter that much for
most tasks. If someone has counter-examples, I'd be pleased to hear them. As
often with concurrency, better memory efficiency would probably win out.

------
bradleyland
A lot of the same comparisons could be made between Ruby/Rails and
Java/Spring/Faces/Struts/Hibernate/etc when the Ruby/Rails combo first came
out. That is to say, when a technology is in its early stages, fragmentation
hasn't had a chance to set in. I think Node.js stands a pretty good choice of
avoiding fragmentation for the near future, but that is only because it is a
pretty raw implementation. Node.js is apples where Ruby on Rails is oranges.

Another thing the author would be wise to note that Node.js may not be ready
for prime time just yet. The author has been attributed as saying such as
recently as May of this year:

<http://www.yuiblog.com/blog/2010/05/20/video-dahl/>

The API needs to stabilize a bit before I'd roll a large amount of code on top
of it. If there's anything I've learned from Ruby on Rails, it's that you have
to be prepared to tear in to a plug-in or module if the maintainer decides
they're not going to maintain it with future versions of the technology that
it plugs in to.

Overall, this rant jumps all over the place. We go from Sinatra, to Rails, to
mobile. How is the switch from Sinatra to Node.js relevant to Ruby in a native
mobile environment and also Rails? It's all just a little bit confusing.

I'm responsible for the app hosting environments at our company, so I
understand the author's frustration with Ruby versions and the impending
release of Rails 3. About 6 months ago, we started on a brand new web app and
decided that we were going to look toward the future. We built it on top of
Rails 3 (first beta) and Ruby 1.8.7. I literally had to compile various builds
of Ruby 1.8.7 until I found one that would work with the first Rails 3 beta.
We had to hold that configuration through Rails beta1 because we couldn't find
a config that worked with Ruby, Rails, and all the plug-ins we are using. It
has been _painful_. But now that Rails is closing in on a 3.0 release, and
Ruby is closing in on 1.9.2, things seem to be coming together. Plug-in
authors see a light at the end of the tunnel and are running toward it.

I also strongly disagree with the authors sentiment with regard to RVM. If
there is a strong point to Ruby on Rails development, it is that every layer
of the stack has received a lot of attention. RVM is an elegant solution, and
it works well with bundler, which is integral to the Rails 3 release. Having
pushed forward through several releases on top of Rails 3, RVM, and
Capistrano, I can say with confidence that Rails app deployment has arrived.
Mixing/managing Gem versions for production and staging environments in one OS
environment is ready to rock. The one caveat being that there is no good
solution for running more than one version of Ruby. The Passenger team is
working on a solution to that, but I'm not sure we'll ever implement it.
Running mixed Gems is one thing, running mixed interpreters in another. My
preference is to keep some level of consistency at that layer.

I've not addressed all the author's points, because he's right about some
things. Specifically speed and the "ooooooh shiny" mentality of most Rails
developers. My lead developer is the best programmer I've ever worked with. I
wouldn't trade him for anyone, but I do find it a constant battle to force a
strict vetting process of new technologies. We went through no less than three
authorization plug-ins during the early stages of app development on our most
recent project, and the last revision consumed a not insignificant amount of
time to strip from the project. I still feel like the trade-offs are worth it.
At least for our project.

------
el_chapitan
Perhaps I'm missing something. Who is this that is announcing they're
switching? Is there a specific reason that HN as a whole cares?

~~~
duck
I have no idea on who it is and I don't think it matters, but rather it was
some interesting points and thought it was fitting to see where others on HN
thought about it.

~~~
el_chapitan
OK, I was just spending far too much time looking to figure out who it was,
and just had to ask.

------
kls
I never was big on Ruby since writing JSON services with servlets and doing my
UI in pure HTML / CSS / JavaScript gave me the same agile velocity. But I have
to say writing JSON services with Node has become a more and more attractive
proposition. It is so light weight and fast that I have been looking for the
right project to get my feet wet on it.

