I've been doing Rails since 2006. My skill level and the framework as changed greatly since. I came from PHP web sites and Java through academics. Ruby was breath of fresh air. Rails was a thing a of beauty. It was exactly what I needed at the time. Now times are different.
A Changing Web Yields Changing Requirements
EDIT: I've written a follow up to this post that can be found here.
I was coming from PHP. PHP was shit then and is still shit now. I just
I think this is a common story for many Rails guys.
I didn't realize how shitty PHP as language was until I started learning
Ruby through Rails. At the time, Rails was exactly what many devs
wanted. It made common tasks like generating basic CRUD interfaces. You
could simply scaffold and start building (but I never recommend that),
but you could do it. It made managing a DB easy. There was
schema.rb. There were ActiveRecord associations. ActionController and
AJAX handling. It did everything and it made a huge splash in the
industry. Rails made such a big impact it was able to drive the growth
of 37signals into a major powerhouse. There are hundreds of committers
and the framework is still very popular and useful. It made building Web
2.0 quick and easy. Hell, the generated application greets you with:
"you're riding on Rails."
I look back on those days fondly. It was a much more simple time. The barrier to enter the market was low. You could churn out SaaS services so quickly. Generate a rails app, throw up some scaffolds, and boom. There ya go. Zero to sixty faster than an R8. Now things are different.
Think back to when Rails first came out. There was no iPhone. There was no Android. People still owned Nokias and actually bought stock in the damn company. Windows XP was still massively popular and we were fighting to get a decent version of IE (but that will never end). There was no such thing as a mobile web. No one was thinking about tablets. How old is the iPad? Not very old. The web has drastically changed due to the smartphone explosion. This is only the first step in a true multiplatform internet. A few years ago you could get by with having a mobile version of your web app. Now that's not enough. That concept is almost laughable today. The bar is set pretty high. People expect applications for different devices. This is unfortunately our fault since we've trained them. I was just on lemon.com while showing it to my boss. There is a huge picture of numerous devices. People are off their computers now. Now it's simply not enough to build a web application. You need to build a service. You need to build your own platform to build your own applications off of. You will not survive if you don't. The changing web yields new requirements in how we design and structure modern applications.
SoA Platforms then Applications
Service oriented architecture has always been very fascinating concept. Jeff Bezos was way ahead of his time when he basically pulled a Hitler and dictated that everything would switch over to SoA. We are at point in the web where platforms represent core business value. You need to have a platform that's accessible on any device either natively or with a browser. So now you're faced with a question. How can you develop your platform and expose to different devices: HTTP. I like HTTP and I make my platforms speak HTTP. We can use HTTP to create JS applications for browsers. We can also use HTTP to communicate with an external system through OS level code. You can build a native application on Android backed by an HTTP service. You can build your JS application backed by HTTP. Don't think that the browser is the only answer. Not every single application can exist in the browser. What if you need to write files? What if you need to access hardware? The browser is not the be-all & end all of internet applications. People will always be creating native applications. So don't look at everything purely through the: HTML5 and JS lens. Sometimes applications need more.
HTTP Backed Services
HTTP backed services are inherently easy to write and manage. They are
much easier to write than traditional web applications because you do
not have to worry about V--just MC. From my experience, generating a
good UI (V) takes orders of magnitude more than implementing M and C. HTTP is
perfect because you only have to worry about garbage in and garbage out.
In Rails, this means you really only care about
respond_with. Data in and data out. Now, when I look at these API'S I
look at the responsibility to the end developer: return JSON. That is it.
A single focus: return JSON. Of course there is processing involved but
the main point is return JSON that end application can use for it's own
purposes. That makes developing this very easy because it removes many
other requirement and makes you think about a fundamental thing: HTTP is
only how the outside talks to my code. My application is not HTTP and
it's certainly not just HTML and JSON. This is only how I talk to the
outside world. The code can be something totally different. You could
have nginx talking to a haskell application. No one cares as long as the
parameters and data coming out are according to spec. This has been
extremely freeing for me because I no longer think rails is my
Changing How We Code
Avdi Grimm verbalized some of my current feelings in this regard. His object on Rails paper goes through the entire process of creating a blog using OOP techniques. The code is developed completely outside of Rails. Rails isn't even introduced. Models are derived completely on their own. Collaborators and responsibilities are defined as well. Slowly the system takes shape. First you need ActiveModel for some validations. Everything is going well. Eventually you're going to need persistence. He treats persistance as an implementation details Mdoels are more than ActiveRecord! Your code is more than Rails. Rails is not your code. You can and should develop the business logic completely on your own ISOLATED from whatever code you'll eventually use to allow the outside world to consume your service. Corey Haines started something called fast tests. Fast tests are great. Everyone loves them. They make tdd faster blah blah. His essential point was to move code out of Rails into Ruby modules that can be tested in isolation. This is a step in the right direction but I think it's a very small one. You should go all out and simply move your code out of whatever framework you're eventually going to use. I highly recommend Avdi's paper on Objects on Rails to see a very refreshing approach. The continuing theme here is dividing parts of your eventual platform. Most important is splitting access from application.
Moving Away From Rails
Rails has always been fantastic at one thing: accepting, handling, and returning body for a HTTP response. What you choose to put that body has always been up to you. Just recently, it's been assumed you're going to generate HTML. Now I just want to generate JSON. Designing my HTTP based services only require two things:
- Accept http requests
- Give me a nice API for determine response code and response body.
Rails has always been fantastic at those two things. But now, I do the rest. I'm not really worried about ActiveRecord. Let me handle the models. I don't need ActionView. There are a lot of things I don't need from Rails anymore. I think that's good. What makes Rails 3 great is you can modularize it by removing (or including) components. Now I can get the most out of Rails by making it fit my requirements. But that's it. I no longer think Rails is my application. It's just a nice thing for handling how it's accessed.
Moving on in Life
I've become increasingly disinterested with Rails over the past while. This is nothing to do with the framework itself. It's just no longer related to my core interests. A few years ago, it was my only interest. It was simply how you build web applications. That time has come and gone. Now we are faced with applications with more diverse requirements. You may have a Rails based application for handling the majority of web requests working in conjunction with a Node process for evented stuff. Hell, you may at some point even have processes in different languages which have been optimized for different things. Look at Twitter with Scala. There are many permutations of different technologies for different requirements. There will be more permutation as the way we architect the modern web. For me, and I think many others, Rails will become and increasingly smaller piece of the puzzle. Why? Simply because their platform is more than Rails. Now I focus on other questions. Rails answers some of them, however I'm finding it's the answer less and less.
— Adam Hawkins