What’s Up With All These Changes in Rails?
yehudakatz.com
yehudakatz.com
Rails is, and really has always been, a framework which changes very quickly. Although virtually all of these changes are for the better either in some abstract feels-better sense or in a tangible practical sense, each of these changes imposes a cost on other people.
This isn't really a problem with the decisions of the rails core team, it is the entire ethos accompanying rails. Authentication plugins I remember from 4 years ago are barely maintained today, and there are a whole bunch of new ones. I'm guessing my knowledge re: authentication has a half-life of approximately 1.5 years.
The implications are as follows:
(1) If you are a Rails developer you need to be a full-time Rails developer and not do too much else. You can't do Rails and a bunch of other things because Rails will take up a lot of your time.
(2) Think you can code, release, and forget about it? Think again. If you have projects, you (and the people who commissioned the projects) need to know that these projects need to have at least 5 hrs / week budgeted for the indefinite future (perhaps less, but the point is that they need a developer on staff -- they can't simply be released and forgotten about).
(3) Extra caution, since not all change is good change. You may end up to subject whatever is cool at the time. That's not to say that this really affects the core team, but there are a gazillion Rubyists out there attempting to change everything over to MongoDB that works just fine in whatever flavor of SQL they were running before. A lot of people have been burned here.
All of these take away from the promise and excitement of Rails for many people -- which was not simply "oh we can be on the cutting edge of technology," but "oh, we can have a sexy app with decent functionality up in a matter of a couple weeks with half the budget of what we thought." That second impression, which is what a lot of the Rails ecosystem is built off of, is largely false (esp. now that there are a bunch of other quickstart web frameworks).
I'm glad to see someone else say this. I don't use rails often, nor am I a "front end" developer by trade.
I have put together some simple web apps using rails, but it seems that each time I go back to rails and try to use the newest released version I'm starting back close to square 1 due to how things always seem to change.
I always just assumed that I didn't grok web frameworks, though this is still a possibility.
(1) Ruby the language
(2) Idiomatic Ruby as perceived by Rails Devs
(3) Rails conventions
(4) Appropriate plugins/addons
All of them take a decent amount of time to learn (well). 3 & 4 also change pretty frequently.
So, it is possible you "grok" everything quite well (I'd guess that you do), but haven't learned all the specifics that make things tick the "Rails way."
by most webapps i mean: (r)dbms-backed, uses a fair bit of html/css (not pure js), that needs to do 'common webapp things' (authentication though fb/google/etc.; audit trails; some REST api; memcache; pagination; ...)
going back -- to php, jsp or even (albeit less so) django -- would complicate things for me.
i feel at time rails might seem to take up a lot of time; but actually it is web development just being quite laborious, and rails one of the best fw to "take the pain out of it" and "providing sane defaults that can be changed where you see fit".
I figure that infrequent users like us aren't who the Rails core is catering for, and that's fine. It does feel like a slow reboot coming back to Rails every 6-12 months for small projects, but I still recognise that it's a great framework that solves a lot of problems.
When making a decision on what technology to use, I often consider Sinatra for its simplicity. Rails feels like a black box to me at times - again, likely not a problem if it's your bread and butter.
It just sort of comes with the territory that being a good Rails developer means being a polymath.
Rails developers need to wear lots of hats to get their jobs done. They need to be "good enough" at each of those. That, in itself, is a difficult enough task. You don't need to go trying to claim they do full time level work for six different jobs.
If you go with rails you still can get to a point very quick, with the downside that you have to spend time for upgrading. But both the elegance and maturity of rails 3, in regard of it's age is quite unique. The older it gets the prettier.
[2]. Agreed. I've been working both on client projects and in startups. If you have 10 Rails projects from clients to support, this is a nightmare, (rails 1.2 - 3.0, from mongrels to passengers). It's hard to charge clients for a rails upgrade.
[3] I developed rails since 0.14 full-time. I think rails was/is very conservative regarding trendy things (except coffeescript).
Pointing out the obvious here but using matured languages/frameworks tends to have less of this problem.
It's like dating: stable -> boring and reliable while dynamically changing -> exciting but scary.
What frameworks, in your opinion, are stable, relevant today, easy to use, and has a good community?
I've been doing some client-side scripting with Ruby lately just for fun and I've also played with Python in the past. I haven't used Rails or Django. After reading all of this, I'm leaning towards Python/Django but haven't used neither web framework I'm curious as to people's opinions.
I can pull any one of those sites up today and make changes using the latest and greatest features of C#, and they won't complain. Or I can pull out the cruftiest bad practice from .NET 1.1 and have that work too.
Django has a good reputation for API stability, and has fantastic documentation (Rails has caught up, but for a long time Django was a standout). My 1.1 books still work for 90% of 1.3, and the 1.1>1.2>1.3 release notes explain and offer solutions for any changes they make (such as class-based views).
I dabbled in Rails & Django over the last 2-3 years, and took a big detour into Rails a few months ago. I like the conventions, but it's easy to get distracted when looking for plug-ins/gems to solve your problems. Every time I look back at Django, it takes me half a day to get back into the flow. Rails, not so much.
2) Disagree here. Sure, you can't forget about it, but Rails 2 is perfectly useable. I'm currently managing a fairly substantial mix of Rails 2 and Rails 3 apps for various clients. If 2.3 works fine for them, and they want a minor feature every few months, it's just not worth the cost to them to upgrade. Sure, if major security holes emerge, patch and upgrade.
3) Agreed. I have a big gap between "things I play with on personal projects", and "things I'd use when I'm being paid at work". When I'm writing things for a client, I want battle tested code that I can predict against. I want to be able to say "That will take me a week", so I can bill, without the risk of going overbudget. If I take a new and shiny framework, and as a result of bugs in their code, or lack of documentation/6 month old blog posts being totally redundant and wrong, I end up slipping on the deadlines, that's not a situation I want to be in.
The thing that I really like is that Rails 2.x worked. I've got github, which stores old versions of gems and plugins for me to grab. I love Rails 3, and I teach new developers on it all the time, as I think it's far easier to learn and far more intuitive than Rails 2, but with Rails, I can take advantage of a fast moving easy to write system on new projects, while not getting screwed over on the old ones.
2) This couldn't be more incorrect. I'm not sure where you got this impression, but I have several apps in production I haven't touch in over a year. I don't even think I've bounced any services like apache or passenger on that box in over a year. I didn't do anything fancy to make this possible. Are you constantly upgrading your apps when new versions come out? Would you do that with a production EJB app?
3) This is true, but isn't specific to Rails or Ruby developers.
One thing I'll say is that Rails 3 definitely has a higher learning curve than 1 or 2 did. I think that's just the framework growing up though. It's a pretty complicated area of development if you want to build a decent sized app. If you're building something really simple and small, rails 3 might be overkill, at least for the time being until it settles down a bit.
There's a need for a central Rails reference that makes this task trivial. Maybe a document with some sort of interactive diff functionality that allows to see specific version differences side by side in a friendly manner. Some system that doesn't force the writers to re-think a full document for every version, that can evolve without erasing older information, and that assists the reader by showing specific chunks of information that she should read in order to catch up to the specific version she is aiming for. Getting this started is a non-trivial task, but it seems like there's enough energy, innovation and attention to detail surrounding Rails to solve this problem.
I couldn't explain the dearth of documentation for these changes at all, it seemed so lax compared to other platforms. Then I realised all the incentives for those who would produce the documents were towards producing books and paid-for screencasts, and knew my time was up.
The one point Yehuda's making I'd dispute is the impact of Arel.
I saw a very early version of Arel back when I was maintaining DataMapper. To be clear, Arel is beautiful code. It's ridiculously well done IMO from an OO stand-point. It's the code I wished I could write in DM.
I didn't use it (or something like it) in DM because I'd been there and seen the consequences. To give the point some context, you might expect NHibernate to impose a 10% overhead on c#. NHibernate is a very complex library, doing a lot more than most (any?) Ruby O/RM. In Ruby, once you get beyond the most trivial examples, you can easily see numbers like 50% overhead, and some queries that would be a cake-walk in .NET are impractical or even impossible in Ruby with constrained resources or service timeouts.
Ruby method dispatch and object instantiation is slow. Damn slow. Ridiculously slow.
The reason DM and now AR perform two-query-eager-loads to avoid JOINs has almost nothing to do with database performance. I doubt many Rubyists really understand or grok what that means. It has everything to do with the instantiation and even simple iteration of a cartesian product in Ruby being infeasibly slow.
Getting back to Arel: It's probably the very best of Rails OO. But that it's introduced some very serious performance regressions is no surprise at all. I said as much to NK and Yehuda when we discussed it during DataMapper 0.9 development.
With Ruby you have to make compromises. Especially in such a critical-loop portion of your stack.
On the other hand, if you're going to stay with AR, then it probably needed to happen sooner or later.
Best of all worlds would have been to drop AR altogether and promote a migration to Sequel for the official Rails O/RM. ;-)
I'd love to hear some practical limitations that applications using Ruby and NHibernate face when querying data.
Is this slowness a reason that so many no-sql engines seemed to have sprung at the same time as RoR?
https://gist.github.com/260280
Edit: Ran it with AR 3.0.7 and 3.1.0.rc4. Granted, this is with a 2-years newer CPU, but 3.0.7 is a huge step up. 3.1 seems to have regressed again, I'll ping tenderlove about it when I see him.
There are still some issues, but there is still low-hanging-fruit as well, such as Aaron's work to add prepare statement caching to Rails 3.1
As a side note, we need to start keeping benchmarks like this and graph over time. We (rails core) should know about regressions like this before the general public.
Take a peek at Paul's benchmark. Iterate and instantiated 100K empty objects in 10s. That's crazy. You're talking about something that would probably take 1ms in c#. You're talking about a performance deficit four orders of magnitude large.
Regardless, I think you've entirely missed the point. The point is not that the O/RMs generate inefficient queries. They may not be perfection, but for what you're asking of it, by and large the queries are not the issue. We're talking about raw method-dispatch.
This simple benchmark takes about 600ms on my MacBook Air:
require 'benchmark'
puts Benchmark::measure {
i = 0
1_000_000.times { |x| i += x }
}
using System;
using System.Diagnostics;
namespace dispatch {
class MainClass {
public static void Main (string[] args) {
var s = new Stopwatch();
s.Start();
var x = 0;
for (int i = 0; i < 1000000; i++) {
x += i;
}
s.Stop();
Console.WriteLine(s.Elapsed.ToString());
}
}
}
You could argue that it's not exactly identical code, but it's fairly idiomatic I'd think for each language.
The point is, the sort of performance deficit you carry with Ruby has real consequences. You don't have to dig very deep at all until such concerns are no longer academic. There's financial applications I've worked on in c# doing transaction reporting with 1,000 rows or so per page that would simply put be at a severe handicap under Ruby and it has nothing to do with the RDBMS.
I'm certainly not gonna give Ruby up any time soon. But it's important as a developer to at least be aware of the shape of the box you live in I think.
public class dispatch {
public static void main(String args[]) {
long s = System.currentTimeMillis();
int x = 0;
for(int i = 0; i < 1000000; i++)
x += i;
System.out.printf("%d in %d", x, System.currentTimeMillis() - s);
}
}
using System;
using System.Diagnostics;
namespace testspeed
{
public static class Extensions {
public delegate void Action();
public static void Times (this int numTimes, Action action)
{
for (var i = 0; i < numTimes; i++) {
action ();
}
}
}
class MainClass
{
public static void Main (string[] args)
{
var sw = Stopwatch.StartNew();
var x = 0;
1000000.Times (() => x += 1);
Console.WriteLine ("{0} in {1} ms", x, sw.ElapsedMilliseconds);
Console.ReadKey ();
}
}
}
Still, it should take the blink of an eye, not a chin-scratch.
Either way, nice observation. Interesting.
puts (1 .. 21).inject :*
puts (1 .. 21).inject(:*).class
Simple math operations are an admittedly terrible way to demonstrate the point I was trying to make (method dispatch and object instantiation overhead). Dismiss it, accept it, or dig deeper verify it. :-)
It's been very exciting for me. I picked it up in about a day, asked some questions, and am now easily doing things I couldn't before, and it just works.
Did you know Sequel's open bug-list is often at zero open issues?
Tried AR but it blew my mind that after all this time the support for CPK is still MIA? It's not about Opinionation IMO. Sequel has opinions. It also has features though.
DM had a few bugs. I asked about the particular relation I was trying to get working in #datamapper and Jeremy suggested Sequel would do it easily, pointing me to the test for it on github. So I tried it on a whim. And he was right, it worked.
Then I saw the documentation. It's beautiful. Seriously. Makes my eyes water just thinking about it.
That Sequel isn't the default O/RM for everything-Ruby just goes to prove there is no justice, and no Santa Claus. I'm not always 100% in love with the syntax, but the documentation, the support, the features, all that means so much more than wether I get to define properties for my models or not, and it's not obtrusive.
Oh, and disk-space is cheap. I appreciate that Sequel doesn't break itself up into 500 gems. That really annoys me about DM. There's no excuse for that outside of database drivers (and yes, that is absolutely my own fault; but it should get fixed...).
Of course it is by no means a scientific or fair comparison, but still makes me wonder.
Indeed. Or decouple the ORM entirely, though that likely removes a key aspect of what Rails is about.
It is, however, what makes Ramaze so appealing. No coupling to any ORM, but there is a community inclination to use Sequel (so you can learn from example and there are people to answer questions).
there is a default to AR which is easy to overwrite with your ORM of choice (which often provides an ActiveModel interface and further rails integration by installing one extra gem).
tl;dr: providing sane defaults != strong coupling
The few times I've wanted to just start a Rails app with simple Erb, with models representing data concepts (but not necessarily SQL anything), and evolve out to using a database (if and when needed), have been frustrating.
It's something that has been easy to do in some other frameworks so I tend to see Rails as almost DB-required, if not in fact coupled.
If you're planning on using a DB eventually but don't want to deal with migrations etc. for now, then start with a NoSQL DB like MongoDB (you don't even need to describe your fields, it can be completely dynamic). You can always sub in an RDBMS later on if your design calls for it.
Works well, just don't require ActiveRecord and hey presto, your app doesn't have a database (or db rake tasks, etc).
Interesting that people do though. Any particular reason? What features of Rails did you still use? Seems like an odd use case.
My current project is over 4 years old, started in the Rails 1.2 era, 100+ models, 30+ gems, 50k LOC, and I can vouch for the pain that the Rails 3 upgrade caused. That said, the upgrade gave us a lot of immediate benefits: the rails_xss upgrade forced us to close a number of small XSS holes that we probably never would have found otherwise, the Bundler upgrade solved several real-world deployment issues that led to downtime over the years, ActiveRecord 3 allowed us to clean up a ton of hairy querying code we had written with its fantastic composability and laziness, the modularity and instrumentation allowed massive logging and generator improvements to be inline with project standards, the ActionMailer API allowed us to significantly DRY up our extensive email notification suite.
In short, Rails development is still definitely heading in the right direction for my organization. There's no doubt that API stability is better in many other frameworks, but as Yehuda points out here, the changes made in Rails are done for good reason that can benefit a lot of people. If stability is more important than agility for your project (without disparagement), then Rails is probably the wrong choice (I tend to use PHP in those cases).
Lets start with this ...
"The Rails core team does seem to treat the project as if it’s a personal playground"
This was said more in frustration with the coffeescript/sass decision than any real belief that it really was the case.
I understand it may be hurtful and disparaging of the amazing effort that the Rails core team has dedicated to making Rails fantastic, and I apologize unreservedly.
With respect to outlining the changes (prototype to jquery etc), I'm not complaining about the changes per se (because I like most of them), what I'm complaining about is the pace of the changes.
Something as major as the asset pipelining feature (where you move assets out of the public folder and into the app folder), for example, seems big enough that it should be a 3.2 release not the next release after an already major change in 3.0.
See what I'm saying?
I haven't worked on the Rails core, so this can be taken with a pinch of salt, but I feel like it would be a good idea to adopt the Intel tick tock refresh style of cpu releases http://en.wikipedia.org/wiki/Intel_Tick-Tock, where major releases come out on the 'tock' and are refined on the 'tick'. That would work well for Rails releases, giving major releases enough time to settle into the Rails consciousness before the next set of changes comes down.
It was great to get a thorough explanation of the rationalization behind the decisions that have been made recently, it would be awesome to see that increase in frequency.
I just want to thank the Rails team for all the hard work and have them understand that while I may argue hard for what I believe, that I have nothing but the highest regard for them.
What's the difference between putting it in 3.1 vs. 3.2? Is the 3.2 version number somehow more substantial than 3.1?
Also there have been quite a few releases after 3.0 - I believe the 3.0 branch is up to 3.0.8 now.
---------------------
The time between releases.
I guess I'm basically just an end user, I like to use technology that's vouched-for and I trust the Rails team. Rails suits me.
I don't need help upgrading. I just think the Rails core team should do releases in such a way that big features which drastically change the way Rails does things, aren't put in the pipeline back to back, like this was (3.0, then 3.1) that way Rails doesn't get a reputation for constantly redoing the "Rails Way".
Either you can go the Microsoft route and be backwards compatible til the end of time (which is great for devs, but causes baggage) or you can embrace change while the community is still young(ish).
It seems like at a minimum, everything in a major version should be backwards compatible (ie a 3.0 project will work in 3.1 without changes) though.
Either you can go the Microsoft route and
be backwards compatible til the end of time
Yes, they are shipping the DLLs till the end of time, but you can also find the source code to Rails 2.3 till the end of time (it's right there, in your face), just as you can find the source code of Linux 0.01 (the initial release).
On the other hand, what's the latest recommended path for building UI, the Microsoft recommended way? The Win16 API? The Win32 API? MFC? WTL? Windows Forms? WPF? Silverlight? HTML5?
Evolution happens, you need to deal with it. The only stable API I know that is still relevant and still important to learn (instead of an abstraction) is POSIX-stuff.
And ASP.NET MVC is different and whatever compatibility it has with ASP.NET is actually hurting, IMHO. I mean, here's a framework with potential, but it has to carry the old bagage of ASP.NET from the start.
I get it that a framework like Rails moves TOO FAST for its own good, but nothing compels you to upgrade right now. Lots of people are still on Rails 2.3, it's a stable and reliable version and if you'll look around many projects have 2 branches, one for 2.3 and one for 3.0. And some of the projects, especially Rack middleware, don't need 2 branches.
It kind of sucks from one perspective - the 2.3 branches are going to receive less patches/upgrades, but you have the source code. If something really important is missing, or there's some unfixed bug, you can go ahead and fix it yourself.
You can't say the same thing about a binary DLL. I remember when I first tried out ASP.NET 2.0 - it contained an annoying bug related to their CSRF protection (if you clicked any control before the page loaded, it triggered an error since the CSRF token was getting loaded right before the </form> tag, at the end of the page), and it took a service pack and 2 months to get it fixed.
On the other hand, I've used web frameworks (mostly Symfony but also a few others) that look awesome in the beginning, but that require major changes when an update needs to be made a year later, because the latest and greatest has changed and the old is no longer supported. And they all support 'plugins', but you're fucked when you use them - sometimes they're upgraded, sometimes not, but when you use a couple you're always stuck; you need to upgrade the framework to use the latest version of one plugin, but another one only works with the old version, so now you need to replace all uses of that plugin with another, and change all the code...
Anyway that was a tangential rant, but Microsoft is really good at keeping a stable dev env, as long as you don't always use the first version of their new shinies (Windows Forms, ...)
But HAML feels like such a vast, unambiguous, never-going-back improvement over ERB that I am honestly baffled Rails hasn't adopted it. It's at least as big a win as Sass and CoffeeScript, if not bigger.
I agree with Katz here. If anything, Rails has shown remarkable restraint in the face of a smorgasbord of shiny, new, and often superior, competing technologies.
http://chriseppstein.github.com/blog/2010/02/08/haml-sucks-f...
As a result, though I love Haml, I think ERb is a more sensible default.
For the few cases where that makes sense, ERb is great. But I have a hard time imagining it's common enough to make it the default.
Edit: Also, the post you linked to outlines several simple ways to mix text into your HAML (inlining HTML, using markdown filters, etc)
(I say this as someone who loves HAML and uses it almost exclusively).
HAML feels great for me as a dev vs the verbosity of hand-hacking HTML, but for the guys who spend 90% of their time in photoshop and 10% chopping their PSDs into static HTML to hand to me, I'm not convinced it's worth the lost productivity to teach them a new markup.
Speaking of which, HTML2HAML works nearly every time.
We're not having any problems with HTML that HAML would solve.
HAML, though, shares the same fundamental problem with ERB: it's straddling the code/template fence. I wrote the Hoshi ( http://github.com/pete/hoshi ) gem to address this, and used it in the last Rails application I wrote (still in production), and still use it for HTML when I need that. (It's still in the "personal itch" phase, so it's only maintained when I notice that W3C doesn't like something or when I'm missing a feature. For example, I haven't done any HTML5, so I haven't put any in.)
For anything requiring a wall of text (in HAML, ERB, Hoshi, whatever), I think it's a mistake to put it into your view code. Make a place where copy goes, decide on a markdown format, and write a helper that pulls in and processes that text. Even if the coders are writing the copy, it's helpful to have the text seperate, and easier to edit besides. And if it turns out that you need the text editable via a web UI or something, it makes the change easier: modify the helper to fetch text by name from the database rather than the filesystem, and import all of the text into the database. Everything is easier all around; I'm at the point where it looks like a code smell when I see walls of text (or frequently edited text) in a template.
Also, DHH chimed in and offered some awesome advice that I didn't know about:
rake assets:precompile will automatically copy images from app/assets/images to public/assets.
Moving from Rails 2 to Rails 3 is a nightmare, a documented nightmare in 3 parts http://goo.gl/2Xw7n
Sure you can get part of the way by porting to bundler and upgrading to ruby 1.9.2, but there is no plugin or way to have an app work with both Rails 2 and Rails 3 at the same time. And this is a year after it was released with 3.1 just around the corner.
For the upgrade you need to change boot.rb, application.rb your routes and all your other configuration. Potentially you may need to update a ton of views to allow for the xss protection.
By themselves none of the changes in Rails 3 are bad, its just that somehow they managed to make it very very hard to upgrade, so less people use it, and it gets less testing and stuff regresses.
I think if the team focused on a bridge / integrated upgrade path for rails 2 that allows you to switch to rails 3 seamlessly it would do wonders for adoption.
This isn't particularly accurate, my understanding is that what became the 1.9 VM was originally an external fork (or rewrite, I'm not clear on which) known as YARV, which was later integrated, but was not originally developed by the MRI team. As always feel free to tell me I'm a moron who has no idea what he's talking about.
From my perspective as a serial startup founder, I won't touch the platform because startups must innovate or die and to enforce too much discipline on the way things are done within a platform is to risk killing innovation.
The best startups not only use platforms in unexpected ways, but are platform agnostic and use multiple platforms that probably didn't expect to have to talk to each other.
Startups choosing Rails need to remember that 37Signals have a group of mature apps that are maintaining and incrementally improving with (I'm guessing) growing team of devs. Their apps are also B2B and have relatively low traffic compared to many consumer focused startups. Their focus is code and team scaleability. They aren't rapidly prototyping or rapidly innovating. Also as the center of the Rails community, they don't need to care that Ruby devs are harder to come by than PHP or more mainstream languages.
Rails also strikes me as a rockstar dev culture that puts marketing, innovation and being perceived as a thought leader ahead of everything else, including the boring crap like productivity, simplicity and performance:
http://www.flickr.com/photos/46457493@N00/4441909186/in/set-...
Point being, Rails' first priority is to improve developers' productivity, sanity and happiness - all developers using it, not just new ones.
I'm not by any means a Rails fan, and think that even now, it feels like a PHP framework. (I have a "competing" web framework that I wrote and use whenever I have the flexibility, if you can call it a competitor; it's not actively promoted and the users number in the low single digits). But they do deserve credit for making sure that it's easy to figure out how to get things done.
compared to what? Have you tried to learn Spring MVC? No way rails is harder to learn than that. Are you comparing it to no-framework php files?
Forgive me, but I fail to see how the main point of the original article is even valid.
I think that Rails is hard to learn for several reasons:
* unless you've used it before, you have to learn Ruby too
* Rails is fast moving and has a lot of pieces
* the error messages can be cryptic and hard to decipher
I've been developing with Ruby and Rails for several years now and I still encounter cryptic error messages.
As a newbie I found it incredibly frustrating when Google did not bring up an immediate answer, it basically built a brick wall around me. I don't think this is Rails' fault per se, it's just the nature of the beast.
I have found those additions worthwhile. The work I've done in Django has gone a _lot_ faster, and I think better written, for the orientation to REST and TDD.
Perhaps real devs with more experience find these pieces less helpful and more intrusive?