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.
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.
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.
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.
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.
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+.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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.
> 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.
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.
> 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' ?
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.
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).
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.
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.
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>
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] ekidd|14 years ago|reply
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.
[+] [-] latch|14 years ago|reply
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.
[+] [-] kenjackson|14 years ago|reply
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.
[+] [-] nirvdrum|14 years ago|reply
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.
[+] [-] brazzy|14 years ago|reply
So basically you agree with point that Rails' rapid changes are making it less approachable, but see it as a good point?
[+] [-] Retric|14 years ago|reply
[+] [-] _pius|14 years ago|reply
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.
[+] [-] rohitarondekar|14 years ago|reply
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
[+] [-] nfm|14 years ago|reply
[+] [-] joshuacc|14 years ago|reply
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.
[+] [-] bulletsvshumans|14 years ago|reply
[+] [-] mrinterweb|14 years ago|reply
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.
[+] [-] joshwa|14 years ago|reply
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.
[+] [-] elithrar|14 years ago|reply
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.
[+] [-] bricestacey|14 years ago|reply
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|14 years ago|reply
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.
[+] [-] trustfundbaby|14 years ago|reply
------------------------
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|14 years ago|reply
[+] [-] jrockway|14 years ago|reply
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.
[+] [-] sunchild|14 years ago|reply
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.
[+] [-] epochwolf|14 years ago|reply
[+] [-] paganel|14 years ago|reply
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.
[+] [-] flocial|14 years ago|reply
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|14 years ago|reply
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' ?
[+] [-] tomfakes|14 years ago|reply
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.
[+] [-] bradleyland|14 years ago|reply
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/
[+] [-] cheald|14 years ago|reply
[+] [-] joevandyk|14 years ago|reply
Assuming you have a compiler on the production box, you're fine.
[+] [-] nfm|14 years ago|reply
If you're on Heroku, you may need 'therubyracer-heroku' instead - there are compilation issues. Hopefully this will be fixed soon.
[+] [-] joelmichael|14 years ago|reply
[+] [-] felipemnoa|14 years ago|reply
<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|14 years ago|reply
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.
[+] [-] localhost3000|14 years ago|reply
[+] [-] chrismealy|14 years ago|reply
Also, I think the switch from prototype to jQuery will help beginners.
[+] [-] dev_jim|14 years ago|reply
[+] [-] damoncali|14 years ago|reply
But what do you do? Slow down? Not sure that's good either.
[+] [-] davidw|14 years ago|reply
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.
[+] [-] jmtame|14 years ago|reply
[+] [-] audionerd|14 years ago|reply
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|14 years ago|reply
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.
[+] [-] swampthing|14 years ago|reply
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.
[+] [-] bstar|14 years ago|reply
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/)