What the hell is happening to rails?

http://blog.stevecoast.com/what-the-hell-is-happening-to-rails

by tswicegood • 15 years ago

201 157 15 years ago

blog.stevecoast.com

_pius• 15 years 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.

nfm3• 15 years 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• 15 years 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• 15 years 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.

rohitarondekar4• 15 years 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 [2] Rails Guides http://guides.rubyonrails.org [3] Railscasts http://railscasts.com

bulletsvshumans• 15 years 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.

nfm3• 15 years 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• 15 years 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• 15 years 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• 15 years 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..

jmtame2• 15 years 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.

joevandyk3• 15 years ago

None of the heroku stacks support mysql.

jmtame2• 15 years 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.

nevinera• 15 years ago

RDS works fine with heroku, and I think there's a heroku mysql option in the works as well

beseku• 15 years ago

I've come from PHP, (specifically CodeIgniter) to learning Rails in the last month, and so have focused on learning from the great online Tutorial by Michael Hartl and the rails edgeguides. All are up to 3.0, but I've managed to work fine with 3.1 since I'm an experienced CoffeeScript dev and everything is very well documented in the GitHub commits. I just can't see a cause for complaint.

In regards to the framework being too opinionated and/or moving too fast, its the exact opposite of the landscape in PHP, where there is a splintered and slow moving culture, with no one framework and certainly nothing as technically advanced as Rails.

If I had to pick I'd take the Rails culture everytime, its more exciting and fun for one.

bricestacey• 15 years 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• 15 years 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• 15 years 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• 15 years 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.

tomfakes3• 15 years 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.

joevandyk3• 15 years ago

Put the coffee-script gem into your Gemfile.

Assuming you have a compiler on the production box, you're fine.

nfm3• 15 years 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.

tomfakes3• 15 years 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.

bonzoesc• 15 years ago

That's the problem though; Rails now depends on an implementation of a second programming language (coffeescript) that's only implemented inside another language environment (node.js) that changes quickly enough that many OSes don't have working packages for it.

Coffeescript is rad as hell, but making Rails depend on it by default without a really great way to install it seems foolish.

cheald2• 15 years ago

You could compile coffeescript in development and commit the resulting JS file. Automatically recompiled Coffeescript is fantastic in development, but IMO, there's really no compelling reason to be compiling it production-side.

tomfakes3• 15 years ago

Yup - I'm going to need a 'build for production' system - I've used Hudson for this in the past - that does this and sets up the production push.

cheald2• 15 years ago

(I can't seem to reply to your comment, so replying here)

You could look at using something like a Git pre-commit hook to do that pretty trivially. I personally use a rake task that compiles all my Sass and Coffeescript to their respective CSS and JS files, then packs it into minified-and-gzipped files with jammit, then commit the resulting bundle. I end up serving pre-baked-and-concatenated assets and it works just fine.

bradleyland2• 15 years ago

I think the assumption is that everyone is using some sort of asset packager/JS compiler at this point. I'm not smart enough to hold an opinion whether or not this is a "good idea™", but I can tell you that it's the general expectation.

We use Capistrano to deploy our app, so packaging assets on the way to the server is as simple as an additional deploy task for the production environments. We have a task named precache_assets that uses Jammit [1] to compile assets based on the Jammit settings (stored in a yml file, imagine that).

1 - http://documentcloud.github.com/jammit/

latch6• 15 years 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.

nirvdrum6• 15 years 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.

rohitarondekar4• 15 years ago

You are not forced to use SASS and Coffeescript. You can just switch them off. You can also switch off the asset pipeline.

jamesbritt2• 15 years 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?

Very true. Frameworks should strive for a solid API that makes it easy for people to write add-ons, and avoid adding anything that is not essential.

Of course, one hacker's essential is another's bloat, but developers should give things a long hard look before adding stuff.

It's the reason I like Ramaze so much. Has what's needed, gets out of your way, it's easy to evolve or extend if you know Ruby, and it respects your opinions.

sunchild3• 15 years ago

"I skipped the Rails 3 upgrade just simply because I couldn't justify the time sink."

This is where you lost me. I spent about 2 hours, aggregate, spent solving upgrade-related problems across a bunch of different apps.

Where is the time sink?

Retric• 15 years ago

IMO, ASP.NET is a mediocre to poor framework get's by because it uses an above average language (C#) and a vary good editor (Visual Studio). Still it all comes down to the types of applications your creating. If your building yet another internal CRUD app go with ASP.NET. If you want to build the next hipmunk then Rails is probably a better option.

xpaulbettsx• 15 years ago

Are you talking about MVC or WebForms? If you're thinking of the framework where you lay out controls on a designer, you're fighting the wrong framework.

bkhl• 15 years ago

Can you elaborate more on why Rails might be a better option than ASP.NET MVC for creating "the next hipmunk"?

kenjackson3• 15 years ago

If you want stagnant frameworks there's plenty to pick.

There's a difference between stagnant and growing in the right direction. I think the author believes that RoR is moving away from what many thought was one of its core pillars: The ability to go from nothing to an up and running web app quickly.

Lots of things aren't stagnant -- few things move in the right direction. I'm not saying that RoR isn't moving in the right direction, but I think you've created a strawman of sorts.

latch6• 15 years ago

I dunno, I kinda got from the OP that is was more about moving too fast than moving in the wrong direction. But, OP aside, I get what you are saying.

IMO, as long as Rails is being driven by real application development, I'm happy. Compared to "enterprise" frameworks which are built in isolation from the real world, Rails movement seems more grounded in pragmatism.

jshen3• 15 years ago

" The ability to go from nothing to an up and running web app quickly."

How in the world do the changes lead to a situation where you can't get an app up and running quickly? I don't see that at all.

PetrolMan• 15 years ago

I just wanted to add my two cents because I'm actually just learning Rails right now. I had never messed with Ruby or Rails at all until two months ago and I've actually enjoyed how easy it is to build basic applications with Rails quite quickly.

I came from PHP and did a lot of work with CakePHP and some with Zend Framework. I found CakePHP fun to work with but often limiting. I found ZF unpleasant to work with and often just as limiting because the effort involved in doing certain simple tasks was often too much.

With Rails I was able to crank out some basic functionality quite quickly and the only hang up I've come across is learning how to create plugins. Then again, the plugins I need are often out there in the world and I could probably get away with never having to write one.

I still think Rails is incredibly easy to learn the basics of but it also is well developed and thought out leaving plenty of room for more advanced behavior without running into the same walls I feel I ran into with PHP development.

Since I started with Rails 3, I don't have any perspective on how difficult it is to keep up with the changes but I must say I'm excited about 3.1 and I don't mind having to dig into whatever information I can scrounge up to familiarize myself with it.

brazzy• 15 years ago

his is great because it tends to attract all the programmers you want to avoid into obvious communities.

So basically you agree with point that Rails' rapid changes are making it less approachable, but see it as a good point?

latch6• 15 years ago

I do see making something less approachable to programmers who don't want to learn good, yes.

pspeter32• 15 years ago

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

mhartl3• 15 years 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.

pspeter32• 15 years 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.

dev_jim• 15 years 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.

swampthing• 15 years 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.

stretchwithme2• 15 years 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.

jamesbritt2• 15 years 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?

dhh5• 15 years 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.

stretchwithme2• 15 years 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• 15 years 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• 15 years 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.

cantbecool2• 15 years 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• 15 years 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.

devski• 15 years 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• 15 years 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• 15 years 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.

sunchild3• 15 years 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.

eropple2• 15 years 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.)

paganel• 15 years ago

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

Just the other day I was writing a similar piece about Django on my blog. Back in the day it used to be damn-simple to start a Django project (compared to starting a Zope project, for example). Download the thing, change a line or two in settings.py, and you were done. No need to worry about what ORM was Django using or about how some people thought that the templateing system was un-pythonic. Things just worked.

Now I see that more and more people decry the fact that Django is not "modular" enough or that you cannot change its default ORM with any other one just by editing one line of code. Guess what? Your boss or the client doesn't care one bit about the virtues of SQLAlchemy compared to Django's default ORM, they only want to know how long it will take for you to implement the features they want. Now, if you, as a programmer, have enough spare time to handle all the loose bits (custom ORM, better templateing systems, custom URL dispatch mechanisms etc.) then chances are you shouldn't be using an existing web-framework (like Django, for example), and that you should build your own. But don't forget to finish your projects on time.

And, for anyone interested, here's Martijn Faassen's recent Euro DjangoCon keynote about what Django could learn from Zope: http://reinout.vanrees.org/weblog/2011/06/07/zope.html . The thing is, I'm old enough to remember about how Zope 3 was supposed to be the "best Python web-framework ever. It lets you do everything you want, you just have to understand interfaces". Six years on, and nobody cares anymore.

grandalf3• 15 years 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.

bradleyland2• 15 years 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• 15 years 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.

wycats• 15 years ago

I didn't quit the Rails Core team (http://rubyonrails.org/core). I no longer work full-time on Rails, but I've been continuing to work with other members of the Rails core team on maintaining code I wrote (most notably encoding-related code and code related to the Railtie system).

I've also been contributing more code recently, and after taking something of a hiatus, have gotten back into it a bit.

No drama here!

grandalf3• 15 years ago

That too is a relief. Thanks much for the clarification. And thanks for your tremendous contribution to open source.

dhh5• 15 years ago

Rails 3.1 is by very far the best version of Rails there's ever been. Nothing makes it in or stays in the framework if I have true opposition to it being there. Believe you me.

Also, please back up your core theory with something else than wild conjecture. Core is more stable and uniform than it's been in years.

grandalf3• 15 years ago

That is a relief. Thanks for the clarification... and also for your great contribution to open source. Not trying to stir the pot but I felt like I had to speculate and hoped someone would illustrate that I was wrong.

damoncali• 15 years 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.

tomkarlo2• 15 years 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.

jshen3• 15 years 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.

mhartl3• 15 years 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.

Volpe4• 15 years 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).

tomkarlo2• 15 years 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• 15 years 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.

flocial2• 15 years 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.

Volpe4• 15 years 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• 15 years ago

I've heard of a few deployments where the dev environment is MRI/"C-ruby" and production is JRuby.

philwelch• 15 years ago

Heroku exists because Ruby deployment is a major pain point and developers are willing to embrace serious architectural limitations and high rates in exchange for willing this problem away. I'm not down on Heroku at all, I think they're brilliant, but "use Heroku" isn't a universally viable technical solution to this problem.

ekidd• 15 years 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• 15 years 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.

pdenya2• 15 years 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.

getsat3• 15 years 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.

jamesgeck0• 15 years 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.

pdenya2• 15 years ago

My biggest problems were mysql2 (i had mysql installed and setup already from my php dev stack) and bcrypt-ruby (required for devise)

trustfundbaby2• 15 years 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• 15 years 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.

trustfundbaby2• 15 years 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

stephenhandley• 15 years 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/ (probably not relevant for HN) http://ruby.railstutorial.org/ruby-on-rails-tutorial-book http://devcenter.heroku.com/articles/quickstart

audionerd• 15 years 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.

dhh5• 15 years 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• 15 years 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• 15 years 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/) Michael Hartl's screencasts/tutorial (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• 15 years 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.

rimantas• 15 years 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• 15 years 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/)

davidw4• 15 years 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.

eagsalazar2• 15 years 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• 15 years 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.

dhh5• 15 years 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!

eagsalazar2• 15 years 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• 15 years ago

You have very funny definition of "solve". In my day we would have called that a workaround.

chriserin• 15 years 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• 15 years 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• 15 years 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• 15 years 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.

What the hell is happening to rails?

Related Stories