8 ms·

What the hell is happening to rails?

201 points by tswicegood 15y ago

_pius 15y ago
If you want to learn rails, don’t get the latest pragmatic programmers book. Go and get the 1st or 2nd edition. Get an old copy of rails and ignore all this. Worst. Advice. Ever. Once you’ve figured that all out then upgrade and expect to spend the same amount of time learning all the new stuff. You don’t save any time jumping to Rails 3+. This just isn't true.
- nfm 15y ago
  Agreed. Rails has significantly changed since 2.3.x, and is extremely different to 1.2.x. These changes aren't just for the sake of it - Rails keeps on improving! Start at 3.1 and you won't be sorry.
  - tdfx 15y ago
    I started with rails 3 and I haven't had any major hurdles to overcome. I've been very impressed with Rails. I'm coming from a Python/PHP framework background, and so far rails is my favorite (only done a few apps so far, mind you).
- joshuacc 15y ago
  Indeed. As a front-end developer with little back-end experience, I was able to get the basics of Rails with just a few hours working through Hartl's tutorial.
- rohitarondekar 15y ago
  Agreed. I strongly urge the author to change this suggestions because it's a dangerous one. You don't want newcomers learning an older version of Rails and then struggling to upgrade. There are a lot of resources to help you out. The API Docs[1], Official Rails Guides[2] are excellent and Railscasts[3] are also awesome. [1] Rails API Docs http://api.rubyonrails.org http://api.rubyonrails.org [2] Rails Guides http://guides.rubyonrails.org http://guides.rubyonrails.org [3] Railscasts http://railscasts.com http://railscasts.com
- bulletsvshumans 15y ago
  I just picked up rails for the first time this month. My background is primarily in the desktop environment, but using rails 3 has been nothing but a joy so far. Glad I didn't take this guy's advice.
nfm 15y ago
I agree that the barrier for entry to Rails is quite high. To really get into it, you might have to learn: * A new language * A new framework * A new programming paradigm * A new set of libraries This is going to be really hard if you're currently a spaghetti coder. Will you learn a lot? Will you become a better programmer? Will you enjoy coding more? I say yes!
- andrewflnr 15y ago
  Generally, I agree. But a spaghetti coder is going to have trouble no matter where they go. For such a person, moving to a new framework might not actually result in much valuable learning. If they were open to that, would they still be a spaghetti coder?
- crag 15y ago
  You rails guys think you're the only game in town. A spaghetti coder is gonna have issues regardless of the language/framework. Also the barrier to any framework in any language is the same.
ethyreal 15y ago
i found the ever changing world of rails intimidating when i first started and that was in the wonderful world of 1 moving to 2 but at the end of the day all you really need is to get the same version of rails that your book/tutorial covers and stick with it..
jmtame 15y ago
The assets pipeline feels horrible, it's really slow. I upgraded to Rails 3.1rc, realized it fights with Heroku unless upgrading to the Cedar stack. Lesson learned: stay away from Rails release candidates. But I downgraded to Rails 3.0.8 because 3.1 was just more of a hassle starting out. Maybe I'm doing something wrong, usually when I'm fighting the framework it's a sign that I don't fully understand something. I loved Rails 3.0 when it was announced, but I share the same sentiment as the OP re: 3.1 at the moment.
- joevandyk 15y ago
  None of the heroku stacks support mysql.
  - jmtame 15y ago
    Right, though I think I was more hesitant on upgrading to Cedar--probably could have done that without any problems, but ultimately I just didn't like 3.1rc. My major gripe was with the assets pipeline. Edit: are images not supposed to be served through /assets? They were loading too slowly for me, that was my major complaint.
    - joevandyk 15y ago
      No, images are not supposed to be served through /assets. Put them in /public.
      - dhh 15y ago
        rake assets:precompile will automatically copy images from app/assets/images to public/assets. The asset pipeline can be a development concern only, if you want it to.
        huetsch 15y ago
        I love the 3.1 rcs but using 3rd party css files that reference images are kind of painful to deal with in conjunction with the asset pipeline. I find myself making awkward directory structures in the vendor directory to avoid making modifications to 3rd party css libraries (like jQuery UI). I'm hoping a lot of this will go away when those things are packed into gems that I can just put in my Gemfile and forget. I'm sure Compass and Blueprint will get to that point pretty quickly but I'm not sure that something custom-generated like by jQuery UI ThemeRoller will ever be smooth to set up.
bricestacey 15y ago
This sounds like an old person ranting about the good ol' days when it's probably a personal phobia against change. I started learning rails just as 3 was coming out. I had made a site with rails 2 and while googling around for help I found all these tutorials about rails 3 and they definitely made everything much easier. Sure, if I had more time invested in 2 (like this guy?) I'd be peeved, but I'm luckily more aligned with the direction of rails rather than its past.
- nthj 15y ago
  This sounds like an old person ranting about the good ol' days when it's probably a personal phobia against change. Crafting software requires a fine balance between getting stuff done with what you know and losing productivity because you're stuck with older technology. Some of my best decisions as a software craftsman required change. Subversion to Git, PHP to Ruby on Rails, VPN to Heroku, all helped me build great stuff far more effectively. And some of my biggest problems came from attempting to adopt new technology x instead of building something great quickly with what I already knew. I don't have a simple answer for maintaining that balance. It's hard. Being aware of needing that balance is a great first step. Complaining about change, though, seems to be the least productive response. Can I build something great right now? No? OK, can I learn something new right now? No? OK, then some downtime might be my best choice. For right now.
felipemnoa 15y ago
What is happening is that the language/framework continues to grow/mature/(get older). Not sure if that is a good thing. My guess is that as more Use Cases are being implemented a lot of the early simplicity is being lost. As it gets older it starts to accumulate good stuff and bad stuff. Just like any other language. I think most languages go through this. <satire> My guess is that eventually there will be another golden boy and a whole new generation of programmers will swear that it is the best thing since the invention of the wheel while at the same time complaining of all the baggage and bad decisions made in Ruby/Rails and ridiculing anybody that still uses it. Meanwhile the Ruby/Rails developers will look and scratch their heads wondering what all the hate is about. After all, Ruby/Rails gets the job done even if it is not perfect and anybody that is a language fanboy does not have a brain. After all, a programming language is just a tool. A whole generation latter the cycle repeats itself with yet another golden boy language. Sigh! To be young and stupid. Those were the days. </satire>
- wtn 15y ago
  There was another golden boy, it was called Merb. Then their team joined Rails and started refactoring things… Members of the Rails core team recognize that growth has limits. They are looking for ways to reduce the stack to improve the design and make things more performant. See Aaron Patterson's RailsConf 2011 keynote.
tomfakes 15y ago
I've been building a new app with the Rails 3.1 rcs for the last 3 or 4 weeks. I still have no idea how to actually deploy into production in a way that has a chance of working. As far as I can tell, I need the V8 code built on my production boxes! That seems insane, unless I want to switch to using node.js.... On my FreeBSD system, I still have no idea how to get V8 built correctly. I've bailed on it for now and am running my 'production' server with the 'development' environment. Remember, I'm not running beta software, I'm running a 'release candidate'. When this works, it'll probably be great, but stick with 3.0 if you actually want to make progress on your application.
- joevandyk 15y ago
  Put the coffee-script gem into your Gemfile. Assuming you have a compiler on the production box, you're fine.
- nfm 15y ago
  You'll need to add 'therubyracer' (or another javascript interpreter) to your Gemfile. It requires python and a C++ compiler to compile its binaries. If you're on Heroku, you may need 'therubyracer-heroku' instead - there are compilation issues. Hopefully this will be fixed soon.
  - tomfakes 15y ago
    This needs the V8 stuff compiled and installed. And then I'm running yet more code on my production servers to deploy. And this code compiles the CoffeeScript to JS, and this will be the very first place that this code will have actually been tested in this configuration. This deployment scares me a lot -- partly because I haven't yet made it work in an RC build, and mainly because it adds more moving parts to my production servers.
    - rubymaverick 15y ago
      You do not need to use CoffeeScript in Rails 3.1, it is merely the default option. Just delete the "gem 'coffeescript'" line in your Gemfile and just use regular js.
latch 15y ago
I spent the end of last year doing Java/Struts. Felt like time travelling back to 2002. Back when I knew PHP, versions increased, but nothing really changed for years and years (I'd be surprised if it was much different today). The .NET folk will tell you how great ASP.NET MVC is, but they live in their own world - a new view engine doesn't close the gap which exists between it and more progressive MVC frameworks. The point? If you want stagnant frameworks there's plenty to pick. A lot of them aren't easier to learn, but none of them require you to keep learning. This is great because it tends to attract all the programmers you want to avoid into obvious communities.
- nirvdrum 15y ago
  Surely there's some middle ground though, no? At what point do you have a stable core and then you just bolt things on? There's nothing stopping you from using SASS and Coffeescript with Rails 2.3. I skipped the Rails 3 upgrade just simply because I couldn't justify the time sink. rspec made it ridiculously worse with the difference in Rails support between 1.x and 2.x. I'm guessing with Rails 3.1 coming out I'll have to upgrade just because most of the plugins I use have moved on and don't backport bugfixes. It'd be nice to evolve an app without having to constantly wasting time on version compatibility. It's an absolute nightmare if you have any non-trivial-sized app.
  - rohitarondekar 15y ago
    You are not forced to use SASS and Coffeescript. You can just switch them off. You can also switch off the asset pipeline.
    - nirvdrum 15y ago
      That wasn't the argument I was making. My argument was if those are the new technologies you want to play with, you don't need a major new Rails release. Since the opposing argument seems to be that Rails needs to keep breaking compatibility in order to keep up with the latest technologies.
pspeter3 15y ago
I used to be a rails developer. After rails upgraded to 3.1, I switched to Padrino and haven't looked back
- mhartl 15y ago
  I'm confused. Rails 3.0.8 is the current version. Rails 3.1 is still in beta. What's in the beta release of Rails 3.1 that caused you to leave? A couple of defaults have changed, but valid Rails 3.0 applications can be upgraded to 3.1 with a minimum of effort.
  - pspeter3 15y ago
    When I tried the Rails 3.1 beta, I had issues with getting Mongoid and various other dependencies working and could not get it to run. My Rails 3.0 app completely broke. I might be an edge case though.
    - mhartl 15y ago
      I'm preparing a screencast on upgrading the Rails Tutorial sample application from Rails 3.0 to Rails 3.1. Maybe you'll find it useful. Subscribe to the news feed (http://news.railstutorial.org/ http://news.railstutorial.org/) to be notified when it's ready.
    - cannikin 15y ago
      Have the gems for Mongoid and such been "certified" against 3.1? Seems kind of hash to drop the whole framework based on a bad beta experience...wait until an official release and see.
dev_jim 15y ago
I could never wrap my head around the Rails world. I enjoy the elegance and simplicity of Python/Django. There's a lot less 'holy shit magic' moments.
deleted 15y ago
[deleted]
korch 15y ago
IMHO Rails has become the very kind of spaghetti web "muck" it set out to replace 5 years ago. This is my primary reason for switching to Node.js for as much as possible going forward. What ever happened to the original spirit from 2007 of "build a blog in 10 minutes using Rails"? Good luck doing that now in under an hour! I think Rails has drifted very far from the "convention over configuation" mentality. It's inevitable that this happens to any awesome software after you let programmer geeks pile on for 5+ years. Now you'd be lucky to get Bundler working in 10 minutes on your new Rails app. And then you'd have to visit railswizard.org or find an app generator to handle all of the boilerplate configuration choices you'd need just to get the conventional Rails app running. And then you'd have to make a million other choices just to build a blog. Developers are like water, always following the path of least energy, flowing downhill. The moment any software becomes difficult to use, it's dead, as the zeitgeist shifts. Right now Node.js feels very similar to the way Rails felt in 2006-7, where you can sense the growing momentum of a large shift in the developer community.
swampthing 15y ago
I think the author is conflating two issues - (1) learning Rails and (2) keeping up with the latest developments in Rails. I agree with the author that (2) is getting harder - but this is the price you pay for improvement. I disagree that (1) is getting to be overly difficult. By and large, the changes to Rails 3 and Rails 3.1 make it easier for developers to do more advanced things with Rails. If you just look at the simple tutorial applications that newcomers to Rails are starting out with, I don't think their complexity has increased very much from Rails 2 to 3 to 3.1. Yes, they are different from version to version, but this doesn't matter to the newcomer. TL;DR - the framework has more functionality, which makes it more difficult to learn the entire framework, but it is not significantly more difficult to learn how to accomplish any given task.
stretchwithme 15y ago
Over time, Rails changes to make it easier to deal with the complex needs of web applications. Part of that is changing things to make things more orderly, so you can actually find your way around a complex application without too much wasted effort. That places demands on developers, especially when migrating, but makes it easier in the future. The amount of power you can weld in the present is dependent on how much capability you acquired in the past. You can always enter a battle with your bare fists and no learning curve, but if someone gives you a free sword, learning to use it before the battle is more likely to lead to victory. This is not learning for the sake of learning. But even learning for the sake of learning grows your ability to learn.
- jamesbritt 15y ago
  Over time, Rails changes to make it easier to deal with the complex needs of web applications. Why? Why is Rails changing to handle this, instead of add-ons, plug-ins, and gems changing?
  - dhh 15y ago
    Because that's always been the mission. Have a solution for most people, most of the time. With the target being building full-fledged apps ala Basecamp (that touches on all parts of web tech). So we've been pursuing this mission for 7+ years. We've just gotten better at it.
  - stretchwithme 15y ago
    One of new 3.1 features actually makes it easier for you to use external assets like gems and plugins. Instead of downloading downloading code and then moving files to their proper locations, the new asset pipeline lets developers package such assets so bundler can accomplish that for you. You'll just specify what the asset is and what version you want in Gemfile. That's a change that you can't just rely upon some gem to make. It's really the responsibility of the framework. And it creates order, making Rails easier to work with, especially when the app gets complicated. Similar changes have similar rationales and these can be understood by watching videos like this one: http://www.youtube.com/watch?v=cGdCI2HhfAU&list=PL379EA9290474C86C
chrismealy 15y ago
I stay caught up on everything in railsland just by watching Railscasts. I can't deny that it's chaotic right now but I'm enjoying the rapid progress. I like the little things, like js and css moving from public to app. Also, I think the switch from prototype to jQuery will help beginners.
OstiaAntica 15y ago
It feels like Rails is slowly dying. It doesn't have the broad penetration of PHP, and most folks taking up a scripting language today choose Python.
- cantbecool 15y ago
  I disagree. With the proliferation of new tutorial books and screencasts in addition to more and more web developers choosing Rails, it's far from dying, it's actually in growing at rapid rate.
  - ssmoot 15y ago
    Where do you get your numbers for that? I'm genuinely curious. I had the opposite impression; but I don't have any numbers at all to back it up.
    - cantbecool 15y ago
      Just anecdotal evidence. I'm just seeing an increase of job postings online, but after doing research, the term 'Ruby on Rails' is actually declining on Google trends. http://trends.google.com/trends?q=ruby+on+rails&ctab=0&geo=all&date=all http://trends.google.com/trends?q=ruby+on+rails&ctab=0&#... I thought at least there would be a slight bump after Rails 3.0 release, guess not.
- devski 15y ago
  not surprised by python itself, since it is a beast of a language on all fronts (web develpment, cross platform guis, games, scientifc computing, etc etc..), and on all os (windows is a first class citizen, one of the reasons for its massive success). django on the other hand is not there yet, compared to rails.
jrockway 15y ago
Catalyst is the main web framework for Perl, and it's always been of this design. No opinions, craft every little component exactly to your own specifications. No default ORM, no default Javascript helpers, no default form builder, no default templating library. Bring Your Own (or download from CPAN). Back in the day, I remember writing reddit comments and blog posts to explain the relative popularity of Rails over Catalyst. It was usually along the lines of, "people want to be told what to do. given a screw, they would rather bash it in with a hammer than to read about what a screwdriver is." Posts like this reinforce that point: people don't use Rails because they want to use Rails, people use it because they're afraid of anything else. Rails gave them everything that they thought they needed, and no easy way to back out of the defaults. It was a comfortable world where you could never do something wrong. Now that Rails is becoming a meta-framework like Catalyst, people are being driven away because they have to think before they program, and they have to customize Rails into the framework they want instead of just using the framework that dhh wants. You can even see this in the Perl community; people are switching away from Catalyst in favor of mini-frameworks that barely meet their needs, just because they feel like the framework author has thought of everything and they will never write a line of boring code again. If only.
- epochwolf 15y ago
  I think the difference with Rails is it still provides defaults. Out of the box it's a full stack ready to go. Customization is not required.
- sunchild 15y ago
  "people don't use Rails because they want to use Rails, people use it because they're afraid of anything else" Nonsense. Almost doesn't deserve a response, but...people use Rails because they agree with many of the choices made by the framework. Where they don't agree, and are willing to absorb the cost to maintainability, they override the framework.
  - eropple 15y ago
    ...or because they think it's trendy, and don't have the breadth of experience to know if they actually agree with it or not. (Not you, but the legions of people who think they're web developers because they learned RoR and never bother to learn anything else are pretty annoying.)
grandalf 15y ago
I think it's quite telling that DHH frequently tweets his opposition to aspects of what is happening with Rails, and that Yehuda quit the core team. In a world where some time on the core team can land someone $300K per year in salary + speaking + book deals, there is bound to be this sort of chaos. I view the push toward agnosticism as a misguided attempt to be the "one true framework" and also to salve the egos of those whose decisions and work are being undone.
- bradleyland 15y ago
  "I think it's quite telling that DHH frequently tweets his opposition to aspects of what is happening with Rails, and that Yehuda quit the core team." That's a bit disingenuous, isn't it? Yehuda was offered an opportunity that makes sense for him. It's not as if he's abandoned the Rails community in a flurry of drama. DHH is the kind of guy that is going to speak his mind, and if you're wise you'll at least listen to what he has to say. If you find yourself agreeing 100% of the time, it's time to find different company.
  - dasil003 15y ago
    Yeah, did Yehuda quit so much as fade into the background? He's clearly a guy who likes ambitious projects. His contributions to the Ruby community have been notable because of their challenging nature. Merging Merb and Rails was a gargantuan project, getting a large established framework to accept that level of outside input was impressive. The level of refactoring that went into it went against prudence, but I can't argue with the results. Rails 3 is awesome. Similarly Yehuda and Carl spearheaded Bundler development. They bit off a massive problem that touches anyone doing large scale ruby development and through sheer force of will hammered out a powerful solution that solves the majority of common issues in a relatively straightforward manner. There's lots to argue with, for sure, maybe it's over-engineered, maybe they didn't work closely enough with RubyGems core, etc; but at the end of the day they solved a problem that was too hairy for the average dev to have much hope of solving. Yehuda's been there, done that. He doesn't need to stick around and be Rails core forever, there's plenty of new blood to pick up the torch, and bigger problems to solve elsewhere.
- 15y ago
damoncali 15y ago
The problem is not that rails has gotten too difficult to pick up (although, I'd agree it's not as easy as it once was). The problem is the documentation is lagging behind the development - in some cases pretty severely. But what do you do? Slow down? Not sure that's good either.
tomkarlo 15y ago
I do agree that defaulting to have SASS and Coffeescript on unecessarily increases the learning curve for new adopters. Along with HAML they're fantastic technologies but in many cases you're asking people to learn Ruby, Rails, HAML, SASS and/or Coffescript all at once now. Make the base setup as such that it minimizes what they have to learn to achieve some success, and let them turn on technologies such as HAML/SASS/Coffeescript later on once the cognitive load of switching to Ruby and Rails has decreased.
- jshen 15y ago
  I think it's better to turn them on by default. Rails gains enormous benefit from the fact that nearly all rails sites are running the same stack. Try learning spring mvc to see what it's like to give lots of options.
- mhartl 15y ago
  There's some serious FUD going on here. Not only are valid CSS files also valid Sass files, but CSS files in the app/assets/stylesheets directory are served up just fine. There's no need to learn Sass right out of the gate. And Haml isn't even included in the default install, so that's a complete red herring. Finally, JavaScript files in app/assets/javascripts work fine as well; as with Sass, there's no need to learn CoffeeScript right away.
- Volpe 15y ago
  > many cases you're asking people to learn Ruby, Rails, HAML, SASS and/or Coffescript all at once now. As oppose to Ruby, Rails, ERB, CSS, and Javascript? - CSS is valid SASS - Coffeescript is closer to Ruby/Python than javascript and is possibly an easier learning curve (if you don't already know javascript) (You can use javascript if you want as well).
  - tomkarlo 15y ago
    ERB is extremely similar to PHP and regular HTML. CSS and Javascript will already be familiar to someone who has done development in other languages. Call it FUD (despite the fact that I do all my development in Rails) but the issue isn't the reality, it's the perception. You make these the defaults for Rails and/or you write the new user tutorials in them, and you increase the perceived difficulty of starting to use Rails. You make them options that more advanced users can choose to turn on, you reduce that friction. That's all I'm saying. To clarify: I'm pro HAML, SASS/SCSS and I like the idea of Coffeescript even though I'm not using it. I just think that some of the way the've been going with Rails is not great from the perspective of growing the adoption of the platform. And yeah, my mistake about HAML. I've been using it so long with Rails I've forgotten it's not a default.
joelmichael 15y ago
I've been coding in Rails since pre-1.0, and while some decisions have annoyed me, I am ultimately happy with the direction Rails has gone. It keeps Rails at the forefront of web technology.
flocial 15y ago
The problem with Rails is not the pace of change so much as the wild changes of direction it takes, sometimes introducing serious performance degradations into official releases. Sometimes it's hard to see a guiding core philosophy other than the fact they want to be on the shiny edge. It's nice that they aren't stuck with bad design decisions forever but when you go in for an upgrade and you depend on some unpopular plugins, you can bet on pain and even performance problems. A major issue with some parts of the community is that some programmers think that being rubyists automatically makes them elegant programmers even if they don't have a clue about proper algorithms and that's probably why others call them "hipsters". The general disregard for improving performance, inherited from Ruby, is also something endemic from a while back. Sure programmer time is important but how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains. Getting your app into production is also another pain point with the all the dirty tricks you need to master, not to mention an array of lackluster choices be it nginx, passenger, unicorn, rvm, REE, bundler, etc. So with that background, I think the author's gripes are understandable but it really doesn't touch on the undercurrent of discontent surrounding the current ecosystem.
- Volpe 15y ago
  > how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains. So how many? I've hardly heard of this as the 'norm' for growing companies on rails... ? This sounds like 'Does Rails Scale' FUD. Getting your app into production is not a pain point at all, services like heroku, or engineyard have made this as simple as 'git push'. Which nirvana of release management are you coming from where this is a 'pain point' ?
  - gtani 15y ago
    I've heard of a few deployments where the dev environment is MRI/"C-ruby" and production is JRuby.
    - nirvdrum 15y ago
ekidd 15y ago
What's happening to Rails? DHH is adding some new APIs, and he's suggesting new programming guidelines and conventions. This is nothing new. He's been doing this every 6 to 12 months since Rails 0.13 (at least). Here are some of the bigger disruptions: - Rails 1.2: Rewrite all your controllers to use the new REST model. (This was annoying, but the results looked a lot better.) - Rails 2.0: Change from ";" to "/" in standard resource routes, and rewrite controllers to use respond_to. - Rails 3.0: Deal with bundler, ActiveModel, Arel, a total overhaul of ActionMailer, etc., etc. By historical standards, the asset pipeline is a medium-sized change, and certainly much smaller than the Rails 3.0 changes. And unlike the Rails 3.0 changes, you can turn it off in about 2 minutes. Personally, I rather liked most of these new features at the time: They addressed my day-to-day pain, they made my code cleaner, and they helped me keep in sync with other programmers. Rails is optimized for a certain set of opinions, which overlap about 80% with my own, and that's usually good enough for me. If your tastes diverge from DHH's tastes to a greater extent, it won't be as much fun.
localhost3000 15y ago
I don't get it. I found rails 3 exceptionally easy to learn. Sass is a dream. It's what css should have been. Haml has its annoyances but in general is great. Both of these are also exceptionally easy to learn. I love where rails is going.
pdenya 15y ago
My biggest issue with rails was more getting my development environment setup. Constant gem compilation issues, I spent hours resolving them. Aside from that I haven't had much trouble stepping into the language or the new environment.
- getsat 15y ago
  > Constant gem compilation issues, I spent hours resolving them. While this is common, it doesn't really have anything to do with Rails itself. I can't think of any Rails dependencies that have mandatory native extensions off the top of my head.
  - pdenya 15y ago
    My biggest problems were mysql2 (i had mysql installed and setup already from my php dev stack) and bcrypt-ruby (required for devise)
    - getsat 15y ago
      mysql2 is far easier than the original mysql gem. If you want to waste half a day, go try to install the old one. ;) Are you on a Mac, by chance? With XCode/GCC + MacPorts, I've not had many issues with gems. Add to Gemfile, run bundle. Done.
  - jamesgeck0 15y ago
    If you want SQLite, there's that. Not mandatory, but pretty useful. Fortunately there are the jdbc-sqlite3 and activerecord-jdbcsqlite3-adapter gems for Jruby.
    - getsat 15y ago
      Ah, good point, I forgot that Rails defaults to SQLite.
trustfundbaby 15y ago
This seems to be a complaint that Rails is a moving target, and that the target is being moved in absence of a genuine need. ------------------------ I think this is more my problem with the whole thing. The coffeescript thing just bugs me for some reason, it seems a bit like the javascript helper, rjs days and look how those panned out. There's a Joel Spolsky article making fun of the way .NET releases come thick and fast just to keep Microsoft developers constantly worrying about catching up ... I just have this weird feeling that we're becoming the punchline in that joke.
- kristianp 15y ago
  The Spolsky article was about how Microsoft changes the whole framework on you every few years. Which is why there seems to be some uproar about the Windows 8 information not mentioning .net at all.
  - trustfundbaby 15y ago
    The Spolsky article was about how Microsoft changes the whole framework on you every few years ------------- Judge for yourself. http://www.joelonsoftware.com/articles/fog0000000339.html http://www.joelonsoftware.com/articles/fog0000000339.html
stephenhandley 15y ago
lol this is just some pay your dues nonsense. "You will love rails if you begin at the start like we all did" http://pine.fm/LearnToProgram/ http://pine.fm/LearnToProgram/ (probably not relevant for HN) http://ruby.railstutorial.org/ruby-on-rails-tutorial-book http://ruby.railstutorial.org/ruby-on-rails-tutorial-book http://devcenter.heroku.com/articles/quickstart http://devcenter.heroku.com/articles/quickstart
audionerd 15y ago
If you're hesitant to be an early adopter (AKA "guinea pig") Rails 2.3.x is very stable, and most of the useful plugins in the Rails ecosystem are still maintained for Rails 2.3.x. Many big names are still on Rails 2.3.x, too. Forgive me if I go astray here, but GitHub and DocumentCloud are two examples that come to mind.
- dhh 15y ago
  Staying on Rails 2.3.x is certainly fine for existing apps, but starting a new app on 2.3 is a very bad idea. You're setting yourself up for a lot of headache for the inevitable migration. Let alone depriving yourself of all the wonders of Rails 3. That being said, nobody is forcing you to jump on a release candidate. Just use the latest released, stable version. In this case Rails 3.0.x.
mrinterweb 15y ago
I think the big difference between now and when Rails was first starting to gain popularity is that now most of the blogs are primarily covering advanced/obscure topics related to rails. Years ago, most blog posts were about the basics of getting started with rails. Now those old posts no longer apply to the newer version of rails. This is not the fault of rails and it is not the fault of bloggers. There is no shortage of books available to learn rails, but learning a new framework via books is not always the most approachable way for newcomers to learn rails. It would be awesome if someone rebooted some of the older railscasts by Ryan Bates Railscasts for rails 3.1, but that takes a lot of effort and in another year or two the content will again become stale. I would love to see some people blog about the basics of using new versions of rails. Rails has been improving over the years, and I think excellent design decisions have been made. I do not think it is the fault of rails that the author feels that rails is less approachable.
- elithrar 15y ago
  > I would love to see some people blog about the basics of using new versions of rails. You mean: Rails for Zombies (http://railsforzombies.org/ http://railsforzombies.org/) Michael Hartl's screencasts/tutorial (http://ruby.railstutorial.org/ http://ruby.railstutorial.org/) Stack Overflow (not a blog, but a really good resource). I think the number of blogs doing Rails 101 type posts has changed, because there are existing resources that do a great job, and developers/bloggers recognise that.
- joshwa 15y ago
  The pace of Rails development isn't a problem in and of itself, it's that the pace of change and the overall Rails development culture wrecks the documentation ecosystem. Of the top rails documentation resources: * Rails Guides are still out of date and incomplete for 3.x series. I often have to go to the API docs since some big topics just aren't covered in any level of detail. * Railscasts deals exclusively with deltas-- new features, new techniques, etc, and no longer has a nice pedagogical sequence. The original tutorials are just plain out of date. (Maybe the peepcode tutorials are more up-to-date and comprehensive?) * Google. The biggest of all. Rails pace of change and its agnosticism means that the corpus of blog posts with recommendations, bugfixes, tips, tweaks, tutorials, etc, become out of date quickly, and more importantly it's extremely hard to tell what version of rails or of a plugin a given post or thread is referring to. A secondary issue: Rails newfound agnosticism (compared to its previous "opinionated" nature), along with the culture of the "flavor of the week" creates problems in the development and documentation ecosystem: * The plugin ecosystem: the "flexibility" of rack means that there are so many plugin options it's blinding, and the flavor of the week changes so often that it's hard to know if you're on a dead-end track or not. * Google: the same issue with Rails core changes applies manyfold to the development ecosystem: blog posts, stackoverflow threads, forums, etc are quickly obsolete and it's difficult to determine staleness and whether the recommendations are pointing to a development dead-end where the project is no longer under active development. The panoply of options and the chaotic development ecosystem can equally be attributed to Rails' newfound agnosticism, the development culture that engenders, and that chaos multiplied by the huge popularity of Rails makes navigating and getting things done difficult. It's my experience that Rails involves a lot more yak-shaving than it used to due to the issues above. I kind of wish there were a more conservative Rails community/blog/resource that issued recommendations and documentation/tutorials about a more stable way of doing Rails, making sure that the surrounding ecosystem is more stable and has less entropy than the community at large.
c00p3r 15y ago
going to be as bloated and complicated as J2EE.. ^_^
rimantas 15y ago
Good things are happening. I am glad to see more attention to front-end stuff. What's so scary there? I am using SCSS and CoffeeScript outside the Rails too (for WordPress themes) and I do pack my JS and compress my CSS. This is how it should be done and I am glad to see it is default in RoR.
bstar 15y ago
My brother, who is a novice programmer, picked up the rails basics in a couple weeks (with some help, of course). He was able to create the app he set out to, going from zero experience to a fully functioning app in 2 months. If you are having trouble with rails, it's for two possible reasons... 1) you won't accept that it's opinionated software and throw out your preconceptions or 2) you're just not trying hard enough. The amount of books, screencasts, tutorials, podcasts out there for rails is just insane. I'm completely jealous these things weren't around in '06 when I started. Edit: Should have mentioned that he did the Michael Hartl screencasts/tutorial (http://ruby.railstutorial.org/ http://ruby.railstutorial.org/)
davidw 15y ago
I too get a feeling of "change for the sake of change" from Rails at times. That's obviously not something they're doing, as all the changes have some motivation, but at times it feels a bit like churn. At one point in time, you did forms like <%= form .... and then they switched to <% form .... do and now they've switched back to <%= form ... do again. Also, the upgrade to Rails 3 is not an easy one. Yeah, you get some nice stuff, but because it's so painful, it's not happening for a lot of people, which is causing more problems. All in all, I still think it's the best thing going in web development today for what I do, and am not contemplating alternatives.
eagsalazar 15y ago
(1) Regarding the article: boo f-ing hoo. (2) Why Rails 3.1 actually is blowing it: There is no way to turn off concatenation of js/css files in development! WTF? Have these guys ever developed a client heavy app before? That is a total non-starter. I love how the entire goal was to make js a first class rails citizen but you can only debug these files in firebug as one giant file! What a f-up!
- xentronium 15y ago
  > There is no way to turn off concatenation of js/css files in development! Remove these lines: *= require_self *= require_tree . There's another option for really client-side heavy applications -- use better packager; however, it requires some effort to maintain.
- dhh 15y ago
  This has already been solved. Just add ?debug_assets=1 to any url and it'll be rendered with individual include lines instead of concatenation. We're building client heavy apps, though, and haven't felt a need for it. But now it's there if you need it. Enjoy!
  - eagsalazar 15y ago
    That is great news! Rails 3.1 otherwise has many great features. However, I'll be honest, I find it completely unbelievable that you don't have a problem debugging in one huge js file. I guess when using coffee script the connection between what you are debugging and what you are editing is already completely severed so maybe at that point it doesn't matter anymore.
  - bxr 15y ago
    You have very funny definition of "solve". In my day we would have called that a workaround.
- chriserin 15y ago
  I find that I like debugging the concatenated version of javascript better. I end up using search a lot more in chrome development tools but I actually get to the place in the code I want to get to faster with one file and search.
elrodeo 15y ago
> But we’re making it harder and harder for anyone to join the club from scratch. That's a brilliant point. Some time ago I wanted to try out RoR to create a fast prototype. It turned out, that if you need just one prototype and if you don't know RoR, you'd be way faster if you use things you already know or just read the short Sinatra manual instead of spending weeks of learning only to be able to START the development.
porras 15y ago
I don't think Rails never was about been quick to learn. It was about being easy to use (once you had bothered to learn to use it, or at least the basics). I don't think that has changed.
Itf 15y ago
As a beginner who started trying to learn rails from 1.2-2.0 I just wanted to say that Rails was never simple with all its magic and metaprogramming. "Blog in 15 minutes" is about being productive. Defaults, conventions and DSL's are for less code only. You still have to know the rules. (Both DSL and what's underneath it.) Javascript is not simple - so we have CoffeeScript. HTML isn't - there's HAML. (1 line of code to add it to Rails 3.1) Web applications are now more complex - client logic finally moved to /app folder.) We can still enable old routing (uncommenting one line). But you have to learn bundler for dependency management, know application.rb configuration options, etc. So I don't get what 'simple' about that technology stack. It's DRY and rather flexible, but not simple.

201 points by tswicegood 15y ago

_pius 15y ago

If you want to learn rails, don’t get the latest pragmatic programmers book. Go and get the 1st or 2nd edition. Get an old copy of rails and ignore all this. Worst. Advice. Ever. Once you’ve figured that all out then upgrade and expect to spend the same amount of time learning all the new stuff. You don’t save any time jumping to Rails 3+. This just isn't true.

nfm 15y ago
Agreed. Rails has significantly changed since 2.3.x, and is extremely different to 1.2.x. These changes aren't just for the sake of it - Rails keeps on improving! Start at 3.1 and you won't be sorry.
- tdfx 15y ago
  I started with rails 3 and I haven't had any major hurdles to overcome. I've been very impressed with Rails. I'm coming from a Python/PHP framework background, and so far rails is my favorite (only done a few apps so far, mind you).
joshuacc 15y ago
Indeed. As a front-end developer with little back-end experience, I was able to get the basics of Rails with just a few hours working through Hartl's tutorial.
rohitarondekar 15y ago
Agreed. I strongly urge the author to change this suggestions because it's a dangerous one. You don't want newcomers learning an older version of Rails and then struggling to upgrade. There are a lot of resources to help you out. The API Docs[1], Official Rails Guides[2] are excellent and Railscasts[3] are also awesome. [1] Rails API Docs http://api.rubyonrails.org http://api.rubyonrails.org [2] Rails Guides http://guides.rubyonrails.org http://guides.rubyonrails.org [3] Railscasts http://railscasts.com http://railscasts.com
bulletsvshumans 15y ago
I just picked up rails for the first time this month. My background is primarily in the desktop environment, but using rails 3 has been nothing but a joy so far. Glad I didn't take this guy's advice.

nfm 15y ago

I agree that the barrier for entry to Rails is quite high. To really get into it, you might have to learn: * A new language * A new framework * A new programming paradigm * A new set of libraries This is going to be really hard if you're currently a spaghetti coder. Will you learn a lot? Will you become a better programmer? Will you enjoy coding more? I say yes!

andrewflnr 15y ago
Generally, I agree. But a spaghetti coder is going to have trouble no matter where they go. For such a person, moving to a new framework might not actually result in much valuable learning. If they were open to that, would they still be a spaghetti coder?
crag 15y ago
You rails guys think you're the only game in town. A spaghetti coder is gonna have issues regardless of the language/framework. Also the barrier to any framework in any language is the same.

ethyreal 15y ago

i found the ever changing world of rails intimidating when i first started and that was in the wonderful world of 1 moving to 2 but at the end of the day all you really need is to get the same version of rails that your book/tutorial covers and stick with it..

jmtame 15y ago

The assets pipeline feels horrible, it's really slow. I upgraded to Rails 3.1rc, realized it fights with Heroku unless upgrading to the Cedar stack. Lesson learned: stay away from Rails release candidates. But I downgraded to Rails 3.0.8 because 3.1 was just more of a hassle starting out. Maybe I'm doing something wrong, usually when I'm fighting the framework it's a sign that I don't fully understand something. I loved Rails 3.0 when it was announced, but I share the same sentiment as the OP re: 3.1 at the moment.

joevandyk 15y ago
None of the heroku stacks support mysql.
- jmtame 15y ago
  Right, though I think I was more hesitant on upgrading to Cedar--probably could have done that without any problems, but ultimately I just didn't like 3.1rc. My major gripe was with the assets pipeline. Edit: are images not supposed to be served through /assets? They were loading too slowly for me, that was my major complaint.
  - joevandyk 15y ago
    No, images are not supposed to be served through /assets. Put them in /public.
    - dhh 15y ago
      rake assets:precompile will automatically copy images from app/assets/images to public/assets. The asset pipeline can be a development concern only, if you want it to.
      - huetsch 15y ago
        I love the 3.1 rcs but using 3rd party css files that reference images are kind of painful to deal with in conjunction with the asset pipeline. I find myself making awkward directory structures in the vendor directory to avoid making modifications to 3rd party css libraries (like jQuery UI). I'm hoping a lot of this will go away when those things are packed into gems that I can just put in my Gemfile and forget. I'm sure Compass and Blueprint will get to that point pretty quickly but I'm not sure that something custom-generated like by jQuery UI ThemeRoller will ever be smooth to set up.

bricestacey 15y ago

This sounds like an old person ranting about the good ol' days when it's probably a personal phobia against change. I started learning rails just as 3 was coming out. I had made a site with rails 2 and while googling around for help I found all these tutorials about rails 3 and they definitely made everything much easier. Sure, if I had more time invested in 2 (like this guy?) I'd be peeved, but I'm luckily more aligned with the direction of rails rather than its past.

nthj 15y ago
This sounds like an old person ranting about the good ol' days when it's probably a personal phobia against change. Crafting software requires a fine balance between getting stuff done with what you know and losing productivity because you're stuck with older technology. Some of my best decisions as a software craftsman required change. Subversion to Git, PHP to Ruby on Rails, VPN to Heroku, all helped me build great stuff far more effectively. And some of my biggest problems came from attempting to adopt new technology x instead of building something great quickly with what I already knew. I don't have a simple answer for maintaining that balance. It's hard. Being aware of needing that balance is a great first step. Complaining about change, though, seems to be the least productive response. Can I build something great right now? No? OK, can I learn something new right now? No? OK, then some downtime might be my best choice. For right now.

felipemnoa 15y ago

What is happening is that the language/framework continues to grow/mature/(get older). Not sure if that is a good thing. My guess is that as more Use Cases are being implemented a lot of the early simplicity is being lost. As it gets older it starts to accumulate good stuff and bad stuff. Just like any other language. I think most languages go through this. <satire> My guess is that eventually there will be another golden boy and a whole new generation of programmers will swear that it is the best thing since the invention of the wheel while at the same time complaining of all the baggage and bad decisions made in Ruby/Rails and ridiculing anybody that still uses it. Meanwhile the Ruby/Rails developers will look and scratch their heads wondering what all the hate is about. After all, Ruby/Rails gets the job done even if it is not perfect and anybody that is a language fanboy does not have a brain. After all, a programming language is just a tool. A whole generation latter the cycle repeats itself with yet another golden boy language. Sigh! To be young and stupid. Those were the days. </satire>

wtn 15y ago
There was another golden boy, it was called Merb. Then their team joined Rails and started refactoring things… Members of the Rails core team recognize that growth has limits. They are looking for ways to reduce the stack to improve the design and make things more performant. See Aaron Patterson's RailsConf 2011 keynote.

tomfakes 15y ago

I've been building a new app with the Rails 3.1 rcs for the last 3 or 4 weeks. I still have no idea how to actually deploy into production in a way that has a chance of working. As far as I can tell, I need the V8 code built on my production boxes! That seems insane, unless I want to switch to using node.js.... On my FreeBSD system, I still have no idea how to get V8 built correctly. I've bailed on it for now and am running my 'production' server with the 'development' environment. Remember, I'm not running beta software, I'm running a 'release candidate'. When this works, it'll probably be great, but stick with 3.0 if you actually want to make progress on your application.

joevandyk 15y ago
Put the coffee-script gem into your Gemfile. Assuming you have a compiler on the production box, you're fine.
nfm 15y ago
You'll need to add 'therubyracer' (or another javascript interpreter) to your Gemfile. It requires python and a C++ compiler to compile its binaries. If you're on Heroku, you may need 'therubyracer-heroku' instead - there are compilation issues. Hopefully this will be fixed soon.
- tomfakes 15y ago
  This needs the V8 stuff compiled and installed. And then I'm running yet more code on my production servers to deploy. And this code compiles the CoffeeScript to JS, and this will be the very first place that this code will have actually been tested in this configuration. This deployment scares me a lot -- partly because I haven't yet made it work in an RC build, and mainly because it adds more moving parts to my production servers.
  - rubymaverick 15y ago
    You do not need to use CoffeeScript in Rails 3.1, it is merely the default option. Just delete the "gem 'coffeescript'" line in your Gemfile and just use regular js.

latch 15y ago

I spent the end of last year doing Java/Struts. Felt like time travelling back to 2002. Back when I knew PHP, versions increased, but nothing really changed for years and years (I'd be surprised if it was much different today). The .NET folk will tell you how great ASP.NET MVC is, but they live in their own world - a new view engine doesn't close the gap which exists between it and more progressive MVC frameworks. The point? If you want stagnant frameworks there's plenty to pick. A lot of them aren't easier to learn, but none of them require you to keep learning. This is great because it tends to attract all the programmers you want to avoid into obvious communities.

nirvdrum 15y ago
Surely there's some middle ground though, no? At what point do you have a stable core and then you just bolt things on? There's nothing stopping you from using SASS and Coffeescript with Rails 2.3. I skipped the Rails 3 upgrade just simply because I couldn't justify the time sink. rspec made it ridiculously worse with the difference in Rails support between 1.x and 2.x. I'm guessing with Rails 3.1 coming out I'll have to upgrade just because most of the plugins I use have moved on and don't backport bugfixes. It'd be nice to evolve an app without having to constantly wasting time on version compatibility. It's an absolute nightmare if you have any non-trivial-sized app.
- rohitarondekar 15y ago
  You are not forced to use SASS and Coffeescript. You can just switch them off. You can also switch off the asset pipeline.
  - nirvdrum 15y ago
    That wasn't the argument I was making. My argument was if those are the new technologies you want to play with, you don't need a major new Rails release. Since the opposing argument seems to be that Rails needs to keep breaking compatibility in order to keep up with the latest technologies.

pspeter3 15y ago

I used to be a rails developer. After rails upgraded to 3.1, I switched to Padrino and haven't looked back

mhartl 15y ago
I'm confused. Rails 3.0.8 is the current version. Rails 3.1 is still in beta. What's in the beta release of Rails 3.1 that caused you to leave? A couple of defaults have changed, but valid Rails 3.0 applications can be upgraded to 3.1 with a minimum of effort.
- pspeter3 15y ago
  When I tried the Rails 3.1 beta, I had issues with getting Mongoid and various other dependencies working and could not get it to run. My Rails 3.0 app completely broke. I might be an edge case though.
  - mhartl 15y ago
    I'm preparing a screencast on upgrading the Rails Tutorial sample application from Rails 3.0 to Rails 3.1. Maybe you'll find it useful. Subscribe to the news feed (http://news.railstutorial.org/ http://news.railstutorial.org/) to be notified when it's ready.
  - cannikin 15y ago
    Have the gems for Mongoid and such been "certified" against 3.1? Seems kind of hash to drop the whole framework based on a bad beta experience...wait until an official release and see.

dev_jim 15y ago

I could never wrap my head around the Rails world. I enjoy the elegance and simplicity of Python/Django. There's a lot less 'holy shit magic' moments.

deleted 15y ago

[deleted]

korch 15y ago

IMHO Rails has become the very kind of spaghetti web "muck" it set out to replace 5 years ago. This is my primary reason for switching to Node.js for as much as possible going forward. What ever happened to the original spirit from 2007 of "build a blog in 10 minutes using Rails"? Good luck doing that now in under an hour! I think Rails has drifted very far from the "convention over configuation" mentality. It's inevitable that this happens to any awesome software after you let programmer geeks pile on for 5+ years. Now you'd be lucky to get Bundler working in 10 minutes on your new Rails app. And then you'd have to visit railswizard.org or find an app generator to handle all of the boilerplate configuration choices you'd need just to get the conventional Rails app running. And then you'd have to make a million other choices just to build a blog. Developers are like water, always following the path of least energy, flowing downhill. The moment any software becomes difficult to use, it's dead, as the zeitgeist shifts. Right now Node.js feels very similar to the way Rails felt in 2006-7, where you can sense the growing momentum of a large shift in the developer community.

swampthing 15y ago

I think the author is conflating two issues - (1) learning Rails and (2) keeping up with the latest developments in Rails. I agree with the author that (2) is getting harder - but this is the price you pay for improvement. I disagree that (1) is getting to be overly difficult. By and large, the changes to Rails 3 and Rails 3.1 make it easier for developers to do more advanced things with Rails. If you just look at the simple tutorial applications that newcomers to Rails are starting out with, I don't think their complexity has increased very much from Rails 2 to 3 to 3.1. Yes, they are different from version to version, but this doesn't matter to the newcomer. TL;DR - the framework has more functionality, which makes it more difficult to learn the entire framework, but it is not significantly more difficult to learn how to accomplish any given task.

stretchwithme 15y ago

Over time, Rails changes to make it easier to deal with the complex needs of web applications. Part of that is changing things to make things more orderly, so you can actually find your way around a complex application without too much wasted effort. That places demands on developers, especially when migrating, but makes it easier in the future. The amount of power you can weld in the present is dependent on how much capability you acquired in the past. You can always enter a battle with your bare fists and no learning curve, but if someone gives you a free sword, learning to use it before the battle is more likely to lead to victory. This is not learning for the sake of learning. But even learning for the sake of learning grows your ability to learn.

jamesbritt 15y ago
Over time, Rails changes to make it easier to deal with the complex needs of web applications. Why? Why is Rails changing to handle this, instead of add-ons, plug-ins, and gems changing?
- dhh 15y ago
  Because that's always been the mission. Have a solution for most people, most of the time. With the target being building full-fledged apps ala Basecamp (that touches on all parts of web tech). So we've been pursuing this mission for 7+ years. We've just gotten better at it.
- stretchwithme 15y ago
  One of new 3.1 features actually makes it easier for you to use external assets like gems and plugins. Instead of downloading downloading code and then moving files to their proper locations, the new asset pipeline lets developers package such assets so bundler can accomplish that for you. You'll just specify what the asset is and what version you want in Gemfile. That's a change that you can't just rely upon some gem to make. It's really the responsibility of the framework. And it creates order, making Rails easier to work with, especially when the app gets complicated. Similar changes have similar rationales and these can be understood by watching videos like this one: http://www.youtube.com/watch?v=cGdCI2HhfAU&list=PL379EA9290474C86C

chrismealy 15y ago

I stay caught up on everything in railsland just by watching Railscasts. I can't deny that it's chaotic right now but I'm enjoying the rapid progress. I like the little things, like js and css moving from public to app. Also, I think the switch from prototype to jQuery will help beginners.

OstiaAntica 15y ago

It feels like Rails is slowly dying. It doesn't have the broad penetration of PHP, and most folks taking up a scripting language today choose Python.

cantbecool 15y ago
I disagree. With the proliferation of new tutorial books and screencasts in addition to more and more web developers choosing Rails, it's far from dying, it's actually in growing at rapid rate.
- ssmoot 15y ago
  Where do you get your numbers for that? I'm genuinely curious. I had the opposite impression; but I don't have any numbers at all to back it up.
  - cantbecool 15y ago
    Just anecdotal evidence. I'm just seeing an increase of job postings online, but after doing research, the term 'Ruby on Rails' is actually declining on Google trends. http://trends.google.com/trends?q=ruby+on+rails&ctab=0&geo=all&date=all http://trends.google.com/trends?q=ruby+on+rails&ctab=0&#... I thought at least there would be a slight bump after Rails 3.0 release, guess not.
devski 15y ago
not surprised by python itself, since it is a beast of a language on all fronts (web develpment, cross platform guis, games, scientifc computing, etc etc..), and on all os (windows is a first class citizen, one of the reasons for its massive success). django on the other hand is not there yet, compared to rails.

jrockway 15y ago

Catalyst is the main web framework for Perl, and it's always been of this design. No opinions, craft every little component exactly to your own specifications. No default ORM, no default Javascript helpers, no default form builder, no default templating library. Bring Your Own (or download from CPAN). Back in the day, I remember writing reddit comments and blog posts to explain the relative popularity of Rails over Catalyst. It was usually along the lines of, "people want to be told what to do. given a screw, they would rather bash it in with a hammer than to read about what a screwdriver is." Posts like this reinforce that point: people don't use Rails because they want to use Rails, people use it because they're afraid of anything else. Rails gave them everything that they thought they needed, and no easy way to back out of the defaults. It was a comfortable world where you could never do something wrong. Now that Rails is becoming a meta-framework like Catalyst, people are being driven away because they have to think before they program, and they have to customize Rails into the framework they want instead of just using the framework that dhh wants. You can even see this in the Perl community; people are switching away from Catalyst in favor of mini-frameworks that barely meet their needs, just because they feel like the framework author has thought of everything and they will never write a line of boring code again. If only.

epochwolf 15y ago
I think the difference with Rails is it still provides defaults. Out of the box it's a full stack ready to go. Customization is not required.
sunchild 15y ago
"people don't use Rails because they want to use Rails, people use it because they're afraid of anything else" Nonsense. Almost doesn't deserve a response, but...people use Rails because they agree with many of the choices made by the framework. Where they don't agree, and are willing to absorb the cost to maintainability, they override the framework.
- eropple 15y ago
  ...or because they think it's trendy, and don't have the breadth of experience to know if they actually agree with it or not. (Not you, but the legions of people who think they're web developers because they learned RoR and never bother to learn anything else are pretty annoying.)

grandalf 15y ago

I think it's quite telling that DHH frequently tweets his opposition to aspects of what is happening with Rails, and that Yehuda quit the core team. In a world where some time on the core team can land someone $300K per year in salary + speaking + book deals, there is bound to be this sort of chaos. I view the push toward agnosticism as a misguided attempt to be the "one true framework" and also to salve the egos of those whose decisions and work are being undone.

bradleyland 15y ago
"I think it's quite telling that DHH frequently tweets his opposition to aspects of what is happening with Rails, and that Yehuda quit the core team." That's a bit disingenuous, isn't it? Yehuda was offered an opportunity that makes sense for him. It's not as if he's abandoned the Rails community in a flurry of drama. DHH is the kind of guy that is going to speak his mind, and if you're wise you'll at least listen to what he has to say. If you find yourself agreeing 100% of the time, it's time to find different company.
- dasil003 15y ago
  Yeah, did Yehuda quit so much as fade into the background? He's clearly a guy who likes ambitious projects. His contributions to the Ruby community have been notable because of their challenging nature. Merging Merb and Rails was a gargantuan project, getting a large established framework to accept that level of outside input was impressive. The level of refactoring that went into it went against prudence, but I can't argue with the results. Rails 3 is awesome. Similarly Yehuda and Carl spearheaded Bundler development. They bit off a massive problem that touches anyone doing large scale ruby development and through sheer force of will hammered out a powerful solution that solves the majority of common issues in a relatively straightforward manner. There's lots to argue with, for sure, maybe it's over-engineered, maybe they didn't work closely enough with RubyGems core, etc; but at the end of the day they solved a problem that was too hairy for the average dev to have much hope of solving. Yehuda's been there, done that. He doesn't need to stick around and be Rails core forever, there's plenty of new blood to pick up the torch, and bigger problems to solve elsewhere.
15y ago

damoncali 15y ago

The problem is not that rails has gotten too difficult to pick up (although, I'd agree it's not as easy as it once was). The problem is the documentation is lagging behind the development - in some cases pretty severely. But what do you do? Slow down? Not sure that's good either.

tomkarlo 15y ago

I do agree that defaulting to have SASS and Coffeescript on unecessarily increases the learning curve for new adopters. Along with HAML they're fantastic technologies but in many cases you're asking people to learn Ruby, Rails, HAML, SASS and/or Coffescript all at once now. Make the base setup as such that it minimizes what they have to learn to achieve some success, and let them turn on technologies such as HAML/SASS/Coffeescript later on once the cognitive load of switching to Ruby and Rails has decreased.

jshen 15y ago
I think it's better to turn them on by default. Rails gains enormous benefit from the fact that nearly all rails sites are running the same stack. Try learning spring mvc to see what it's like to give lots of options.
mhartl 15y ago
There's some serious FUD going on here. Not only are valid CSS files also valid Sass files, but CSS files in the app/assets/stylesheets directory are served up just fine. There's no need to learn Sass right out of the gate. And Haml isn't even included in the default install, so that's a complete red herring. Finally, JavaScript files in app/assets/javascripts work fine as well; as with Sass, there's no need to learn CoffeeScript right away.
Volpe 15y ago
> many cases you're asking people to learn Ruby, Rails, HAML, SASS and/or Coffescript all at once now. As oppose to Ruby, Rails, ERB, CSS, and Javascript? - CSS is valid SASS - Coffeescript is closer to Ruby/Python than javascript and is possibly an easier learning curve (if you don't already know javascript) (You can use javascript if you want as well).
- tomkarlo 15y ago
  ERB is extremely similar to PHP and regular HTML. CSS and Javascript will already be familiar to someone who has done development in other languages. Call it FUD (despite the fact that I do all my development in Rails) but the issue isn't the reality, it's the perception. You make these the defaults for Rails and/or you write the new user tutorials in them, and you increase the perceived difficulty of starting to use Rails. You make them options that more advanced users can choose to turn on, you reduce that friction. That's all I'm saying. To clarify: I'm pro HAML, SASS/SCSS and I like the idea of Coffeescript even though I'm not using it. I just think that some of the way the've been going with Rails is not great from the perspective of growing the adoption of the platform. And yeah, my mistake about HAML. I've been using it so long with Rails I've forgotten it's not a default.

joelmichael 15y ago

I've been coding in Rails since pre-1.0, and while some decisions have annoyed me, I am ultimately happy with the direction Rails has gone. It keeps Rails at the forefront of web technology.

flocial 15y ago

The problem with Rails is not the pace of change so much as the wild changes of direction it takes, sometimes introducing serious performance degradations into official releases. Sometimes it's hard to see a guiding core philosophy other than the fact they want to be on the shiny edge. It's nice that they aren't stuck with bad design decisions forever but when you go in for an upgrade and you depend on some unpopular plugins, you can bet on pain and even performance problems. A major issue with some parts of the community is that some programmers think that being rubyists automatically makes them elegant programmers even if they don't have a clue about proper algorithms and that's probably why others call them "hipsters". The general disregard for improving performance, inherited from Ruby, is also something endemic from a while back. Sure programmer time is important but how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains. Getting your app into production is also another pain point with the all the dirty tricks you need to master, not to mention an array of lackluster choices be it nginx, passenger, unicorn, rvm, REE, bundler, etc. So with that background, I think the author's gripes are understandable but it really doesn't touch on the undercurrent of discontent surrounding the current ecosystem.

Volpe 15y ago
> how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains. So how many? I've hardly heard of this as the 'norm' for growing companies on rails... ? This sounds like 'Does Rails Scale' FUD. Getting your app into production is not a pain point at all, services like heroku, or engineyard have made this as simple as 'git push'. Which nirvana of release management are you coming from where this is a 'pain point' ?
- gtani 15y ago
  I've heard of a few deployments where the dev environment is MRI/"C-ruby" and production is JRuby.
  - nirvdrum 15y ago

ekidd 15y ago

What's happening to Rails? DHH is adding some new APIs, and he's suggesting new programming guidelines and conventions. This is nothing new. He's been doing this every 6 to 12 months since Rails 0.13 (at least). Here are some of the bigger disruptions: - Rails 1.2: Rewrite all your controllers to use the new REST model. (This was annoying, but the results looked a lot better.) - Rails 2.0: Change from ";" to "/" in standard resource routes, and rewrite controllers to use respond_to. - Rails 3.0: Deal with bundler, ActiveModel, Arel, a total overhaul of ActionMailer, etc., etc. By historical standards, the asset pipeline is a medium-sized change, and certainly much smaller than the Rails 3.0 changes. And unlike the Rails 3.0 changes, you can turn it off in about 2 minutes. Personally, I rather liked most of these new features at the time: They addressed my day-to-day pain, they made my code cleaner, and they helped me keep in sync with other programmers. Rails is optimized for a certain set of opinions, which overlap about 80% with my own, and that's usually good enough for me. If your tastes diverge from DHH's tastes to a greater extent, it won't be as much fun.

localhost3000 15y ago

I don't get it. I found rails 3 exceptionally easy to learn. Sass is a dream. It's what css should have been. Haml has its annoyances but in general is great. Both of these are also exceptionally easy to learn. I love where rails is going.

pdenya 15y ago

My biggest issue with rails was more getting my development environment setup. Constant gem compilation issues, I spent hours resolving them. Aside from that I haven't had much trouble stepping into the language or the new environment.

getsat 15y ago
> Constant gem compilation issues, I spent hours resolving them. While this is common, it doesn't really have anything to do with Rails itself. I can't think of any Rails dependencies that have mandatory native extensions off the top of my head.
- pdenya 15y ago
  My biggest problems were mysql2 (i had mysql installed and setup already from my php dev stack) and bcrypt-ruby (required for devise)
  - getsat 15y ago
    mysql2 is far easier than the original mysql gem. If you want to waste half a day, go try to install the old one. ;) Are you on a Mac, by chance? With XCode/GCC + MacPorts, I've not had many issues with gems. Add to Gemfile, run bundle. Done.
- jamesgeck0 15y ago
  If you want SQLite, there's that. Not mandatory, but pretty useful. Fortunately there are the jdbc-sqlite3 and activerecord-jdbcsqlite3-adapter gems for Jruby.
  - getsat 15y ago
    Ah, good point, I forgot that Rails defaults to SQLite.

trustfundbaby 15y ago

This seems to be a complaint that Rails is a moving target, and that the target is being moved in absence of a genuine need. ------------------------ I think this is more my problem with the whole thing. The coffeescript thing just bugs me for some reason, it seems a bit like the javascript helper, rjs days and look how those panned out. There's a Joel Spolsky article making fun of the way .NET releases come thick and fast just to keep Microsoft developers constantly worrying about catching up ... I just have this weird feeling that we're becoming the punchline in that joke.

kristianp 15y ago
The Spolsky article was about how Microsoft changes the whole framework on you every few years. Which is why there seems to be some uproar about the Windows 8 information not mentioning .net at all.
- trustfundbaby 15y ago
  The Spolsky article was about how Microsoft changes the whole framework on you every few years ------------- Judge for yourself. http://www.joelonsoftware.com/articles/fog0000000339.html http://www.joelonsoftware.com/articles/fog0000000339.html

stephenhandley 15y ago

lol this is just some pay your dues nonsense. "You will love rails if you begin at the start like we all did" http://pine.fm/LearnToProgram/ http://pine.fm/LearnToProgram/ (probably not relevant for HN) http://ruby.railstutorial.org/ruby-on-rails-tutorial-book http://ruby.railstutorial.org/ruby-on-rails-tutorial-book http://devcenter.heroku.com/articles/quickstart http://devcenter.heroku.com/articles/quickstart

audionerd 15y ago

If you're hesitant to be an early adopter (AKA "guinea pig") Rails 2.3.x is very stable, and most of the useful plugins in the Rails ecosystem are still maintained for Rails 2.3.x. Many big names are still on Rails 2.3.x, too. Forgive me if I go astray here, but GitHub and DocumentCloud are two examples that come to mind.

dhh 15y ago
Staying on Rails 2.3.x is certainly fine for existing apps, but starting a new app on 2.3 is a very bad idea. You're setting yourself up for a lot of headache for the inevitable migration. Let alone depriving yourself of all the wonders of Rails 3. That being said, nobody is forcing you to jump on a release candidate. Just use the latest released, stable version. In this case Rails 3.0.x.

mrinterweb 15y ago

I think the big difference between now and when Rails was first starting to gain popularity is that now most of the blogs are primarily covering advanced/obscure topics related to rails. Years ago, most blog posts were about the basics of getting started with rails. Now those old posts no longer apply to the newer version of rails. This is not the fault of rails and it is not the fault of bloggers. There is no shortage of books available to learn rails, but learning a new framework via books is not always the most approachable way for newcomers to learn rails. It would be awesome if someone rebooted some of the older railscasts by Ryan Bates Railscasts for rails 3.1, but that takes a lot of effort and in another year or two the content will again become stale. I would love to see some people blog about the basics of using new versions of rails. Rails has been improving over the years, and I think excellent design decisions have been made. I do not think it is the fault of rails that the author feels that rails is less approachable.

elithrar 15y ago
> I would love to see some people blog about the basics of using new versions of rails. You mean: Rails for Zombies (http://railsforzombies.org/ http://railsforzombies.org/) Michael Hartl's screencasts/tutorial (http://ruby.railstutorial.org/ http://ruby.railstutorial.org/) Stack Overflow (not a blog, but a really good resource). I think the number of blogs doing Rails 101 type posts has changed, because there are existing resources that do a great job, and developers/bloggers recognise that.
joshwa 15y ago
The pace of Rails development isn't a problem in and of itself, it's that the pace of change and the overall Rails development culture wrecks the documentation ecosystem. Of the top rails documentation resources: * Rails Guides are still out of date and incomplete for 3.x series. I often have to go to the API docs since some big topics just aren't covered in any level of detail. * Railscasts deals exclusively with deltas-- new features, new techniques, etc, and no longer has a nice pedagogical sequence. The original tutorials are just plain out of date. (Maybe the peepcode tutorials are more up-to-date and comprehensive?) * Google. The biggest of all. Rails pace of change and its agnosticism means that the corpus of blog posts with recommendations, bugfixes, tips, tweaks, tutorials, etc, become out of date quickly, and more importantly it's extremely hard to tell what version of rails or of a plugin a given post or thread is referring to. A secondary issue: Rails newfound agnosticism (compared to its previous "opinionated" nature), along with the culture of the "flavor of the week" creates problems in the development and documentation ecosystem: * The plugin ecosystem: the "flexibility" of rack means that there are so many plugin options it's blinding, and the flavor of the week changes so often that it's hard to know if you're on a dead-end track or not. * Google: the same issue with Rails core changes applies manyfold to the development ecosystem: blog posts, stackoverflow threads, forums, etc are quickly obsolete and it's difficult to determine staleness and whether the recommendations are pointing to a development dead-end where the project is no longer under active development. The panoply of options and the chaotic development ecosystem can equally be attributed to Rails' newfound agnosticism, the development culture that engenders, and that chaos multiplied by the huge popularity of Rails makes navigating and getting things done difficult. It's my experience that Rails involves a lot more yak-shaving than it used to due to the issues above. I kind of wish there were a more conservative Rails community/blog/resource that issued recommendations and documentation/tutorials about a more stable way of doing Rails, making sure that the surrounding ecosystem is more stable and has less entropy than the community at large.

c00p3r 15y ago

going to be as bloated and complicated as J2EE.. ^_^

rimantas 15y ago

Good things are happening. I am glad to see more attention to front-end stuff. What's so scary there? I am using SCSS and CoffeeScript outside the Rails too (for WordPress themes) and I do pack my JS and compress my CSS. This is how it should be done and I am glad to see it is default in RoR.

bstar 15y ago

My brother, who is a novice programmer, picked up the rails basics in a couple weeks (with some help, of course). He was able to create the app he set out to, going from zero experience to a fully functioning app in 2 months. If you are having trouble with rails, it's for two possible reasons... 1) you won't accept that it's opinionated software and throw out your preconceptions or 2) you're just not trying hard enough. The amount of books, screencasts, tutorials, podcasts out there for rails is just insane. I'm completely jealous these things weren't around in '06 when I started. Edit: Should have mentioned that he did the Michael Hartl screencasts/tutorial (http://ruby.railstutorial.org/ http://ruby.railstutorial.org/)

davidw 15y ago

I too get a feeling of "change for the sake of change" from Rails at times. That's obviously not something they're doing, as all the changes have some motivation, but at times it feels a bit like churn. At one point in time, you did forms like <%= form .... and then they switched to <% form .... do and now they've switched back to <%= form ... do again. Also, the upgrade to Rails 3 is not an easy one. Yeah, you get some nice stuff, but because it's so painful, it's not happening for a lot of people, which is causing more problems. All in all, I still think it's the best thing going in web development today for what I do, and am not contemplating alternatives.

eagsalazar 15y ago

(1) Regarding the article: boo f-ing hoo. (2) Why Rails 3.1 actually is blowing it: There is no way to turn off concatenation of js/css files in development! WTF? Have these guys ever developed a client heavy app before? That is a total non-starter. I love how the entire goal was to make js a first class rails citizen but you can only debug these files in firebug as one giant file! What a f-up!

xentronium 15y ago
> There is no way to turn off concatenation of js/css files in development! Remove these lines: *= require_self *= require_tree . There's another option for really client-side heavy applications -- use better packager; however, it requires some effort to maintain.
dhh 15y ago
This has already been solved. Just add ?debug_assets=1 to any url and it'll be rendered with individual include lines instead of concatenation. We're building client heavy apps, though, and haven't felt a need for it. But now it's there if you need it. Enjoy!
- eagsalazar 15y ago
  That is great news! Rails 3.1 otherwise has many great features. However, I'll be honest, I find it completely unbelievable that you don't have a problem debugging in one huge js file. I guess when using coffee script the connection between what you are debugging and what you are editing is already completely severed so maybe at that point it doesn't matter anymore.
- bxr 15y ago
  You have very funny definition of "solve". In my day we would have called that a workaround.
chriserin 15y ago
I find that I like debugging the concatenated version of javascript better. I end up using search a lot more in chrome development tools but I actually get to the place in the code I want to get to faster with one file and search.

elrodeo 15y ago

> But we’re making it harder and harder for anyone to join the club from scratch. That's a brilliant point. Some time ago I wanted to try out RoR to create a fast prototype. It turned out, that if you need just one prototype and if you don't know RoR, you'd be way faster if you use things you already know or just read the short Sinatra manual instead of spending weeks of learning only to be able to START the development.

porras 15y ago

I don't think Rails never was about been quick to learn. It was about being easy to use (once you had bothered to learn to use it, or at least the basics). I don't think that has changed.

Itf 15y ago

As a beginner who started trying to learn rails from 1.2-2.0 I just wanted to say that Rails was never simple with all its magic and metaprogramming. "Blog in 15 minutes" is about being productive. Defaults, conventions and DSL's are for less code only. You still have to know the rules. (Both DSL and what's underneath it.) Javascript is not simple - so we have CoffeeScript. HTML isn't - there's HAML. (1 line of code to add it to Rails 3.1) Web applications are now more complex - client logic finally moved to /app folder.) We can still enable old routing (uncommenting one line). But you have to learn bundler for dependency management, know application.rb configuration options, etc. So I don't get what 'simple' about that technology stack. It's DRY and rather flexible, but not simple.