
Why critics of Rails have it all wrong (and Ruby's bright multicore future) - saurabh
http://www.unlimitednovelty.com/2012/03/why-critics-of-rails-have-it-all-wrong.html
======
programminggeek
I love Ruby, but I have no love for Rails. Want to write a nice JSON API using
something light and nice? Use Sinatra, pick your favorite ORM (even
ActiveRecord) and go to town. Why mess with all the other Rails junk when you
can have a simple app.rb for your sinatra app and just write simple little
controller actions and you're good to go?

You don't need all the ceremony and structure of Rails and MVC to write a JSON
api, you just don't.

Worrying about Rails' future and if it's still "winning"(for some definition
of winning?) compared to node.js is silly and reminds me of how many Java devs
had an existential crisis about the future of Java since Java 7 took a few too
many years to ship.

Rails is a web MVC framework, that's it. It's not even the only or best web
framework in ruby. Rails is not ruby. It is not designed to compete with node.
Node is a totally different thing.

Compare node and ruby and that's a more interesting and correct comparison,
but I've happily used both and neither one is going to "kill" the other any
more than Rails killed PHP or Java killed C++.

~~~
cheald
"Rails" is a collection of libraries and conventions, just as "Sinatra +
ActiveRecord" is. There's nothing inherent in it that makes it "worse" than
Sinatra (which I love, by the way) for JSON APIs.

Use Rack, pick your favorite gems, and go to town. Why mess with all the other
Sinatra junk when you can have a simple config.ru for your app and just write
a simple call method and you're good to go?

You don't need all the ceremony and structure of Sinatra to write a JSON API,
you just don't.

~~~
joedoe55555
You cannot really compare Sinatra with Rails. Rails has scaffolding, DB
migrations and all this ultra-highlevel stuff rendering debugging to pure
guess-work. Reminds me of doing template-metaprogramming with C++. If it works
it's great and the performance rocks, if not you are left alone with cryptic
errors and nobody can help you.

~~~
jeltz
If you want Sinatra with scaffolding there is Padrino which I personally find
to have superior scaffolding compared to rails.

------
jes5199
(I'm a full time Ruby/Rails programmer, and I have been for five years.)

There's a major flaw in the R/R culture: they have no interest in maintaining
stable APIs. If you want to upgrade your Rails app to the latest version of
some library, you might as well do a rewrite of your entire app. So many of
the APIs change from release to release that most of your gems will stop
working unless you upgrade. When you upgrade the gems, _your_ code will stop
working, because most of the gems will have changed their public API. If
you've got a non-trivial application, you will essentially be unable to
upgrade. You will stop getting security updates. What minor upgrades you can
manage to do will leave things partially broken, and you'll just get used to
it being broken. (for example, one project I've worked on is stuck with a
brain-damaged RSpec library that reports error messages without interpolating
the strings, you always get "Expected CONDITION, got FAILURE, see CODE" in the
logs)

My recommendation: only use Rails for short term projects that will be
completely shut down after a few months.

I know that it's common wisdom that "no ruby engineer will ever want to switch
to java", but that's because you've never been saddled with a 2-year-old rails
project (or a 5-year-old plain-ruby project, which will have the same
symptoms, just more slowly). Then your team will be _begging_ for something
that runs its test suite quickly, that has enough static analysis to know if
you're using an outdated API, that has a decent metrics library, where you can
query the state of the VM, that doesn't constantly leak memory, that plays
nicely with databases that have real constraints, that has fewer race
conditions in common libraries, etc etc etc.

~~~
jes5199
and by the way, I can't recommend Node either. As far as I can tell, they're
eagerly making these same mistakes.

~~~
tlack
Node is no panacea, but that's not quite true about stable APIs. npm is great
about maintaining separately versioned libraries and reducing conflicts.

In your package.json can specify what version of a library to use and npm
mostly figures it out for you. For instance, I'm still intentionally using an
older version of Express (2.5.9 instead of 3.0.x) and npm hasn't had a problem
figuring out deps.

Part of the reason this works is that the npms you install are kept in the
local folder, not stored globally as many other package managers do, so some
other random app on you box won't trample your delicate library configuration.

~~~
jes5199
sure, but, if you chose to upgrade to Express 3.0.0, would your application
still work? or are all the method signatures in Express 3 different from
Express 2.5 ?

~~~
deafbybeheading
And (as you note above), is 2.5 still getting critical bug fixes? There's a
thin line between stable and stagnant.

------
jashkenas
To pour a little cool water on this bombastic post -- I have much love and
respect for Rails. We (NYT Interactive News) continue to use it for nearly
everything we build that requires a server-side component.

All I was trying to say (in a direct reply to Jeff) was that I think that
putting Rails on hold for 2-3 years while merging in Merb (or the Merb team,
depending on how you want to look at it) wasn't, in retrospect, a wise
decision.

But that's old news, and doesn't need to be re-hashed now -- it's great to see
Rails 4 starting to pick the pace back up, and exploring new features like
improved streaming, granular cacheing, built-in queues, and more.

~~~
dasil003
I don't understand why you think Rails was on hold for all that time and that
the modularity is not worth it. Yes it was a tremendous refactoring effort
that took a lot of cycles, but Rails 3 has come out with great features.

I mean arel, unobtrusive js, bundler, routing API, and actionmailer overhaul
just in 3.0. The asset pipeline, full engine support, modularity benefits such
as pluggable ORMs and log subscribers. I find all this stuff to offer huge
practical benefits on the ground.

For me the pain of Rails is mostly just the pain of Ruby—ie. it's slow, and
concurrency is not really part of the DNA yet.

What are the killer features that Rails has neglected and caused it fall
behind in your view?

~~~
knowtheory
It is worth pointing out that you're talking to the dude who wrote Jammit. The
asset pipeline was not an innovation in or by Rails3.

~~~
wycats
The idea of asset packaging, of course, is not innovative. Jeremy's original
claim was that Rails was put on hold. Integrating an asset pipeline solution
into Rails took time and commits, and providing an ecosystem-wide solution for
something like this has a strong impact on the overall productivity of the
ecosystem.

------
andrewvc
This is a classic problem among engineers. The notion of bloat and cruft that
goes unsubstantiated, and is really code for 'new and shiny'.

Older software projects offer more features, but that doesn't mean they're
materially slower or worse in any objective way.

We use Rails at Pose to deliver JSON to over 1M users on either Android,
iPhone, or our Backbone Web UI. It works well, it scales, and it's clean. No
complaints.

~~~
nateberkopec
Yeah. Just read the top comment (as I write this): "You don't need all the
ceremony and structure of Rails and MVC."

I think the problem with this outlook is that you don't need it...until you,
you know, need it. Rails has a _lot_ of niceties that you lose with Sinatra.
Why not start from a superlight Rails app (using any of the many gems or
ActionController::Metal options) and then add on bits and pieces when you need
one? I think that this method is either just too difficult for some people to
wrap their heads around or it offends their sensibilities as a programmer.

I've had too many personal Sinatra projects that have bogged down when I
started reimplenting Railslike functionality.

~~~
dasil003
For me personally it's because Rails is so fucking slow these days. That's it,
I don't mind having all that structure and ceremony sitting there. It doesn't
stop me from architecting things however I please in lib/ and app/models/. But
when it takes seconds for a brand new app to run `rake -T` it forces me to
look for speedier alternatives. Speed will probably be what ultimately pushes
me off Ruby as my bread and butter for good some day.

~~~
jeltz
Do not blame ruby for the failings of rails.

Personally I have never had any problems with speed when developing large
projects with Ramaze, Sinatra or Padrino. In my experience this only happens
to Rails. No clue why though. Maybe some gems used by Rails take too long to
load.

~~~
dasil003
Ah but if Ruby were faster Rails would be faster. Whether it's possible to do
less and be acceptably fast is besides the point, I like Rails.

------
timsally
> _Edit: Contrary to what I said here, José Valim is not stepping down from
> Rails core, he is merely on sabbatical. My bad._

And then later in the article...

> _Jose Valim, (now former) Rails core member,_

When you have to issue a retraction, you should update the article. The way
the _Times_ does it is to make the edit and then put a small note at the end
of the article recording the original error. Like so:
[http://well.blogs.nytimes.com/2012/09/10/early-music-
lessons...](http://well.blogs.nytimes.com/2012/09/10/early-music-lessons-have-
longtime-benefits/?src=me&ref=general).

~~~
regularfry
Either way is valid. This way, you don't change the text you originally wrote,
which some might view as more honest, and in addition the reader is warned in
advance that there's an inaccuracy. As long as they can't come away with the
wrong impression, the update's good.

------
dscrd
Having developed software on both Rails and Django, I prefer the latter.
Reasoning: python's community seems more professional. They have well-defined
language change and enhancement processes (the PEP), good docs online, almost
every question imaginable has been answered already somewhere, and the
performance ain't too bad.

Plus the code smell overall is just... lesser.

Then again, I came from a background of C and scheme, and somebody on c2 wrote
that python appeals to people like me more.

~~~
bascule
Last I checked out Django they had just added a bunch of features from Rails
1.2. (Edit: sorry, Rails 2.1)

Python suffers from their web framework community being too fragmented, so
none of the projects are as mature as Rails.

~~~
hekker
I use Django for my projects and I don't share this opinion on the maturity
aspect. Can you explain your statement a bit more? What aspects of Django are
immature?

~~~
bascule
The release notes for Django 1.4, for example, list support for both Time
Zones and Selenium.

Time Zones were added to Rails 2.1 in 2008. selenium-on-rails also debuted in
2008.

Does it not seem strange to you that it took 4 years after Rails for Django to
get these features?

~~~
dscrd
Really, if you wanna complain about something that's in Rails and not in
Django properly, talk about database migrations.

~~~
hackerboos
South...but I agree that database migrations should be part of the Django
core.

------
endlessvoid94
No other programming community on the planet cares so much about how they're
perceived.

I suspect there's a silent majority...

~~~
nwienert
Any new and active programming community _should_ be vocal, and node is no
different. In fact, both node and rails have very loud supporters and
detractors (IE, you).

~~~
rbanffy
I don't think loud people contribute to the health of a community. In fact, I
consider it a "community-smell" - when there is too much incentive to be a
"rockstar", too many people will focus on being rockstars and not enough will
be focus on actually getting the job done.

~~~
jebblue
Right, totally agree, in the Enterprise Java world (love Java, can't stand the
enterprise connotation) things ran a muck and we ended up with J2EE. Spring
isn't better only different. Too loud voices in any camp just mess things up,
then they move on and we are left to sort things out.

~~~
bloodredsun
When it came out, Spring was massively different from J2EE. "J2EE Development
without EJB" was mindblowing for the Enterprise community back in 2004

------
adamkittelson
As far as using websockets with Rails goes, I just wanted to mention that I've
been having a really good experience using the websocket-rails gem
(<https://github.com/DanKnox/websocket-rails>) in a text game (MUD) I'm
working on as a Rails 3 app.

~~~
tomjakubowski
That sounds amazing! When you've got this MUD on Rails going, please do submit
it here. Similarly, I'm working on a MCaaS (MUD Client as a Service ;]) half
tongue-in-cheek to learn more about Node. There's no feeling like using new &
exciting tech to solve the problems of our neckbearded forefathers.

~~~
adamkittelson
That sounds cool too, have a demo up anywhere? I'm kinda doing a deploy as I
code thing, I've added the url to my profile.

------
ZoFreX
I agree a lot with this but it contains its own absolutely huge non-sequitur:
How on earth is Cramp an example of damn simple websockets in Rails? It's
Ruby, not Rails.

It's also probably worth mentioning that it literally only works with Thin, is
unmaintained, largely undocumented, and that the latest master on GitHub
doesn't actually work. Not really the best example to pick!

~~~
bascule
Cramp is based on Rack, just like Rails... there is nothing stopping you from
using the two in conjunction.

~~~
ZoFreX
Well, no. But if someone said "CodeIgniter sucks" and the counter-argument was
"No it doesn't, there's this great framework called Symphony" you'd probably
take issue with that, no?

------
samd
_"Modern HTML5/JS apps depend on beautiful, consistent RESTful JSON APIs."_

 _"Rails is great for JSON APIs."_

 _"Many of these companies have client-heavy HTML5/JS applications which
consume a JSON API coming out of Rails. Many of them have APIs that are
routinely cited as archetypical RESTful JSON APIs."_

Rails is great for JSON RPC over HTTP. It's not great for beautiful,
consistent RESTful APIs. It still lacks basic support for hypermedia. Without
hypermedia you aren't being RESTful and you aren't reaping the benefits of
being RESTful. All you have is a weak convention for doing RPC with HTTP
methods.

None of those companies are examples of REST either, they're all doing JSON
RPC, and propping them up as RESTful does a disservice to REST and a
disservice to Rails. How can Rails make progress towards hypermedia APIs if
people won't even acknowledge that it's lacking?

I know people like Steve Klabnik are valiantly trying to get Rails to adopt
hypermedia, but it isn't there yet, and there are significant technical and
political barriers to overcome.

Node.js frameworks, being in their relative infancy, aren't burdened with the
same barriers as Rails and have the opportunity to move faster than Rails
could. No framework has dominated the Node.js community like Rails dominates
the Ruby community; there's still the opportunity for a Node.js framework for
building hypermedia APIs to take center stage.

~~~
AffableSpatula
there's a gem called roar that's been around for a while for producing
hypermedia in ruby. there's also a roar-rails gem specifically for integration
with rails.

------
j_s
_> Meanwhile, Node.js is the new hotness, and many in the Node community have
sought to build Node up by bringing Ruby and Rails down._

And this post attempts to return the favor?

 _> Node is three years old now. Where are the Node.js success stories? Who's
built a brand on top of Node? _

_> Meanwhile code quality is de-emphasized and large Node programs degrade
into incomprehensible, byzantine structures of callbacks and flow-control
libraries _

Edit: added examples. The whole post is as much an attack on Node as it is a
defense of Rails.

------
f4stjack
Biggest gripe I had with rails is its learning curve. I have started to read
Michael Hartl's impressive tutorial book but gave up when I started to deal
with errors related to gemfile dependencies (if the versions do not match with
the tutorial the expected outcome does not happen at best or you deal with
errors at worst). I have bought Agile Web Development with Rails and thinking
to start again because it is really new and I don't believe I'll encounter any
problems. What do you do when you encounter such errors by the way?

~~~
JonnieCache
Run `git blame` on the code pathway that's throwing the exception (in the
gem.) Look at the changes that have occurred on it and either move back to a
version of the gem that works, or change my code to suit the new version.

Alternatively, look at the changelog or just manually decrement the version
number until my tests pass, obviously taking care not to move back past any
critical security updates.

Also, the precise version numbers used in railstutorial are available in the
code listings here:
[https://github.com/railstutorial/sample_app_2nd_ed/blob/mast...](https://github.com/railstutorial/sample_app_2nd_ed/blob/master/Gemfile)

The (fast paced|aglie|slapdash) nature of the rails ecosystem does necessitate
a certain degree of attention to detail when it comes to versioning. However
this applies equally to sinatra. It's worse with node.

~~~
f4stjack
Thank you. Far as I understood there is no easy way to handle those errors.
I'll take your comment into consideration when I start to learn it.

~~~
JonnieCache
Use the source, luke!

~~~
f4stjack
but I shouldn't get cocky, eh? :)

~~~
JonnieCache
In case it wasn't clear, that aphorism is supposed to be telling you to get
into the habit of reading the source code of the libraries you use. It is
often the fastest way to solve your problems, and you'll learn a lot about the
lib and about the language in the process.

Without the ability to do this one can only be a plumber fitting other
peoples' appliances.

~~~
rjbond3rd
Han Solo says, "Don't get cocky, kid," to Luke.

------
mtkd
"Rails is great for JSON APIs"

Rails is good for simple APIs (especially adding an API to an existing HTML
site).

However, if you want to do more than that, elegantly - it isn't great yet. You
quickly end up with some fairly messy serialization hacks and confusion
between what should sit in the controller and the model.

The active_model_serializers gem is a really good start, but there is a way to
go to get to the level of convention the rest of Rails provides.

Soon it will be great I have no doubt and the convention/stability of Rails
will lead a lot of businesses to start using it.

~~~
nateberkopec
Why not use a format-specific DSL, like DHH does with jbuilder?

That's not messy at all, it's basically just another TemplateHandler.

~~~
codenerdz
Or RABL if you want both XML and JSON output

~~~
joedoe55555
Or XSLT if you want both Oracle and IIS at the same time

~~~
nateberkopec
That sounds horrible.

------
dcu
For me, the biggest problem with rails is that it boots really slow on
development so it's really boring. I switched to padrino a while ago due to
this issue. Also I prefer padrino's router since it's more explicit.

~~~
bryanlarsen
Seriously? How often do you need to reboot Rails? In dev mode it reloads code
as it's changed, so pretty much the only time you need to reboot Rails is when
you change the configuration or update your gems. Maybe once a week, say. The
startup time is a couple of seconds, so you switched frameworks to save a
couple seconds a week. Hardcore.

~~~
dcu
heh. running specs requires to boot rails, starting the console, switching
branchs, reviewing code, etc...

rails boots fast if you have few files but when the project is big it is a
pain, it takes a lot of time to boot and it's not fun. That's why the article
says rails is "a day job".

I just hope the rails team don't think like you.

~~~
mrinterweb
You don't need to restart the rails app when running specs if you use spork.
Also ruby 1.9.3 vastly improved rails application boot times over 1.9.2, just
in case your slow experience was with 1.9.1.x - 1.9.2.x.

~~~
wpietri
Spork's a fine notion, but it's no panacea. Pretty regularly we would be
running down some weird bug only to discover that we had to restart. It
doesn't take a lot of 10-minute debugging excursions to eat up all the time
that Spork saves on starting tests.

------
keeran
6 month old flame bait dug up and reaired as more flame bait.

------
macariomijael
I feel I've been struggling with Rails for a while now, at the time I've got
excited about the promise Merb brought, but the merge hasn't noticeable
changed the way I work. Mountable engines seems like a big hack to me and I
some times struggle with class reloading in development because of it. Sinatra
got mountable apps from the beggining because of being closer to rack, one
could just us rack mount to inclue another app. I worked for a while on a big
Sinatra app and it was a pleasant experience allthough Sinatra provides too
little, but latelly I started a personal project on Padrino and a found a joy
I havent felt in a wile using the languaje and tools I learned to love,
Padrino is like I've allways wanted Rails. I am gratefull of what Rails has
taught me, but I want to get off the bandwagon, Rails has grown to big and
complex for my taste.

------
nateberkopec
Jose Valim heard about people avoiding Rails thanks to it not having a
Sinatra-like routing syntax, and he just decided to code one up:

<https://gist.github.com/3717973>

------
marknutter
> Meanwhile, Node.js is the new hotness, and many in the Node community have
> sought to build Node up by bringing Ruby and Rails down

This is exactly what the Rails community did to PHP when Rails was the new
hotness.

~~~
dasil003
Java is the better analogy. Rails is now a mature enterprise-worthy framework,
but it suffers in some basic areas that Node handles well despite a relative
lack of maturity.

~~~
marknutter
> Java is the better analogy

Agreed, good catch.

------
rbanffy
Shouldn't this be listed on <http://rubydramas.com/>? Name-calling, platform
bashing... Why can't we just get along?

~~~
yxhuvud
It is a response to item #6 on that list, so it is already included.

~~~
rbanffy
I think this much drama on HN deserves its own entry, as well as a day counter
reset.

------
paulbjensen
I read this article a few weeks ago as a result of Tony writing "debunking the
Node.js gish gallop" in response to my "Rails, Node, and the web apps of
today" blog post.

I have a response coming in the next week/2 weeks, so I won't go into much
here, but I will say that Tony's efforts to defend Rails are admirable;
despite some snarkiness and elements of being reactionary, he raises good
points in his posts.

One quick question. Tony, what are your thoughts on Elixir?

~~~
bascule
I'm friends with Jose and quit developing my language Reia because I thought
Elixir was better. I've since gone on to develop Celluloid and haven't looked
back ;)

------
aneth4
I use Rails for most projects. It has its warts and there are many things I
dislike about it. I also like node, but after experiencing the sad state of
nearly ever node module I tried, I came to the conclusion that the ecosystem
is just not there yet. If you want to start from scratch, node may be the way
to go. If you like leveraging existing code, node can be hell.

------
garyadamshannon
Thankyou for this!

------
gosub
2013 is the year of rails on multicore.

