Why critics of Rails have it all wrong (and Ruby's bright multicore future)

http://www.unlimitednovelty.com/2012/03/why-critics-of-rails-have-it-all-wrong.html

by saurabh • 14 years ago

189 125 14 years ago

unlimitednovelty.com

endlessvoid94• 14 years ago

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

I suspect there's a silent majority...

nwienert2• 14 years ago

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).

rbanffy3• 14 years ago

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.

andrewvc• 14 years ago

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.

nateberkopec6• 14 years ago

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.

jeltz7• 14 years ago

To solve this problem is why Padrino was created. Padrino is a collection of "Railslike" functionality for Sinatra. So either start with a Sinatra project and then pick stuff from Padrino or start with Padrino in the first place. Padrino is highly modular.

dasil0035• 14 years ago

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.

slurgfest• 14 years ago

I have no complaints about Rails.

What you said about bloat and cruft is partly true. But there are other things which sometimes substantiate it - boilerplate and cognitive overhead, for example; sometimes older things have more of these than necessary, and are kept anyway because of their maturity and usefulness (and because a community has already developed which fit its brain to the project and has memorized the quirks already).

That is a good reason to keep the old thing, but it does not mean that the older thing is always optimal or even better than a newer thing.

programminggeek2• 14 years ago

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++.

jeltz7• 14 years ago

Agreed, when you want to build an API use Sinatra, and when you want to do web MVC there is Padrino which turns Sinatra into a very competent MVC framework.

planetmcd• 14 years ago

I really enjoy Sinatra and am indeed using it for REST style API hosting, but the counter argument might be all the security stuff that is built into the Rails routes/controllers. this might be a great case for a stripped down rails app as opposed to a Sinatra app.

damncabbage• 14 years ago

I've used Padrino for a couple of projects now, but unfortunately it slips into "Uncanny Valley Rails" territory (particularly when it comes to the rake tasks you expect to have but turn out to be missing, eg. db:test:prepare).

nateberkopec6• 14 years ago

FTA: https://gist.github.com/1942658

Why wouldn't you just do a 50-line Rails app instead, and slot in any other Rails niceties when you feel like you need them?

cheald6• 14 years ago

"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.

jallmann2• 14 years ago

Sinatra has a lot less boilerplate than the typical Rack app.

programminggeek2• 14 years ago

You're absolutely right, you don't need Sinatra to write a JSON API either. The more ruby devs that realize this the better. Really, just people getting out of the mindset that Rails is the be all end all of ruby is all I'm going for.

joedoe555553• 14 years ago

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.

ajsharp• 14 years ago

Whole-heartedly disagree. You can't even parse a json-encoded POST body with plain-vanilla Rack without a middleware from rack-contrib HEAD (the "stable" version is about a year behind the last time I checked). Rack is a standard and abstraction for build ruby app servers and frameworks. To say it's sufficient for building production quality API's is just absurd.

One of the main benefits of using frameworks like Sinatra and Rails is that you often don't need to re-write and re-implement all the same boilerplate code (like parsing JSON post bodies) over and over again.

And the difference with rails and sinatra vs most other open source projects is the size and activity community, and as a result, the overall stability of those projects.

So, in theory, do you need all that "ceremony and structure"? No, but I can't think of a good reason why you'd go implement all that stuff yourself.

krichman2• 14 years ago

I get what you are saying, but I feel reducto ad absurdum is unfair here. I understood the parent's point as this; using Sinatra to give yourself the convenience of the {get,post,...} methods for working with HTTP vs. Rails, which forces upon you its more opinionated structure for websites.

I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choose as they wish, and Rails might be the more appropriate library is some cases regardless of preference (like in the sibling post about teams).

But there's a ton of utility on the spectrum from Rack to Rails and it's perfectly reasonable to choose a midpoint, and perfectly reasonable to choose it because you think Rails is too much but Rack is not enough.

nahname• 14 years ago

I really liked using Sinatra until I used it with a team. The lack of ceremony and structure (as you put it) killed us. The app started out as just a simple service, so why not use Sinatra right? Then things changed and we were more focused on the web side, but stuck with Sinatra because everyone had heard the FUD about rails.

Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it.

This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.

joedoe555553• 14 years ago

My experience is similar. Sinatra is great for one-man-shows or really simple REST apis. For the rest, forget about it...

However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing.

I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable.

But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized.

Great when building but it sucks when debugging and maintaining.

heretohelp• 14 years ago

I agree that the total lack of structure in Sinatra can be harmful at times, but don't blame a technology for your team problems.

That's just the bad workman blaming his tools for the faults of the toolbags he works with.

1gor• 14 years ago

Padrino (www.padrinorb.com) is a sinatra-based 'rails without the bloat' framework.

It provides generators, basic helpers (link_to etc.) and, most importantly, it gives project a sane structure. Oh, and it does not tie you to any fixed set of components. Using Padrino and Sequel is a bliss!

But your app remains a sinatra app, small and elegant. Also, the documentation is excellent.

sirfried• 14 years ago

yeah what can be wrong about a framework imposing design & coding discipline on sheeple :P

jmonegro• 14 years ago

https://github.com/spastorino/rails-api

Problem solved.

sunkencity• 14 years ago

Cheez, the reason to not use Sinatra for me is that I'd have to implement all the security measures myself. Sure for a hobby project or a really simple project it might be OK. I guess it all depends on what budget you have for spending time re-implementing all the plumbing.

mtkd• 14 years ago

"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.

nateberkopec6• 14 years ago

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

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

codenerdz2• 14 years ago

Or RABL if you want both XML and JSON output

cheald6• 14 years ago

Use decorators. Draper is my personal favorite, and it very cleanly solves the issue of serialization nightmares and controller/model confusion.

(I hope that it ends up in the Rails core someday, because it really is a gamechanger in how Rails is used for non-HTML content!)

VeejayRampay• 14 years ago

Agreed, Draper + Jbuilder and you got yourself plenty of decoupling and beauty.

randomdata• 14 years ago

I do agree that the way to provide APIs has been poorly conveyed by the core members. All of the samples end up amounting to:

  render :xml => @objects

Which, naturally, falls apart quickly beyond the most basic serialization. However, as long as you treat the API like any other view (even HTML is just another API format), then Rails does a pretty decent job.

timsally• 14 years ago

> 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....

regularfry• 14 years ago

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.

j_s• 14 years ago

> 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.

ZoFreX2• 14 years ago

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!

nwienert2• 14 years ago

There's also faye with faye-rails

https://github.com/faye/faye

http://faye-rails.sociable.co.nz/

https://github.com/jamesotron/faye-rails

bascule6• 14 years ago

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

ZoFreX2• 14 years ago

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?

adamkittelson2• 14 years ago

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.

nateberkopec6• 14 years ago

A Rails-powered MUD? You're doing God's work, son.

tomjakubowski• 14 years ago

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.

adamkittelson2• 14 years ago

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.

garyadamshannon• 14 years ago

Thankyou for this!

dcu4• 14 years ago

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

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.

dcu4• 14 years ago

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.

mfkp• 14 years ago

You should check out Zeus (https://github.com/burke/zeus). "Boot any rails app in under a second". It'll use more memory, unless you want to GC-patch your ruby (instructions in the repo).

dcu4• 14 years ago

yeah already saw it, but why are these hacks needed in first place? I am pretty sure there's a good way to fix rails to load faster in a reasonable amount of time (again, I am talking about big projects).

jashkenas• 14 years ago

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.

cageface• 14 years ago

I said exactly the same thing at the time. The Merb merge felt like it had a lot more to do with politics and ego than engineering. Unfortunately two years is a long time in this world.

bascule6• 14 years ago

> But that's old news, and doesn't need to be re-hashed now

Well gee Jeremy, thanks for rehashing it then! ;)

I work on a legacy Rails 2.x app at my day job. Wading through the alias_method_chain soup is not fun. I for one am glad the time was spent to eliminate the technical debt that came from too much feature push in earlier versions of Rails and an underemphasis on code quality. They now have a great foundation on which to add future features (which is more or less what you're saying at the end)

mnicole• 14 years ago

I just want to chime in and say that you guys at NYT Interactive always inspire/blow-my-mind. Thank you for doing dataviz right.

dasil0035• 14 years ago

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

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.

wycats2• 14 years ago

Jeremy, I think you know better, but you find this argument too convenient to give up. We did not "put Rails on hold". You could just look at the commit logs, but let me be more explicit.

* December 23, 2008: Merge announced

* March 15, 2009: Rails 2.3 released

* June 25, 2009: Rails XSS protection plugin for Rails 2.3 is released

* July 20, 2009: Rails 2.3.3 is released

* July 29, 2009: The first version of bundler (0.3.0) is released

* February 3, 2010: Bundler 0.9.0, the first "modern" version of Bundler, is released with support for Rails 2.3.5

* February 4, 2010: The first Rails 3.0 beta is released

* May 22, 2010: Rails 2.3.6 is released

* June 8, 2010: The first beta of Bunder 1.0 is released

* July 26, 2010: The first Rails 3.0 RC is released

* August 29, 2010: Bundler 1.0 is released

* August 29, 2010: The first Rails 3.0 final is released

As you can see, activity in Rails hardly ground to a halt during the time period we were working on Rails 3. We didn't even ship Rails 2.3 until three months after the merge, and continued active development for some time thereafter. And during this time, we backported two major new Rails 3 features, Bundler and Rails XSS, to Rails 2.3, actively releasing new versions of Rails 2.3 to take advantage of these backports.

Further, Rails 3 itself was a MAJOR feature release. Saying that Rails was "put on hold" for 2-3 (?!) years to merge in the Merb team is like claiming that Obama is going on an international apology tour. See below for a summarized list of important features.

I won't even talk about the improvements in Rails 3.1 or 3.2, which were possible because of the firmer footing we put the entire project as part of Rails 3 development. And this analysis doesn't even cover the major ways that the project structure changed during that time (full embrace of GitHub, significant increase in long-term contributors, acceleration of the guides project and other improvements to documentation).

---

Rails 2.3 was a major Rails release, with the following features:

* Completion of the Rack integration work begun earlier in the Rails 2.3 series

* Full integration of the Engines feature that was first softly integrated in Rails 2.2

* Localized views

* Support for public HTTP caching

* Ruby 1.9 support

* Nested Attributes (in both ActiveRecord and ActionView)

* Nested Transactions, even in MySQL

* A whole slew of other significant ActiveRecord improvements (http://guides.rubyonrails.org/2_3_release_notes.html#active-...)

* Unified rendering (render :foo, render "foo", etc.)

* HTTP Digest Auth

* Various performance improvements

* Rails application templates

* A whole lot else, see http://guides.rubyonrails.org/2_3_release_notes.html

---

Rails 3.0.0 was a major Rails release. Here are a few of the important features, but summarizing them all would be difficult:

* Incorporated direct support for Bundler, and drove the initial Bundler feature-set.

* Many architectural improvements, which drove improved, more stable third-party libraries in the Rails 3.x era (http://guides.rubyonrails.org/3_0_release_notes.html#rails-a...)

* A much bigger emphasis on eating our dog food: Rails 3 internals use exposed public APIs that any third-party extension can use. In fact, ActiveRecord itself is built as an extension!

* TMail, used by Rails 2.3, was unmaintained and extremely buggy (it often crashed when reading mail). The `mail` gem, written from Rails 3, is a ground-up rewrite.

* The ActiveRecord query interface is a night-and-day difference from the Rails 2.3 query interface. Users of ActiveRecord can now mix and match query parts (where clauses, group, order, limit) without having to worry about how to describe everything in terms of a single hash. This is probably the biggest change to the way developers use a major Rails component since the embrace of REST in Rails 1.2.

* ActionMailer finally got the update it needed. By Rails 2.3, ActionMailer had become a red-headed stepchild, sharing many features of the mainline render system on an ad-hoc basis. That meant inconsistencies galore. In Rails 3.0, ActionMailer got updated to share code and interface with ActionController, locking the two together to avoid another redheaded stepchild problem.

* Large improvements to Internationalization.

* ActiveModel makes it possible to use parts of ActiveRecord without using its SQL persistence layer. Apps have used this to spruce up plain Ruby objects, and libraries like Mongoid have used this to make alternate persistence libraries feel like the ActiveRecord people know and love.

* The router was completely rewritten, adding commonly requested features like the ability to match on any element of the request (commonly used for subdomain matching) and optional segments.

* The new ActiveRecord, ActionMailer and Router APIs maintained backwards compatibility with the older APIs until Rails 3.1 or 3.2, making upgrading plausible for more people.

---

Rails 2.3.3 was a minor update, with the following features:

* `touch` in ActiveRecord, to update a record's timestamp manually or automatically when associated records change

* Improved support for legacy schemas in ActiveRecord

* A general-purpose JSON encoding API and support for the `json` and `yajl` backends

* Other features: http://weblog.rubyonrails.org/2009/7/20/rails-2-3-3-touching...

Rails 2.3.6 through 2.3.9 (The Bridge to 3.0) was a significant update, with the following features:

* Direct support for the Rails XSS plugin

* Support for permanent and signed cookies

* Support for table-name-prefixes for all ActiveRecord classes in a module

* Lots of 3.0 ActiveSupport backports and improvements

* Improved support for Ruby 1.9

* See more at http://weblog.rubyonrails.org/2010/5/22/ruby-on-rails-2-3-6-...

charlysisto• 14 years ago

I may be wrong but I can't help seeing a little anti-Katz bias there.

Beyond this 'cheap' psychological interpretation, I think the merb merge was mainly paying the huge technical debt 'young rails' contracted in its fast growth.

Rails 3 set the ground for the future. All big project go through this teenage phase, and if Rails 4 has so much potential today is because the 'alias_method_chain' and other quick hacks were cleaned out with well thought architectural principals - even though rack and streaming don't play well...

Oh god and I haven't read the whole post yet...

f4stjack3• 14 years ago

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?

JonnieCache3• 14 years ago

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...

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.

f4stjack3• 14 years ago

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.

mhartl• 14 years ago

The Rails Tutorial is at least as up-to-date as Agile Web Development with Rails. For example, two weeks ago I bumped the version of RSpec used in the tutorial, fixing a few minor bugs in the process. Just be sure to use the online version at http://railstutorial.org/book or the most recent ebook from http://railstutorial.org/ so that you get the freshest copy.

If you use the Gemfile at http://railstutorial.org/gemfile in a clean Ruby environment and run bundle install, the issue of dependencies shouldn't even come up. If you continue to have trouble, drop me a line at admin@railstutorial.org.

dscrd2• 14 years ago

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.

slig• 14 years ago

Also, the Django docs is awesome. Nothing gets into master without proper documentation.

bascule6• 14 years ago

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

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?

squidsoup• 14 years ago

Having moved from rails to django development the thing I am missing the most is the wide range of mature testing tools in the ruby ecosystem. Django's testing tools feel very primitive comparatively and there's no clear separation of unit, functional and integration tests. I'd agree that in general the python community feels more professional and that the quality of documentation is typically better.

samd• 14 years ago

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

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.

keeran• 14 years ago

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

marknutter2• 14 years ago

> 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.

dasil0035• 14 years ago

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.

marknutter2• 14 years ago

> Java is the better analogy

Agreed, good catch.

jes51993• 14 years ago

(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.

jes51993• 14 years ago

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

tlack• 14 years ago

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.

bithive123• 14 years ago

This is sadly too true. We have over a dozen Rails apps that need indefinite maintenance and we end up specifying explicit gem versions and/or burning lots of time just staying current. Still, it's better than everyone doing their projects in ad-hoc PHP.

tluyben2• 14 years ago

I do understand the need to refactor and clean up code, however, there is a lot to say for at least deprecating things for a very long time as I find the current RoR far too volatile like you say. Unless you are doing prototypes, short lived sites OR have a fulltime team on it all the time (who upgrades to every small increment of every lib and fixes/refactors/tests the entire project), I don't like it so much. I have done and supported RoR projects and it really takes out the initial wins when you sit swearing behind your monitor because even trivial libs (for which, in fact, you already had to resist the urge not to roll your own) stop working after installing the latest and the greatest. Sure, then don't upgrade to the latest; for a lot of things that's not an option (security would be one, needing another feature this new gem has is another) and it should just give you a nudge 'this is deprecated, please fix' warning for the next year+ instead. If you didn't fix it by then, then at least you were warned plenty in advance.

rbanffy3• 14 years ago

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

yxhuvud• 14 years ago

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

rbanffy3• 14 years ago

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

paulbjensen• 14 years ago

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?

bascule6• 14 years ago

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

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.

nateberkopec6• 14 years ago

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

macariomijael• 14 years ago

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.

gosub• 14 years ago

2013 is the year of rails on multicore.

Why critics of Rails have it all wrong (and Ruby's bright multicore future)

Related Stories