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.
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.
I have no opinion on this, but the original article makes a few cases for this: no more ajax/javascript helpers in core, no more catch all route by default etc.
The catch all route is there, you just have to uncomment it. It takes one second.
There are other points where the article is plain wrong to. "It used to be that you just used Prototype, now it goes to vast efforts to be agnostic." No, it switched the default to JQuery, thank god.
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.
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.
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.
The time sink is in migrating all the plugins/gems that either dropped support for Rails 2.x in favor of 3 (i.e. no version that supports both), or were abandoned for some other competing gem. What this means is that for any app that uses lots of plugins, it's a nightmare to upgrade to Rails 3.0, not because of Rails itself, but because it means you have to migrate all those plugins simultaneously just to preserve existing functionality.
There are entire sites like http://railsplugins.org/ to help you figure out if your plugins are Rails 3 compatible. Unfortunately, there simply aren't enough users to crowdsource the compatibility of all the plugins out there.
100% correct. The other fun one is rspec 1.x supports Rails 2.x but not Rails 3.x. spec 2.x supports Rails 3.x but not Rails 2.x. Since the Rails support was modular, I have no idea how this situation resulted. But it basically means I have to upgrade with no test suite.
Which gems are we talking about, specifically? If it was abandoned, then you should be replacing them anyway. Backward compatibility is vastly overrated.
Actually, it doesn't really matter if it was abandoned or not. Upgrading a large number of dependencies at once is going to create problems for any project. Hell, working out the redis-rb nightmare of an upgrade took well over a week of effort trying to coordinate with the various projects that depend on it.
But, if you think backward compatibility is vastly overrated, there's really no seeing eye-to-eye on this.
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.
Also there are a lot of deprecated things that must have been removed in 3.1 ― TBH I haven't kept in touch with 3.1 development but I'm sure a lot more has happened besides the default switch and Asset Pipeline. :)
Basically in the end, Rails is a curated framework. It either fits your requirements or it doesn't. There is no need for it to work for "all possible" cases.
Also like I said you don't have to use the defaults. :)
> Rails is a curated framework. It either fits your requirements or it doesn't.
"Opinionated" was the original description. "Curated" is just some buzzword that means "people look after it" rather than "automatically generated", which is, uh, pretty much going to be par for the course for a maintained framework.
"Opinionated" communicates the idea so much better - it means not only that yes, some choices were made, but that some of them are the result of strong opinions, and do not necessarily try and accommodate all points of view.
DHH saying it does not make it any less of a silly buzzword. I much prefer his original "opinionated", as it much more clearly gets at the heart of what Rails is, that it doesn't try and be everything to everyone.
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.
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.
Rails (really Ruby) has only one thing going for it, as far as I'm concerned:
The norm in the community is to actively refactor.
That's it. When the Rails folks redesign the routes system, not only does my app get cleaner, but I learn stuff about how to write a good DSL. When Blake Mizerany wrote Sinatra, not only did we all get a super simple new tool for prototyping web apps in, like, zero seconds.... but we all learned something about how far you can take the "hello world" simplification trend.
We're all trying to get better at programming. We're all trying to advance the state of the art in software design. And we're all learning from each other, and it's awesome.
In many ways it's just a microcosm of what's happening in the Open Source world at large. Node.js is teaching Ruby devs important stuff, just as the Node authors seem like they probably took a cue or two from Sinatra. It's why I left the Microsoft world years ago.
Loose federations of heterogenous interests with high incentives to integrate are so much more interesting than centralized organizations.
IMNSHO, the norm in the ruby community as of late as not been refactor, but rewrite.
When the rails folk redesign the route system it's not a refactoring cause a refactoring keeps functionalities unchanged, it does not add/remove/change corner cases. Which has happened in all major rails releases and some point ones.
It wasn't a rewrite. The point of TDD-assisted refactoring isn't to not change anything ever, it's to change things in a controlled way and prevent regressions. It was actually pretty interesting to watch carlhuda and the rails team take rails from 2.3 to 3.0.
That simply isn't true. I'd urge you to pick up a copy of Fowler's "Refactoring: Improving the Design of Existing Code."
"Refactoring" as a term was defined in that book. It has very much been diluted into "I changed some code because I think this is better," which is a shame because it has a very clear definition.
I should also note that having a test suite allows you to refactor with more confidence, but it's neither a requirement nor changes the definition at all. So a "TDD-assisted refactoring" isn't different from a "refactoring."
It's more productive. You get more done in a shorter amount of time. Not trivially either. Its more about the language (Ruby vs C#) than the Frameworks (in that all the cool shit the Framework lets you do is thanks to the language).
If you knew C really well, and someone said "Hey, you can be more efficient building a website in C#/ASP.NET", would you have that hard a time believing them?
If you knew C really well, and someone said "Hey, you can be more efficient building a website in C#/ASP.NET", would you have that hard a time believing them?
I wouldn't. But if they said that I could write systems code better with Objective-C I'd say prove it.
Unfortunately whenever I see RoR people talk about ROR vs anything else, including ASP.NET MVC, they talk in broad strokes with statements like, "Obviously dynamic languages are far more productive than static ones." Or "People who program in Ruby are much better developers -- which is obvious to prove, because they program in Ruby."
I'm a former ASP.NET MVP, a codebetter.com blogger, I wrote Foundations of Programming, I own a handful of .NET OSS libraries. Yada, yada, yada..
All of that is pretty meaningless, I'm not saying to show off (most of that stuff isn't show off worthy). However, by all accounts, I'm an expert C#/.NET programmer who's been in the thick of of any progressive .NET movement. I know C# and ASP.NET (MVP or WebForms) much, much better than I know Ruby and Rails. Yet, somehow, I'm still more efficient in RoR (and thats only getting more true). I can get as low level about this discussion as you want, it won't change my opinion.
The two big wins for me: I write a ton less code and code is easier to test (this is largely since IoC is a language feature).
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.
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).
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.
...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.)
> 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' ?
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.
Heroku exists because Ruby deployment
is a major pain point
No dude, Heroku exists because dealing with hardware, OS configuration and updates and maintaining a scalable infrastructure (that can be upgraded to how many servers you want, or downgraded) with a sane deployment workflow is a major pain in the ass, no matter the dev tools you're using.
In fact, I found the deployment story of Rails (with the help of Rvm, Rake, Bundler, Capistrano and Passenger) to be the best one yet and no other environment can really match it (although you get pretty close with Python, Django, VirtualEnv, Pip, Fabric and mod_wsgi for example).
And I'm not using something like Heroku btw, as I consider it to be seriously overpriced - I'm maintaining my own Linux servers on top of EC2 (which still involves pain, that I can handle nonetheless, but then again I also have sysadmin skills). Deployment for me is literally just "git push && cap deploy".
Okay, pre-heroku, Capistrano, which again was a huge simplification on other deployment processes. How is rails more of a pain point than anything else? Deployment is always going to be a task that is required. Rails has for a long time had pretty good solutions to this.
I'm objecting to the parent stating that deployment is a serious pain point for rails.
I would like to know what the 'simple' deployment stack people are comparing the Rails stack too?
PHP.
I used rails exclusively for webdev the last 6-7 years and I just now worked on a PHP project. Deployment of PHP is the same as deployment of static HTML. How is that not simpler than what we got in rails. For rails you need to understand version control, webservers and scripting. For PHP you need to understand copy.
For a serious project I think rails is great but you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge that most people don't have.
Deployment of PHP is the same as deployment
of static HTML
Until somebody other than you does a database schema change or data migration, and forgets to tell you about it. Or until somebody adds a new PHP dependency (for resizing images or other shit like that) and forgets to tell the rest of the team.
For rails you need to understand version control,
webservers and scripting
No shit - those things are required in PHP too, unless you're building a contact form.
you can't deny it involves lots of abstractions
which sometimes break down and then necessitate
expert knowledge
Those abstractions save you from dealing with boilerplate or with repetitive tasks that you can easily forget about. They are based on sane practices used by experts. And those same abstractions are also present in mature PHP frameworks like Symfony and not because the developers were bored to death and just wanted to complicate your life.
Rails is not for contact forms. You are better off using PHP for that - but I saw contact forms evolve into big piles of unmaintainable crap and developers doing that because they thought a mature framework was too complicated and haven't evolved since then - shouldn't have a place in this industry.
I truly understand the points you give and I like the fact that rails has a proper process for all of this.
Fact is though that 90% of projects that I didn't start myself involve FTPing stuff to a server were all the developers muck around writing over each others files.
Horrible yes. State of the art in most web consultancies also yes.
Passenger allows one to basically work this way with ruby too and it is sorely needed because there are 'developers' out there that seemingly haven't worked with Sourcecontrol in their entire career. If you need to give them access to some templates it is nice if you don't have to bring them up to speed on git first.
I wouldn't hire those people but I was forced to work with some.
My point: Allowing a less robust but easier deployment method is a pareto improvement because I can now choose. It is also a path towards sane practices used by experts when you start with a big pile of unmaintainable crap.
I get what you're saying - and I think simple scripts uploaded by FTP are good in many contexts.
However, Ruby on Rails was never good for shared hosting. It was never designed or intended for this purpose. The deployment solutions available are not doing so good in a shared hosting environment. Or at least, not as good as PHP (nothing is as good as PHP in shared hosting).
The deployment story got a lot better when Passenger came along in 2008, which is a self-healing and easy to configure server, capable of functioning with Nginx or Apache in front. You wouldn't believe the shit you had to pull before that for reliable servers.
Personally, I hate Heroku because their prices are for the moment too high and I could partly replicate their environment on my own, using already available tools. But such hosting services will become the norm as they are so kick-ass and convenient; for instance I just received an invitation for Gondor, a Heroku-like service for Python and Django.
I think Java deployment is pretty straightforward and php is dead simple. I guess it depends on how much traffic your site gets but the larger your Rails site gets the more moving parts you end up with (at a lot less traffic than say a Java stack), higher server specs, reliance on memcache, some proxy, etc. just for a standard dynamic website. Sure you can wrap that deployment dance into a Capistrano recipe but it's not inherently simple.
But the main point is that since Rails/Ruby requires a lot more resources (cpu, ram, etc.) and wraps a lot up into a black box (auto-generated queries that might have a deadly join or two), when you deploy it's more "thrilling" for want of a better word.
I'm not saying Rails sucks completely, but the programmer productivity thing is oversold because in a small shop, the dev guys are usually babysitting servers too. This and some whimsical api changes can dampen your enthusiasm a bit. I just wanted to emphasize that some Rails enthusiasts are zealously in a state of denial of Rails/Ruby short-comings and putting a Rails app in production/deployment can be a bit challenging. Like others have said, the number of startups focused on making deployment and scaling of Rails apps "easy" kind of says something.
Given how different the two of those can handle things, particularly with dependencies, that strikes me as a bad idea. I'm not even sure I'd trust it to CI. This isn't academic either. I'm contemplating moving to JRuby. I really think I'd be more comfortable with my local dev environment matching my deployment environment.
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.
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 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.
This is the best way to do it, and using a continuous integration server to emit a binary as the output of your build, as our ancestors in compiled languages did in days of yore, is a good way to make it happen. You don't even need to commit it; just use the tarball (or whatever) as the artifact of deployment.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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!
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?
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.
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.
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.
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:
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.
> 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.
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.
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.
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.
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.
> 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).
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.
I find the quality of javascript produced through coffeescript is much higher than devs who proclaim competency with javascript. Even the simple stuff (using closures properly, and '===')
I've found a lot of devs while they have been 'trained' in C/Java/Pyhon/Ruby have kind of just picked up bits and pieces of javascript without a really a firm understanding of how it works or it's idioms. Coffeescript on the other hand, has a very (python-esque) prescriptive set of idioms that produces very decent javascript, if you don't follow the idioms, it doesn't compile.
For an absolute "i know nothing" I think the Ruby, Rails, HAML, SASS, Coffescript is a smaller learning curve than ERB, CSS, Javascript.
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.
"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.
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.
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.
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.
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.
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..
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.
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.
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/) to be notified when it's ready.
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.
(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!
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.
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.
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.
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&#... I thought at least there would be a slight bump after Rails 3.0 release, guess not.
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.
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.