
Why we moved from NodeJS to Ruby on Rails - heroic
http://blog.targeterapp.com/post/22984987832/why-we-moved-from-nodejs-to-ror
======
Spyro7
I really do think that, as time wears on, we will see more of these incidents
of people switching from Node to another, more familiar development
environment. It seems to me that a lot of people started using Node simply
because of the amount of hype that surrounded it, and many of these decisions
were not as well researched as they should've been.

Reading through this gentleman's blog post, it seems that, originally, Node
was chosen for just one reason – he wanted to develop the entire application
in JavaScript. Other than this, it does not seem that he took the time to
research the Node development environment before deciding to develop his
application in it.

With respect to the author of this post, the testing environment and the ease
of developing a CRUD web application are things that should have been looked
into before a single line of code intended for production had been written.

In addition to this, as several other commentators have already noted, Node is
not directly comparable to Rails. Node is basically an event framework and
standard library that bolts onto JavaScript. Node would be more comparable to
something like Python's Twisted or Ruby's EventMachine. The author was
probably using one of the frameworks available in Node such as Express.js,
Railway.js, or Geddy.

~~~
heroic
Actually since the app was developed at startup weekend which gives you 54
hours to make a presentable demo, I'd say testing was not the first thing on
their mind.

~~~
mgkimsal
And it's generally nowhere near 54 hours... more like 42. We nominally started
at 6pm on Friday night, but teams weren't formed until 9-10pm. Pitches were
demoed Sunday afternoon, and 48 hours from the start on Friday - Sunday at
6pm, it was all over. I've no clue why they SW fixates on the "54 hours"
number. 42 would be far closer to the truth, but perhaps more intimidating for
people?

------
bad_user
I only played with Node.js and I didn't like it. The event loop is cool for
long-lived requests. It scales and so on.

However for the project I worked on, I decided to go with Ruby on Rails + Java
Servlets.

You see, only some parts of an API needs to scale. But what about simple web
pages like the viewing/editing of a user profile? What about viewing some
stats that are auto-generated? What about the freakishly boring admin
interface that every web app must have? What about deployment automation? What
about just searching for a library that already does what you want and
actually finding a good one?

Therefore I've built a Ruby on Rails app. Everything except the API that
needed to scale was built on top of Rails. Then the API with scalability
concerns was built as a couple of Java servlets. And I deployed the whole
thing on top of Jetty.

The wonderful thing about Jetty is that it has support for continuations, so
requests don't have to block on processing in case you're doing something
expensive. You can just push that processing in an Akka actor and release the
request until a response is ready. And Jetty may not scale as well as
something custom built on top of JBoss Netty or Apache Mina, however a single
Jetty server does scale to ten thousand requests per sec easily. And in case
that doesn't satisfy me at some point, Netty and Mina are there, waiting for
me to tap their potential.

And then with the wonderful JRuby-Rack integration, I could configure Jetty to
select between the pure Java implementation and Ruby on Rails for serving,
based on the URL. So everything, like the Rails server, the Java servlets for
the API and the queue processing (Akka) is running in a single process. Which
really, is freaking awesome.

So why use Node.js, when I can get the Rails maturity and ease of use, while
escaping to Java in case I have special needs, such as extreme scalability or
flexibility?

------
mmahemoff
I could write a similar post, having used Node on a couple of projects before
nodding to reality and switching back to Rails for a larger project.

For a "typical" web project, Rails simply has a ton of mature libraries that
don't exist in Node, or are very early days. Sure, there might be a basic data
mapper, but does it have support for testing? Automatic counter caching?
Workaround on StackOverflow for a hundred things the framework doesn't cover
by default?

Rails versus NodeJS isn't apples-to-oranges. Rails is an opinionated framework
for web development, Node is a low-level evented framework. This is important
because right now, Node has no Rails equivalent. It has Express as the
equivalent of Ruby's Sinatra, but for a higher-level web framework, there are
several possibilities and none of them the outright leader. This is the
situation Python found itself in circa 2006, before Django became the de facto
standard for web apps, and (speaking as a mostly-outsider) its seems to me the
Python community is better for it. I truly hope a high-level framework
establishes itself as the clear standard for Node development, presumably one
which embraces the benefits of dual-side JavaScript.

~~~
heroic
There is a project coming up - railwayjs. I hope it changes the way people use
nodejs!

~~~
tjholowaychuk
That's part of the problem in a way. Rails-style large applications are kinda
poor by-design. Even Express suffers from this more than I'd like (express-
specific plugins etc). Ideally Express "plugins" or extensions would just be
thin wrappers around things that the rest of the Node community can utilize.
I'm guilty of this too of course but that's largely due to time constraints.

Anyway, writing Rails for Node won't be anything revolutionary, it would just
be... Rails on a different platform. Frankly lots of developers including
myself prefer these smaller frameworks, sure some things might be a bit slower
to get started with but ultimately you're not fighting a framework, it's just
another block of lego.

I used Drupal for about 3 or 4 years, and you can get things going much faster
than Rails even, but you'll spend a lot of time fighting the thing.

------
claudiusd
When it comes to prototyping, anything goes - you should be optimizing for the
speed with which you can deliver and market-test a product, and you should
choose the tools that allow you to do so. The trick is having the discipline
to pay back the technical debt that accumulates as a result of the fast,
informal prototyping work.

I think the OP did exactly that, realizing that Rails is the better long-term
solution for their engineering activity. I wouldn't say they "moved" from
NodeJS to RoR, because that implies that that they chose a new technology to
solve the same problem - they didn't... they chose NodeJS for prototyping and
RoR for production.

I had the same experience transitioning from a prototype RoR app to a
production app also written in RoR - I still did significant rewriting to
improve testability/test coverage and make it more RESTful, but I didn't need
to switch frameworks to do that.

------
Fluxx
> NodeJS is suitable for apps that do plenty of short lived requests.

I'm confused. Isn't Node's event-loop style programming ideal for long-lived
requests? I.e. ones that, under a synchronous i/o, block other requests?

~~~
karterk
The OP probably meant short-lived with reference to CPU bound requests.

~~~
benatkin
OP explained things improperly, then. It's an important detail, because Rails
currently defaults to single-threaded. This makes an operation such as
fetching and returning a twitter feed in a single request (assuming it takes
hundreds of milliseconds to get a response from twitter's servers) expensive.

~~~
bad_user
Only rookies do that inside the web server process.

The job of fetching a Twitter feed can be offloaded to a background jobs
queue. With a little help from Nginx, you can free the Ruby process to take
care of other requests until the response of that Twitter feed is ready.

Or you could simply deploy your Rails app on top of a Java server, by means of
JRuby and forward that request to a servlet that uses the continuations
support in EE 6, offloading the request to an Akka actor and freeing the
pipeline until it is ready. Works great and you can even write everything in
Ruby ;-)

Also, Rails does work with multi-threading.

~~~
reissbaker

       Rails does work with multi-threading.
    

Ruby has no support for concurrency, no matter how many threads your
interpreter is using. 1.8 had no OS threads at all, and 1.9 has a global
interpreter lock. This is not solvable in the application layer (for example,
by a framework like Rails): this is a problem inherent to the runtime.

~~~
bad_user
JRuby is fully parallel with no global lock and many people choose it for
deployment. Rubinius 2.0, which is in development, will also lack the GIL.

You're also very confused about how threading on Ruby MRI 1.9 works. First of
all, pure Ruby code in 1.9 can and does execute on multiple OS threads, in
parallel.

Also, the problem that the Ruby VM still has is that while executing native
code, it does not allow a context switch unless that code explicitly informs
the VM that it can do a context switch. This is in effect how the global
interpreter lock works. The gotcha here is that native extensions that are
well behaved, can inform the VM that a context switch is possible. For
instance, the older "mysql" gem was NOT well behaved, blocking context
switches between threads, but the newer mysql2 gem does behave well and works
correctly in multi-threading.

Right now, if you start a new Rails 3 app, it will work in a multi-threading
environment correctly and modern Rails servers are taking advantage of that,
unless you install some older gems that haven't been fixed. The biggest
problem is that you can't know what libraries are well behaved, but if that's
too much of a burden, JRuby is a fully supported platform for Rails and
doesn't share the same issue.

So like, seriously dude, do some reading.

~~~
reissbaker
Pure Ruby code in MRI 1.9 can run on multiple OS threads, but it can't run on
multiple OS threads in parallel. Here's some reading you can do if you're
unsure:

<http://merbist.com/2011/10/03/about-concurrency-and-the-gil/>
[http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-
ru...](http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby/)
[http://jabberwocky.eu/2010/10/02/where-is-the-global-
interpr...](http://jabberwocky.eu/2010/10/02/where-is-the-global-interpreter-
lock-/) <http://en.wikipedia.org/wiki/Global_Interpreter_Lock>

Yes: Ruby can allow native code to execute in parallel with Ruby code
(although it doesn't always do so, as you note). But if you're under the
impression that multiple Ruby threads can execute in parallel, you're wrong.
That may or may not be a problem, depending on what you need Ruby to do.

JRuby can be a good option for parallelism, but it's also slower than Ruby MRI
1.9 and has an ecosystem that most Ruby developers will be unfamiliar with.
Regardless, my point was that Rails doesn't magically "work with
multithreading," at least for standard Ruby deploys.

------
mbostock
This post would benefit from concrete examples rather than vague complaints.
For example, if something is "very immature", why not include specific
examples of bugs or issues that required upgrading to "the latest version"?
Likewise, if Node's testing frameworks are "good" but "no match for … Django",
explain what's missing or how other testing frameworks are better. Being
precise with your criticism helps the reader put them in context, and also
helps maintainers improve their projects. Unsubstantiated criticism merely
generates fear, uncertainty and doubt.

------
j45
Wow, Node is being turned away from because it's too new, and Rails is the
destination because it's established?

I remember a few years ago Rails using the argument of re-inventing the wheel
was the only way because there was presumably no other capable web framework
out there.

We all know better now and I hope celebrate choice that's relatively equally
capable :)

~~~
VeejayRampay
Maybe some day people will finally realize what's so awesome about Ruby on
Rails. It's not the libraries and the fact it's been around for almost 8 years
now. No, it's simply the language. Ruby is a fantastic language and an
addictive one at that. Once you get a feeling of how productive and expressive
it is, it's enough of an incentive to keep at it. The same goes for Python by
the way, another GREAT language. One day people will realize that Javascript
just doesn't cut it.

~~~
j45
I think you totally missed my point.

I was just speaking to how Railists too often, do not openly consider or think
anything productive, well structured, or maybe even great could have existed
before, or at the same time as Rails for the web.

We forget the difference between a language and a framework as well. Too many
folks short sightedly compare a language to a framework. Frameworks will
always evolve and change, and few rarely do anything new or novel, just like
languages may, but they're entirely different things.

------
julian37
_The data is being written to the db, or being crunched, while the request is
ending, and the browser can continue with the important stuff._

It sounds like a good fit for NodeJS for sure, but for what it's worth, even
in a synchronous web framework nothing forces you to keep the connection open
until the request has been processed.

I don't know off-hand how to do it in Rails, but say in Java Servlet-based
frameworks you'd just call HttpServletResponse.close().

~~~
heroic
The point is that the rack middleware would be called for everything, which is
very heavy for something so trivial

~~~
julian37
I didn't mean to imply that NodeJS isn't the best fit for the problem at hand.
I was just trying to clarify that it doesn't take an asynchronous framework
like Node to keep processing a request after the connection is closed.

~~~
mike-cardwell
Yeah, even with a simple Perl CGI, all you have to do is close STDOUT if you
want the HTTP response to end, but continue processing the request.

------
nkoren
I suspect -- and I may be wrong -- that the advantages of using Node differ
between large teams and small teams. For my first startup, I had the budget to
hire a single full-time developer. The was a substantial amount of work to do
on both the frontend and backend -- with the backend development needing to
get underway first, but the frontend work being much more experimental and
needing to go through many more iterations as part of the development process
(we understood this upfront).

My developer did his homework, and came to exactly the same conclusions about
Node that this article highlights. So he began developing the backend in
Python/flask. I'm sure that was a good choice for the backend, on general
principle.

However, we began hitting problems when it came time to start developing and
iterating the frontend in parallel with the backend: it proved to be almost
impossible for a single person to handle the task-switching between two
completely different languages, testing frameworks, etc. So backend
development lagged a little, and frontend development lagged a _lot_. I'm
fairly sure this set the project back by 3-4 months. It wasn't until we
brought on a dedicated front-end programmer that development was able to pick
up pace a bit.

So I can see how for larger companies, it is probably best to optimise the
backend with something other than Node -- you will have enough people working
for you that backend and frontend programmers can specialise. But for
companies with two (or fewer) developers -- which know that they also have to
be doing a quite substantial amount of javascript on the front-end -- then I
suspect that Node's comparative small task-switching penalty is probably
_hugely_ valuable.

That's just my hunch, but it's lasted a long while. So as I get ready to hire
a couple of developers for my second startup, I'm leaning towards using Node.
It's a frontend-intensive application which is unlikely to ever have to deal
with "web-scale" issues that more mature backends are needed to handle. And if
it _does_ ever approach "web-scale", then it'll _certainly_ have the budget to
hire additional programmers to re-implement the backend in something else --
or maybe, by then, Node will have evolved into something sufficiently robust.
Either way, it seems better than causing ourselves a bunch of task-switching
pain upfront.

I'd be really curious to see a critique/comparison of Node which addresses the
relative merit (or lack thereof) of its low task-switching barrier --
particularly for small teams.

~~~
yannski
What it this "low task-switching barrier" ? I mean, even though, the language
is the same, back end coding and front end coding are really different. For
example, your front end development may have lagged because of lack of front
end development knowledge, not because of this mythical task switching barrier
that everyone is talking about !

~~~
danbmil99
Maybe not true for everyone, but I find when working on quick prototypes of
web ideas, where I have to write both front and back-end code, the fact that
they're both in the same language with node.js is actually a huge advantage --
much greater than I expected.

~~~
yannski
IMHO the main problem is that usually front end development implies XHTML/CSS
integration and/or UI and/or UX, and that's a very different job from back end
development.

------
jroseattle
I read this post as "your mileage may vary", gravitating toward "it doesn't
work like we expected". One particular line caught my eye:

"NodeJS’ async everything wont have any affect on a CRUD app. Popular
frameworks, provide very good caching and everything that is needed for your
app to work fine even synchronously."

There is a lot to this statement that implies how an application is
architected. Node.js is async at heart, and one can only build a successful
application if you follow the programmatic model as it's designed. It doesn't
matter how simple or complex an application may be, if a framework is being
bent to work in ways in which it wasn't designed, the application may not work
so well.

Reading between the lines, what I'm getting is a picture of a team that has
encountered productivity issues with the current stack and is migrating to a
more familiar stack to increase productivity. Nothing wrong with that
tradeoff, but I always look to what future tradeoffs are being made: "cache
everything and gets the work done ASAP" is great _until_ you need finely-
grained control of your queries.

I'm sure they thought well about their decision, but if asked to make a wager
-- I'd guess that certain problems are being traded from one framework to
another.

~~~
prospero
I think the point wasn't that "asynchronous is hard", it's that "asynchronous
is just incidental complexity". CRUD apps don't need to be asynchronous, and
node.js has a relatively impoverished ecosystem for such apps.

There are undoubtedly tradeoffs no matter what you use, but this seems like an
eminently practical decision.

~~~
jroseattle
I'm not so sure about that (the async-is-hard part.) If one is making a
decision of architecture change due in part to CRUD capacities within a
framework, I'd guess the asynchronous programming model in Node.js is a little
more than just incidental complexity.

CRUD operations within R/R might be just a few lines of code, but it's not
_that_ much more to accomplish the same with Node, Express/Railway, and any
one of a bunch of template schemes.

The change certainly sounds appropriate for the team, but the basis of CRUD as
a reason to change an entire architecture leads me to question how the team
approached their solution with Node.

~~~
prospero
Unless you're taking the sunk cost of the node.js development into account, I
don't understand your point.

If the core programming model for node.js doesn't help them in any way, and
the ecosystem is less mature, then it kind of misses the point to say that
everything is doable in node.js. Whether something can be accomplished is not
a good metric for whether a platform is productive.

~~~
jroseattle
> If the core programming model for node.js doesn't help them in any way, and
> the ecosystem is less mature, then it kind of misses the point to say that
> everything is doable in node.js. Whether something can be accomplished is
> not a good metric for whether a platform is productive.

Hmmm, don't recall saying everything is doable in Node.js. I was speaking of
CRUD operations.

I've had experience with many teams who have made similar architectural
decisions based on broad, abstract data points, i.e. programming model,
ecosystem maturity, etc. Frankly, making these types of decisions on those
over-arching points rarely leads to good decision making. Most often, problems
of one type are simply exchanged for problems of another, and it's usually
caused by lack of real evaluation of system/architecture needs.

I'm not arguing this team shouldn't make this switch, just that the stated
reasons don't pass the sniff test. I think the team prefers to programmatic
model of R/R to Node, and feel they would be more successful going forward.
But I would be hard-pressed to believe this transition is being made for most
any reason beyond comfort and familiarity, as opposed to significant system
limitation.

------
jarin
This is why it's good to have a lot of tools in your toolbox. Everything has
its strengths and weaknesses.

------
MatthewPhillips
The author seems to be confused about what Node.js is.

> NodeJS is a very young framework, and packages around it are very immature.

Node.js is not a framework. It is a JavaScript engine and standard library.
Node is comparable to the MRI.

~~~
heroic
First thing is that NodeJS is not a JS engine, V8 is. Second,
<http://notinventedhe.re/on/2011-7-26>. That is from
<http://nodejs.org/community/> which makes the terms quite right, i'd say.

~~~
MatthewPhillips
Node _is_ V8 and a standard lib. Node is not an abstraction around http (which
is what RoR is).

~~~
heroic
"Node.js is a platform built on Chrome's JavaScript runtime for easily
building fast, scalable network applications."

From nodejs.org

~~~
MatthewPhillips
Right, and "fast, scalable network applications" !== "http abstraction layer".
Node doesn't even come with an http abstraction, it comes with the standard
request/response objects that nearly every standard lib ships with.

------
andybak
Maybe I'm missing something but isn't node for chat/messaging, API's and other
stuff that you might have used something like Twisted for?

Why would you use it over Rails/Django etc. for a content-heavy site (i.e. 95%
of websites)

~~~
triathlete
I use node for everything now myself for a number of reasons. The "problem"
with node is that its still very young. And its a different programming model
then people are used to. So its similiar to the whole RDBMS/document store
argument. You use what works for your applicaiton.

The thing that annoys me personally is that they make it seems like there
something wrong with node. And there isnt at all.

~~~
andybak
Does it provide any of the functionality that you get with a Django/Rails
style framework? Or is it at a lower level?

~~~
triathlete
Yes of course via express.js and railway and several other frameworks. Again
node itself is just a set of libraries on top of of v8. So its not a proper
comparison.

Personally i use express.js and roll my own framework essentially because i
prefer to work that way.

------
fiaz
The important point in posts such as these is that execution matters, not the
tool you use. If the tool you decide to develop with fits, then use it. If you
find out later it doesn't work, then switch. Sure, the tool you use can affect
your execution, but that only means you have to understand how you want to
execute before even selecting a tool.

I think it would be a big mistake to read such a post and come to the
conclusion that Rails is somehow superior to node.js.

------
rmATinnovafy
My take on this is that it is more about getting the MVP out with "whatever"
(in this case Node), than anything else.

I do this all the time. Some ideas get mocked up in python, others PHP, some
in C#, etc. Then if it sticks, I look at the needs it has and pick the best
tool for the job. Sometimes it Rails, others its .NET.

Though it is quite interesting to read about it from someone else's point of
view.

------
petercooper
This reminds me of Derek Sivers switching from Rails back to PHP 5 years ago
:-)

[http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...](http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html)

~~~
wamatt
Haha great find. Thanks. I agree, I think it would have been important to also
say just how quickly Node.JS has developed.

I'm a firm believer it has a very bright future, but this is not a zero-sum
game.

------
Timmy_C
The argument he makes is that it boils down to maturity. One framework is
still evolving and the other is more mature.

~~~
heroic
Exactly the point being raised i'd say!

------
sh1mmer
I'd be curious which things were missing in Node. I realise gratuitous detail
doesn't make for a great blog post but if Node.js is missing things that
stopped development of an app it would be useful for the Node community to
know what they are.

Mentioning "immature packages" and "testing" is fine, but I'd really like to
know what makes testing on RoR better than, say, testing with Mocha.

I'd also be really interested in the experiences of trying to cache with Node.
I think while it's possible to do it's definitely a place that could be
improved.

~~~
heroic
IMO, things like a good ORM(or ODM) are still way too far off in NodeJS. I am
aware of mogooseJS, but it is very far from the power provided by ActiveRecord
and Mongoid.

Also mocha is powerful, but if you have a look at capybara and rspec, they are
much more powerful and friendly.

The final thing in my opinion is the speed of development. With rails you go
to devise, and you have authentication. I am aware of the presence of a
similar authentication system for nodeJS but I am not very sure if that works
with mongoose js and is as extensible as devise is. And then there is the
rails console, which makes trying out things real easy and fun.

~~~
philbo
I started looking into libraries for a Node-based model layer this weekend.
The two most interesting after my initial reading about are Tubbs [1] and
Resourceful [2].

I won't have a chance to actually play with them properly until this weekend
unfortunately. Anyone else have any experience with these two (or other
options)?

[1] <https://github.com/dandean/tubbs>

[2] <https://github.com/flatiron/resourceful>

------
javajosh
Anyone else find it ironic that this post is about moving from Node to Ruby in
order to produce the admin interface to a _Java_ hosting service? (This was a
blog post written by "Jelastic" devs, who make a Java PaaS product).

We seem to be seeing more of this "don't eat your own dogfood" approach to
software development lately. The other example that comes to mind is the Play
Framework, written in Python and also targeted to Java devs.

~~~
SiVal
I see what you mean by ironic, but it might be a bit less ironic when you
consider the history of the name "JavaScript." Its original market positioning
was as a lightweight complement to the heavier Java. Now we have other
languages serving in that capacity as well: Python, Ruby, Scala, etc.

I don't know if there will someday be a language that is as easy to work in as
a Python or Ruby for simpler programs but which lets you get (almost) as fast
and fine-grained as C as your features stabilize and you start to optimize,
but while we're waiting for Godot, it's not too ironic to use different tools
for different projects, even if the project relates to one language in
particular.

(And I don't know why you were downvoted for this. Sheesh, downvoters.... I'm
contradicting you a little with my post, but I see no reason why you shouldn't
say what you think. So, after contradicting you, I'll now go and cancel your
downvote with my upvote. How's that for irony?)

~~~
Or1on
>I don't know if there will someday be a language that is as easy to work in
as a Python or Ruby for simpler programs but which lets you get (almost) as
fast and fine-grained as C as your features stabilize and you start to
optimize

Have you looked in to Cython? It seems like it tries to do what you wrote.

From <http://cython.org/>

"The Cython language is a superset of the Python language that additionally
supports calling C functions and declaring C types on variables and class
attributes. This allows the compiler to generate very efficient C code from
Cython code. The C code is generated once and then compiles with all major
C/C++ compilers in CPython 2.4 and later, including Python 3.x. PyPy support
is work in progress and is mostly usable in recent developer versions."

The latest Gevent dev uses libev (same as node.js) I'm curious to know how
Cython and the new Gevent will perform vs the alternatives.

------
LoneWolf
First of all I would like to say that I'm no fan of these 54/whatever hour
coding rushes, I think it makes people go too fast with poor planning and NO
time for testing anything, even for developing looks short, I would rather
take my time to plan anything before writing a single line of code.

About Node I have played with it and it looks nice but at the end of the day I
just returned to Java and PHP (can't talk about ruby never tried and not sure
when I will), why? First, all the Node talk seems to revolve around the hype
it generated recently, why I don't know. The idea of the async is nice but
stall it with something that takes long to process (and needs to send a
response) and you are screwed just like any other language, but I think node
may be worse as far as my understanding goes its a single thread dispatching
stuff (am I right? please correct me on this if I'm wrong).

Libraries for it, there seem to be too many of the same kind all of them with
different ways of working that is not easy, and when I tried it none did what
I wanted.

------
EternalFury
Does anyone know 1 major consumer-facing site that was able to scale with
Rails?

I know Twitter kind of had to move away from Rails due to scalability issues.

GameBattles.com also had to back away from Rails after their uptime dropped to
80%.

I am not trying to tarnish Rails, I am just curious to learn about some
success stories involving Rails at very large scale.

~~~
tptacek
Github, Airbnb, Groupon.

Three reasons people think Rails doesn't "scale":

(1) Earlier versions were adopted by applications with anomalous scaling
requirements. So, the project had to "learn to scale" on its feet in a very
short amount of time. There were predictable hiccups. Or, put even more
simply: it's a young framework that got adopted quicker than people expected.

(2) There's an expectation that web platforms can accomodate near-automatic
horizontal scaling with maybe just a couple config-file tweaks. That
expectation is unrealistic on any platform for which you can easily hire
developers. The reality is that scaling to Twitter or even Github's volume is
extremely difficult, and the developers who can reliably accomplish it on
_any_ platform are extremely hard to find and extremely expensive.

(3) Rails attracts a kind of junior/casual developer that Python just doesn't
have, and (weirdly enough) also I think attracts systems developers like
myself that aren't steeped in web scaling folklore, which long story short
means lots of projects start out by making lots of embarrassing mistakes.

In our practice we see much more Rails today than we do any other framework
(there may be some selection bias there, but probably not too much) and for
the most part Rails just works. It is definitely _not_ the case that we see
lots of startups go out the gate on Rails, go "oh shit we can't scale", and
switch to something else.

~~~
hkarthik
> There's an expectation that web platforms can accomodate near-automatic
> horizontal scaling with maybe just a couple config-file tweaks. That
> expectation is unrealistic on any platform for which you can easily hire
> developers.

I can attest to this. I did consulting work for Match.com a few years ago back
when they ran around 20 million uniques/month. They are a .NET shop here in
Dallas, TX where you can throw a stone and likely hit a .NET developer.

After a few years, their stack looked nothing like a typical ASP.NET stack. It
included things like custom database replication, memcached, config pulled out
of files and stored in actual code, and lots of other things that went way off
the beaten path from standard practices for .NET. New developers often had to
learn "The Match Way" before they could be effective. Many things that worked
with typical .NET enterprise apps would break down spectacularly when massive
scale was thrown at them.

------
ronreiter
It saddens me that so many developers need to learn why it's a mistake to
build a system in node.js right now, just because it's "cool" right now. A
variation of this post showed up on HN about 20 times already.

The lesson is simple - don't use node.js to build big apps, it's still
immature.

------
sasha-dv
This reads like my life story. Falling in love with a new technology, trying
to use it in production, only to find out that it just isn't there yet :)

Node.js will become a great option for web development, but I don't think that
node, at this moment, is ready for "mainstream" use.

~~~
gordianknot
To me that's the value proposition actually. Invest in learning and
collaborating now, then be ahead of the curve in a few years (if interested in
getting hired) or be ready to capitalize and know how to hire and make
software that only could've been made with it when it eventually reaches some
level of maturity. I mean, those that grow it reap the best rewards.

Software is a product of the platform(s) it was built with, in the same way a
novel is a reflection of the writer's language more-so than the writer.
Microsoft's software is what happens when you use C and .NET; Google with C++,
Java, and Python; Facebook with PHP; 37signals with Rails; etc. There are apps
that will be built because they could only be built with a unified JS
platform. There will be new kinds of software that directly result from the
new possibilities of Node, CoffeeScript, Meteor, Firebase, Parse, etc.

Different tools yield fundamentally different results. Once a platform is
"mainstream", it's to late, the big opportunities have already passed and the
innovation is elsewhere. There's still a chance to be the "DHH of Node"; that
spot's obviously already been taken in the Ruby world.

~~~
sasha-dv
Learning new technologies is something I do, not because I'm interested in
getting hired or in becoming the DHH of node. I would do it even if I were by
profession a truck driver.

This may sound "romantic", but when your love of technology interferes with
you actually being productive and getting things done, ... it's frustrating.

If you are a student, then jumping on a new platform and making a name for
yourself is a great thing to do. But I'm an old fart, I was there when Java
applets were "the thing that will change the world".

>There will be new kinds of software that directly result from the new
possibilities of Node, CoffeeScript, Meteor, Firebase, Parse, etc.

Like what? (not rude, just curious)

As far as I can see there's nothing new under the Sun, so to speak.

~~~
gordianknot
I hear you, and can relate to the romance and frustration! I was in grade
school when JS was released... but've been writing it for over 10 years now. I
tried "everything" else, and it's made be a better JS hacker, but I feel like
I'm doing it wrong when I use anything else.

I didn't mean to suggest riding the wave of new, distinct, non-progressive
technologies. Their _is_ a progression; it seems clear to me that PG was
right, that we (as an industry) are slowly moving toward Lisp. He also said
that he felt Lisp and C represent the two "clean, consistent" programming
models, and I agree. And that's the reason that JS isn't just another passing
wave (although my previous comment did seem to make that suggestion).

JS is something different; it's (1) a good-enough balance of C and Lisp and
(2) available on every platform. To me, the situation is clearly that JS will
form a solid, durable layer over C. Then the language designers and industry
hype machine will shift to langs that compile to JS. This is already
happening, naturally, it's just not evenly distributed.

> Like what?

We're still in the early days of compiling to JS, and being able to use it as
a modern server-side environment. I don't know what the results will be, but I
think the difference will stem mostly from development time. Even though it
could be done, in practice you don't end up with the same app if using
Fortran, Java, and CoffeeScript, because doing so would take a month versus a
week versus a day. To paraphrase Linus from his Tech Talk on Git, speed
doesn't mean you do the same thing faster, it changes behavior.

Apps will get written that wouldn't've. I'd argue that Facebook succeeded
mostly because of PHP, and in turn, that they'll eventually fail because of
it, too. They beat MySpace because MySpace used the MSFT stack; it's like
England's victory over Spain due to more nimble war ships. Same thing'll
happen to FB unless they evolve when necessary.

This is what Yegge was getting at back in '06 [Dreaming in a Browser Swamp].
He mentioned "Scheme on Skis" and "JavaScript on Jets", which might turn out
to be ClojureScript and Express or Railway. Well on our way, and he was
entirely right in retrospect (even though a shocking number of smart hackers
don't want to accept it and keep on with archaic tech that's becoming rapidly
endangered, but that's life).

Light Table is an early example of an app that's happening because of
ClojureScript. And many exiting CoffeeScript apps are quite impressive:
<https://github.com/jashkenas/coffee-script/wiki/In-The-Wild>

I think it comes down to being able to focus on design and make fast changes,
without needing to worrying as much about the lower layers of abstraction.

------
mcantelon
I wonder what testing functionality, specifically, they see missing in the
Node ecosystem...

~~~
FooBarWidget
I'm writing a server in Node and to date I'm still trying to figure out how to
control the main loop from Node. I want to write tests like this:

    
    
        1. register some timers and create some sockets
        2. send some stuff over the sockets
        3. wait until the socket handlers received some data which cause the handlers to unregister the sockets and timers
        4. at this point, the main event loop has ended. go to next test and setup a new event loop
    

How do you do (3) and (4) in Node? I have no idea, and I couldn't find any
clear answers on the Internet. I ended up writing my tests in RSpec which
launch Node processes, and I just check whether the stuff printed to stdout
matches what I expect. RSpec also happens to have a much much nicer syntax
than any Javascript testing framework I've encountered.

~~~
bergie
That sounds like a complicated approach at it. Here's an example of some
NodeUnit tests that involve communications with a Redis-based message queue:

[https://github.com/bergie/noflo/blob/master/test/MQ_SendMess...](https://github.com/bergie/noflo/blob/master/test/MQ_SendMessage.coffee#L46)

More BDD-ish version of something similar:

[https://github.com/nemein/kckupmq/blob/master/test/001_kckup...](https://github.com/nemein/kckupmq/blob/master/test/001_kckup-
mq.coffee#L111)

~~~
jerf
Does that test you link actually talk to a live Redis-based message queue that
must exist for the test to run?

If so, while that's a nice test there's also a need to be able to fully
control the event loop so you can test arbitrary event orders, some of which
you may not be able to synthesize (or not easily, or not reliably) but may be
able to occur in the real world. Testing event loop code sucks hard enough
when you can fake events perfectly correctly, take that away and it sucks even
worse.

~~~
javajosh
_> there's also a need to be able to fully control the event loop so you can
test arbitrary event orders_

Hmm, something doesn't sound right there. I'm not really sure why you'd want
to "fully control the event loop" for testing, but if you did you can install
a callback on every tick:
[http://nodejs.org/api/process.html#process_process_nexttick_...](http://nodejs.org/api/process.html#process_process_nexttick_callback)

If you want to test arbitrary inbound event sequences, you'll need to run at
least two processes. You could run two node processes, one generating events
for the other. This would probably give you a better test environment then
hacking the event loop, too.

~~~
jerf
"I'm not really sure why you'd want to "fully control the event loop" for
testing,"

Because while I'm actually one of the first to tell you that not everything
needs to be a unit test and I tend to prefer integration tests over unit tests
if given a choice, I will also say that unit tests still have their place, and
the way you unit test an event-driven program is to feed the events you
specify to an event loop and ensure that the proper actions taken, using
whatever is necessary to ensure proper independence.

It's nice to _be able to_ do integration tests, it is not nice to _have_ to do
integration tests.

You know, this may explain a great deal of the gap between my opinion of
event-based programming and the conventional Node opinion. Testing event-based
code isn't necessarily _that_ hard (testing is never really easy in a language
where you're always in the local IO monad equivalent, though cracking it up
into events does make things challenging, especially if you try to take
advantage of closures in your handlers, which unfortunately is advantageous in
other ways but hurts testability hard) but it doesn't help that the frameworks
never seem to ship with the testing support I just specified and I'm always
having to bash it together myself, which tends to show a certain... disconnect
in expectations between me and the authors.

------
kajala
If you think how the whole web development has been changing from server-side
generated views to more "produce data and send it over as JSON" style
services, Node.js and others start to make a lot more sense. That said, the
post has point that on more established platform you can expect to be more
productive since you have more established work flows and standard libraries.

Btw. note the terminology: Node.js should not be called "framework", it's a
platform. "Framework" is something that runs on platform and you extend/modify
it's functionality by writing code. "Library" is something which you call/use
from your code.

------
brown9-2
_Since our stack involved MongoDB, it only made sense to live in a JS only
environment._

I've never used MongoDB; can someone explain to me why this would seem like an
advantage, and/or what it has to do with MongoDB?

Is the MongoDB API simply JavaScript?

~~~
triathlete
Mongodb is a json document store. I use it myself. It works very well with
"node" because node of course uses javascript as its language.

~~~
andypants
It's not JSON, it's BSON. BSON supports more data types, which are needed for
a proper database (such as object IDs, longs, doubles, binary data,
references, etc.)

You still need a driver and a bson serializer if you use node.js.

~~~
viscanti
Sure. But it's certainly easier than most other languages. It's not a great
reason to switch for that, but working with Mongo is fairly trivial in Node.

------
gfosco
Basically they switched for... personal opinion. That's all I can really gleam
from the post. You can do it all in Node JS, they just didn't want to.

Screw all the frameworks, I am working with bare-metal Node and loving every
minute.

~~~
czzarr
definitely agree with this. I can understand why 37signals use RoR, because
they built it and know it inside out. But for a newcomer diving into rails now
is difficult because the ecosystem is so huge it's hard to navigate, and
everything is so integrated and you usually end up bundling a ton of thin that
you don't need. With node everything is modularized, it is much more easier to
understand what's happening under the hood, and streams are freakin awesome.

~~~
ryan_f
I disagree with this. By the ecosystem being huge do you mean the modules and
different gems? That in itself is modularized for having the choice not to use
them. The availability is what makes it powerful on top of the simplicity to
get it all running.

Node is by far not simple for a new developer or new teams running node.
Projects tend to drift toward unreadable due to poor design, just try
following people's callbacks. I am not saying this is Node's fault but it
being young results in developers' lack of experience.

~~~
triathlete
Im sorry but you make it sound like everybody that does rails is a perfect
programmer. Rails itself has changed over the years and if you look at an app
from years ago im quite sure it will be very different then a current rails
app. So again this is just not an appropriate comparison.

~~~
ryan_f
I don't think they are perfect programmers. Heck, I use several languages and
frameworks, whatever is right for the project. Knowing a language isn't a
perfect programmer (we all know that). And to your point, that was the
comparison I would make. Node is young so there is a lack of experience with
it.

------
semarjt
>I am huge fan of NodeJs and I believe it’s a very technology and we will see
it getting

I think you accidentally word.

~~~
sushi
Thanks. Fixed now.

------
sparknlaunch12
Ok. So for a beginner coder looking to build web sites and mobile apps on
weekends. They are not looking for a career or job coding. What language?

Assume they know html, CSS, Javascript, SQL. Where do they go and spend their
next 12 months?

When do the differences matter?

------
edwardtrunk
i think what i'm enjoying most about node.js and the new frameworks, is that
they require me to think differently. i'm also optimistic about coding end-to-
end in the same language (client, server, database). this is a big learning
curve for many folks. i remember when folks transitioned from C to C++ and
from C++ to Java -- it takes awhile. i think this is going to be a lot of fun
to see where it takes us. also i think work like coffeescript and future IDEs
might make this really interesting. Also meteor -- lots of creativity and cool
things.

------
philjackson
I'd love some elaboration on these points, especially the one about testing as
it's an area that interests me.

------
triathlete
For anybody wanting to learn about node the NodeUP podcast is excellent.

