27 ms·

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

189 points by saurabh 14y ago

garyadamshannon 14y ago
Thankyou for this!
dcu 14y 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 14y 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.
  - dcu 14y 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.
    - mrinterweb 14y ago
      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 14y ago
        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.
    - jeltz 14y ago
      The boot times is one of the main reasons rails feels like a day job for me. It is there for every rake task, every time I need to generate a migration, every time I need to use the console. All this waiting makes me lose my flow and forget what I was doing.
- mfkp 14y ago
  You should check out Zeus (https://github.com/burke/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).
  - dcu 14y 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).
    - bascule 14y ago
      Extensive work has already gone into improving Rails startup time. If you want to further improve it, try removing railties you aren't using.
jashkenas 14y 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 14y 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.
- bascule 14y 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 14y 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.
- wycats 14y 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-record 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 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-architectural-changes 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-faster-json-bug-fixes/ 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-released/ http://weblog.rubyonrails.org/2010/5/22/ruby-on-rails-2-3-6-...
ascendant 14y ago
I was doing servlets and JSP in the mid 2000's when Rails came on the scene. I remember how Rails was the new hotness and Java was said to be slow, stupid and for idiots. I'll burn some karma to say I'm slightly vindicated watching those same Rails people get beat up by kids drinking the node.js koolaid these days ;)
f4stjack 14y 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?
- JonnieCache 14y 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/master/Gemfile 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.
  - f4stjack 14y 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.
    - JonnieCache 14y ago
      Use the source, luke!
      - f4stjack 14y ago
        but I shouldn't get cocky, eh? :)
endlessvoid94 14y ago
No other programming community on the planet cares so much about how they're perceived. I suspect there's a silent majority...
- nwienert 14y 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).
  - rbanffy 14y 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.
    - jebblue 14y ago
      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 14y ago
        When it came out, Spring was massively different from J2EE. "J2EE Development without EJB" was mindblowing for the Enterprise community back in 2004
andrewvc 14y 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.
- nateberkopec 14y 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.
  - jeltz 14y 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.
  - dasil003 14y 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.
    - 14y ago
programminggeek 14y 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++.
- nahname 14y 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.
  - joedoe55555 14y ago
mtkd 14y 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.
- randomdata 14y 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.
- nateberkopec 14y 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.
  - codenerdz 14y ago
    Or RABL if you want both XML and JSON output
    - joedoe55555 14y ago
      Or XSLT if you want both Oracle and IIS at the same time
      - nateberkopec 14y ago
        That sounds horrible.
- 14y ago
timsally 14y 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-have-longtime-benefits/?src=me&ref=general http://well.blogs.nytimes.com/2012/09/10/early-music-lessons....
- regularfry 14y 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 14y 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.
ZoFreX 14y 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!
- nwienert 14y ago
  There's also faye with faye-rails https://github.com/faye/faye https://github.com/faye/faye http://faye-rails.sociable.co.nz/ http://faye-rails.sociable.co.nz/ https://github.com/jamesotron/faye-rails https://github.com/jamesotron/faye-rails
- bascule 14y ago
  Cramp is based on Rack, just like Rails... there is nothing stopping you from using the two in conjunction.
  - ZoFreX 14y 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?
adamkittelson 14y 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 https://github.com/DanKnox/websocket-rails) in a text game (MUD) I'm working on as a Rails 3 app.
- tomjakubowski 14y 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.
  - adamkittelson 14y 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.
- nateberkopec 14y ago
  A Rails-powered MUD? You're doing God's work, son.
dscrd 14y 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 14y ago
  Also, the Django docs is awesome. Nothing gets into master without proper documentation.
- bascule 14y 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 14y 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?
    - bascule 14y ago
      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 14y ago
        Really, if you wanna complain about something that's in Rails and not in Django properly, talk about database migrations.
samd 14y 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 14y 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 14y ago
6 month old flame bait dug up and reaired as more flame bait.
marknutter 14y 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.
- dasil003 14y 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.
  - marknutter 14y ago
    > Java is the better analogy Agreed, good catch.
jes5199 14y 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.
- jes5199 14y 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 14y 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.
rbanffy 14y ago
Shouldn't this be listed on http://rubydramas.com/ http://rubydramas.com/? Name-calling, platform bashing... Why can't we just get along?
- yxhuvud 14y ago
  It is a response to item #6 on that list, so it is already included.
  - rbanffy 14y ago
    I think this much drama on HN deserves its own entry, as well as a day counter reset.
paulbjensen 14y 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?
- bascule 14y 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 14y 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.
nateberkopec 14y 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 https://gist.github.com/3717973
macariomijael 14y 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 14y ago
2013 is the year of rails on multicore.

189 points by saurabh 14y ago

Thankyou for this!

dcu 14y 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 14y 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.
- dcu 14y 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.
  - mrinterweb 14y ago
    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 14y ago
      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.
  - jeltz 14y ago
    The boot times is one of the main reasons rails feels like a day job for me. It is there for every rake task, every time I need to generate a migration, every time I need to use the console. All this waiting makes me lose my flow and forget what I was doing.
mfkp 14y ago
You should check out Zeus (https://github.com/burke/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).
- dcu 14y 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).
  - bascule 14y ago
    Extensive work has already gone into improving Rails startup time. If you want to further improve it, try removing railties you aren't using.

jashkenas 14y 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 14y 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.
bascule 14y 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 14y 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.
wycats 14y 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-record 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 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-architectural-changes 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-faster-json-bug-fixes/ 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-released/ http://weblog.rubyonrails.org/2010/5/22/ruby-on-rails-2-3-6-...

ascendant 14y ago

I was doing servlets and JSP in the mid 2000's when Rails came on the scene. I remember how Rails was the new hotness and Java was said to be slow, stupid and for idiots. I'll burn some karma to say I'm slightly vindicated watching those same Rails people get beat up by kids drinking the node.js koolaid these days ;)

f4stjack 14y 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?

JonnieCache 14y 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/master/Gemfile 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.
- f4stjack 14y 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.
  - JonnieCache 14y ago
    Use the source, luke!
    - f4stjack 14y ago
      but I shouldn't get cocky, eh? :)

endlessvoid94 14y ago

No other programming community on the planet cares so much about how they're perceived. I suspect there's a silent majority...

nwienert 14y 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).
- rbanffy 14y 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.
  - jebblue 14y ago
    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 14y ago
      When it came out, Spring was massively different from J2EE. "J2EE Development without EJB" was mindblowing for the Enterprise community back in 2004

andrewvc 14y 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.

nateberkopec 14y 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.
- jeltz 14y 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.
- dasil003 14y 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.
  - 14y ago

programminggeek 14y 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++.

nahname 14y 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.
- joedoe55555 14y ago

mtkd 14y 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.

randomdata 14y 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.
nateberkopec 14y 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.
- codenerdz 14y ago
  Or RABL if you want both XML and JSON output
  - joedoe55555 14y ago
    Or XSLT if you want both Oracle and IIS at the same time
    - nateberkopec 14y ago
      That sounds horrible.
14y ago

timsally 14y 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-have-longtime-benefits/?src=me&ref=general http://well.blogs.nytimes.com/2012/09/10/early-music-lessons....

regularfry 14y 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 14y 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.

ZoFreX 14y 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!

nwienert 14y ago
There's also faye with faye-rails https://github.com/faye/faye https://github.com/faye/faye http://faye-rails.sociable.co.nz/ http://faye-rails.sociable.co.nz/ https://github.com/jamesotron/faye-rails https://github.com/jamesotron/faye-rails
bascule 14y ago
Cramp is based on Rack, just like Rails... there is nothing stopping you from using the two in conjunction.
- ZoFreX 14y 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?

adamkittelson 14y 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 https://github.com/DanKnox/websocket-rails) in a text game (MUD) I'm working on as a Rails 3 app.

tomjakubowski 14y 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.
- adamkittelson 14y 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.
nateberkopec 14y ago
A Rails-powered MUD? You're doing God's work, son.

dscrd 14y 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 14y ago
Also, the Django docs is awesome. Nothing gets into master without proper documentation.
bascule 14y 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 14y 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?
  - bascule 14y ago
    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 14y ago
      Really, if you wanna complain about something that's in Rails and not in Django properly, talk about database migrations.

samd 14y 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 14y 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 14y ago

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

marknutter 14y 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.

dasil003 14y 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.
- marknutter 14y ago
  > Java is the better analogy Agreed, good catch.

jes5199 14y 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.

jes5199 14y 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 14y 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.

rbanffy 14y ago

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

yxhuvud 14y ago
It is a response to item #6 on that list, so it is already included.
- rbanffy 14y ago
  I think this much drama on HN deserves its own entry, as well as a day counter reset.

paulbjensen 14y 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?

bascule 14y 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 14y 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.

nateberkopec 14y 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 https://gist.github.com/3717973

macariomijael 14y 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 14y ago

2013 is the year of rails on multicore.