Piotr Sarnacki home

I'm writing a book about Ember.js. Sign up here for a notification email if you are interested.

I'm tired by "Rails should fundamentally change" crowd

I read How can Rails react to rise of the JavaScript applications? by Andrzej Krzywda recently. A part of the discussion in the comments derailed into more general question of “Where is Rails heading?”. As @solnic mentioned in one of the comments: "These days I'm pretty sure Rails will not change much. I said this many times in the past and usually I was "attacked" with arguments that it improved a lot in 2=>3 transition.” and then Andrzej added "People often say - if you don't like something, write a pull request. The thing is, if I fundamentally disagree with some architectural choices, then it has no chance of being merged in.”. I began to write a comment, but it started to get longer and longer and I felt that for the most part it was not really targeted at their comments, but at a general trend to complain about a state of Rails architecture and the lack of support for the new architectural goodness (insert here any of the things like SOA, DCI, hexagonal, DDD etc. etc.).

Before I start: I’m not a part of Rails Core team and they may totally disagree with anything I say about Rails here, don’t treat it as something which is a definitive scenario for future Rails development. I'm also not targeting Andrzej and Piotr with this rant, I value them both as great and experienced developers, far better than me. This post was sitting in my head for quite some time now, they just happend to trigger it.

I like the idea of Rails being a set of decoupled APIs, which can be used in various ways. For most users it doesn’t matter, but if you like to experiment with the framework and use it unconventionally it becomes quite useful. In fact, quite some time ago I started decoupling Action View from Action Pack, which was later extracted by Łukasz Strzałkowski as a part of GSOC 2013. I wanted to extract Action View from Action Pack specifically because I care more and more for APIs which either doesn’t use views at all or use them in a very limited way, where much simpler solutions like Tilt could be used. Does DHH care about this? I strongly doubt it. Is it ok? It is totally ok in my opinion.

Now let me tell you how I use Rails nowadays. I tend to write small API applications, which are usually consumed by Ember.js web interface. For example with my recent pet project (which I also decided to turn into a product after I realised that I work on it for myself anyway) a flashcards application with a builtin dictionary I have a set of 2 API apps with a frontend application in Ember.js, which does not even live in the same directory as an API. In essence - it has nothing to do with Rails. I could swap an API with Go powered version and as long as it’s compatible the client wouldn’t care. I use fixtures for testing, I use test/unit, I write integration tests and I generally go “Rails way” (well, not fully, because it’s just an API, but you get the point). Do I use services or DI or other techniques, which become more and more popular recently? Sometimes I do. And sometimes I don’t. For example I created a few services in one of my apps just because I anticipate using them from the console rather than putting them in the API - those will be mostly “admin” actions and I don’t have time to build any admin interface at the moment. In summary, I don’t use server generated javascript, but for the most part I use Rails conventionally.

Am I happy with Rails? Yes, in my opinion it gives me a nice balance between flexibility and a set of conventions, which lets me use some of the patterns I like and in the same time it lowers the time to ship.

Let’s get to the main point of this blog post now: should Rails change its’ architecture? I don’t know. What I know is: it’s silly to expect people who are perfectly happy with their tools, to change those tools fundamentally. DHH, core team members and quite possibly thousands of other developers are happy with Rails more or less in current form. It’s easy to fall into assumption of a community moving in a completely different direction, because you don’t see a lot of the posts enthusiastically shouting “Hey! Look at me, I use Rails just as people used it for years!”. It’s not really interesting and I doubt you would get to such a post through your social circles or RSS readers, especially if you’re leaning towards new architectures, hexagonal, SOA, DCI etc.

I want to be clear: I’m not saying that majority of people use Rails in “standard way”, but you shouldn't be saying otherwise either if you don’t have any data to back it up other than the number of your friends talking about it.

To sum this part up: I’m sorry folks, in my opinion there is a little chance of a fundamental changes in Rails. It’s certainly possible, but not likely, at least not in a near future.

The faster you acknowledge that fact, the better, it will help you with further moves. I don’t want to be all negative and unconstructive, so let’s see what may be done in the current situation. Just to be on the same page: I will be talking mostly about non-AR parts of Rails. Active Record is already dead easy to replace by any other ruby ORM out there.

First thing is that I saw a lot of the posts praising new approaches to web development, but I haven’t seen a lot of specifics. Especially when it comes to things that should be changed in a way Rails works. I agree with Andrzej on the fact that preparing a pull request, which would introduce fundamental changes will most probably be a waste of time, but there is a lot of ways you can tackle the problem. You may introduce a lot of new things as long as APIs on top stay untouched.

In fact, you don’t even have to write a pull request. It may be a technical proposal with a specified API and a description on how Rails would benefit from the changes. Information on backwards compatibility would be nice as well. Maybe you can change a lot of the lower level APIs to suit your needs while keeping it backwards compatible? I would love to see at least one proposal like this. I know that it still may be a waste of time, in a sense that it won’t be accepted, but for all I know there was no such proposals regarding Rails architecture. Of course it’s easier to say that Rails is dead, that it’s lacking and it’s going in the wrong direction, but how do you think this can be changed if everyone just repeats the same mantra?

I am aware that changing Rails in a way it stays unchanged on the surface may be limiting. In theory lower level APIs could be extended a lot without changing abstractions which developers use, but if you want fundamental changes you will hit the wall sooner or later. What to do in such case? Well, you know already that forcing such ideas to Rails may not be an option. I believe that in such situation the best way to proceed is to change the framework. There are a few other options when it comes to frameworks not getting in your way a much as Rails does: sinatra, webmachine, maybe padrino. If you want to write framework independent applications, why do you want to stick with Rails so much? Write an app, preferably open source, write a case study, show others how can other apps benefit from the choices you made. Maybe you will convince someone? The problem with all the new approaches to building web applications is that I don’t see a lot of real world cases. I saw applications presenting a new approach a few times, but unfortunately most of the time there is no docs, no overview, no description and usually it’s just a first draft, a hello world of sort. Do you think that something like that can convince long time sceptics? You need to try harder.

I hope that I will see more action and less complaining in this new year, let's make a Rubyland a better place! Even if this post sounds like a rant, believe me, I really want to see new exciting things and I would love to see cool changes in Rails. The problem is: we need to see more specifics.


If you liked this post consider following me on twitter.
blog comments powered by Disqus
Fork me on GitHub