This is an opinion piece. The following is my opinion. I don’t need to yuck your yum; if you love Rails and you think Rails is great, then that’s awesome for you. I’ve had a lot of great experiences with it in the past. These are my thoughts, for me. I’m not stupid enough to say “Rails Considered Harmful!” or anything stupid like that; it’s still a powerful, popular tool. But here are my thoughts about it:
I know a ton of languages. I know a decent number of frameworks. I have been working with Rails since like v1.0 or something.
I remember when I first started using it; it was amazing. All this stupid boring shit I had to do in PHP to get a database connection, grab results, put them on the screen, make forms around them – everything – could now get done in a ridiculously tiny fraction of the time. It was truly world-changing, and it made total sense that everyone was going nuts over it. As well they should.
Ruby, the language, is a bit slow. So what? Just run more servers. And I agree with that. I mean, if I can make my programmers just 2x as effective and make my server bill 10x as much, it’s still a steal. I have no problem with that math at all.
And there’s much to be said for the language and its elegance. Everything is an object. Classes are just more objects. Class methods and all kinds of other things are great too. Everything you would want to do to a string is a method in the String class. It’s really quite pleasant to read.
But I remember the first time I ran into something weird and magical in Rails that freaked me out. I was trying to troubleshoot why this one field kept outputting as a date, when it was actually a timestamp. I mean, the field’s name happened to be
date but that was a legacy issue I just needed to live with. The name of a thing shouldn’t affect what type of thing it is, right? Eventually I renamed the field to
fuck_you_rails_you_piece_of_shit and suddenly it began working. Too much magic.
But, still, I was far more productive with Rails than I was anywhere else. I’d looked into PHP frameworks at the time and they did not come remotely close. They seemed to just add complexity and not take anything away.
So I kept holding on to my toolset – Rails for anything with a decent amount of MVC-ish complexity; PHP for little one-or-two-pager apps that I need to bang out real quick. And that served me well.
That being said, Rails began to start to show some real problems for me. Upgrading an app I built from Rails 1 to Rails 2 was a pain in the butt, but I was able to do it once I spent enough time. Upgrading that app to Rails 3 was nearly impossible, and I had to just completely back out of the upgrade once I was around 6 hours in. The documentation was constantly changing. What was once
rake console now suddenly became
rails console and it’s not like the error messages were very clear about that either. A friend of mine tried to run through a Rails tutorial and had a horrible time of it, so he gave up. He wasn’t the best programmer in the world, but still. Keeping Rails running was also nightmarish, the best solution I had come up with at the time was Phusion Passenger, and that was OK. But getting code deployed was really difficult and generally very unpleasant. I was starting to feel like “Rails makes my developers 5 times more productive!” was still true, but conversely, “Rails makes my operations engineers 5 times less productive!” was also true.
And as Rails grew larger and more popular – and was still dog-slow – it started to have to add even more features around its miserable slowness. Rails got the Asset Pipeline. And support to push everything into CDN’s. Certainly, those are scaling issues that need to be handled, but Rails by default handled it sooner to try and make up some of that lost time. Now we have “Spring,” which means every command I type I have to preface with
DISABLE_SPRING=1 or else I get hard-to-debug errors and lose countless amounts of time. Another innovation Rails has had to add is Turbolinks – which I actually think is spectacular technology – but is yet another way to hide or bury the generalized sloweousity of Rails. And the previous version completely shat up my apps; we pulled it pretty quick. (Caveat: the new Turbolinks 5 is excellent, and I’m using it in production and really enjoying it).
At some point, somehow, I got introduced to Laravel. And Laravel is all the good things of Rails and fewer of the bad things.
Yes, it’s written in PHP, and PHP isn’t a “pretty” language. Shut the fuck up, we’re not painting beautiful renaissance canvasses here; we’re putting together some bullshit web app for someone who is giving us money. Yes, there are gotchas in PHP. There are gotchas in Ruby. I spent an hour troubleshooting why some really basic, obvious comparison was failing only to eventually determine that one variable was a
Symbol and one was a
String. Or I don’t know if you’ve ever tried to use
@@ class variables, but they’re confusing, weird, and I’m still not sure I understand them completely. Everything’s at least a little weird, everywhere. And another problem I keep running into (and this may be a community problem, not a language problem) is that everyone is so fucking busy jerking themselves off to how “Readable” and “Elegant” their code is that it slows them down – “Oh, should I write this as
do_something! unless @mything.foo? or should I write it with an
if…” and then they sit around with their thumbs up their asses trying to be these lovely hand-crafted artisan hipster douchewads. Sometimes too much syntactic sugar can lead to crushing decision-fatigue.
Laravel is fucking fast. I open up a Laravel console (called “Tinker”) on Snipeyhead‘s Snipe-IT project and it pops open in a split-second. If I wanted to be distracted – and believe you me, I really do seem like I want to be – I couldn’t be. It’s just already there. Whatever thing I wanted to dick around with on the console I can just bang right out. And in general everything seems to be fast like that. We don’t have a
schema.rb file in Laravel, because you don’t need it; you can rip through a massive directory of migrations in a ridiculously tiny amount of time. So there’s no
schema.rb file to get out of sync with your other developers or any other such kind of miserable shitshow.
There’s a lot of cool stuff that saves you time, but it’s not so crazily magical that you can’t figure out what it does. When you want to say that something hasMany of something else, you just create a method named appropriately, and have it return
Deployment is still harder than a boring old regular PHP app, but that’s mostly due to
composer (PHP’s gem/bundler solution) – and I suspect that we gain much more from
composer than we lose. I remember trying to grab PEAR libraries, and other ways of tracking down dependencies. Not fun. I can still deploy an app as complex as Snipe-IT in seconds, relative to the multiple-minutes-long-nail-biting that is the Rails apps that I work with.
So far my biggest pet peeve with Laravel is the namespacing. Everything has these god-awful backslashes everywhere. Every file you edit has like a bajillion
use statements up front to load up all the namespacery. It’s annoying and ugly. And like in the early days of Rails, I still find myself occasionally digging through the Laravel source to try and figure out how something works, or what it does. But, for me, it still gets the job done much better, much quicker, and much less unpleasant than when I do something in Rails.
Oh, another Laravel peeve – I still don’t fully grok when I need to use
->get() or not. I generally try it one way until it fails, then I try it the other way. And “when to use parentheses on relations” also confuses me. But, generally, I try it one way then the other and it eventually works.
And, as a side note, I suspect you can pull together PHP programmers for way cheaper than Rails folks. So it might actually even pay off!
But that’s not why I’d choose Laravel; I’d choose it because it’s fast, saves me time, makes sense, and generally makes me feel good while I’m using it.