Saturday, December 28, 2013

How can Rails react to the rise of the JavaScript applications?

The rise of JavaScript applications is tremendous. Every week new JS frameworks appear. Every website UI is now JS-heavy.

How can Rails react to it?

Do we need to worry about our jobs?

History

Let's go back to the history for a while.

Rails was created as a light-weight, but well-structured alternative to create dynamic, db-backed, html websites.

I still own the main Rails book, that was published in 2005: Agile Web Development with Rails. I just checked, there was 558 pages of good content. Only 16 pages were about The Web, V2.0 (this part was written by Thomas Fuchs, not by the main authors - DHH and Dave Thomas). Back then, Rails supported JS via the prototype library. There was no mention about RJS, yet.

Late 2006, I bought another book - Ajax on Rails. I have it in front of me right now. This time, RJS was important already, as they wrote: "Ruby-generated JavaScript (RJS) is the capstone of Ajax in Rails". Before the concept was introduced in the book, all the server did was returning HTML snippets (data) and the JS libraries inserted it into appropriate places. No such thing as view model, data-binding, etc, yet.


Where are we now?

Rails does a really good job of handling the backend part. It's secure, based on conventions, all apps are similar, everybody knows how to work with it.

Look at the frontend part of many Rails apps, though - you don't see the conventions, you don't see the same structure everywhere.

There's this pro-Rails argument, that it's better for a startup to do Rails, because many Rails devs will know what is going on if the project is done the-Rails-way - so, it's easier to scale the team. It's no longer true, though. Yes, the backend part is usually familiar, but the JavaScripts? They're completely different in every Rails app. Often, they're like 50% of the codebase.

Some developers just hack together some jQuery plugins and call it a day.

Some developers go with DHH suggestions and use RJS (UPDATE: or clean JS returned from the server) (to be honest I have never seen this approach in a Rails app, but I'm sure someone followed DHH here).

The new trend is to use JS frameworks, like Ember.js or Angular.js, which are opinionated and feel more aligned to the philosophy of Rails (conventions, magic, implicit features).

Other developers (me included) want to control the JavaScript app and don't use any framework, relying on self-imposed architectures like http://hexagonaljs.com/.

How can Rails react?

There are some possible ways of reacting. I'm trying to be neutral here, although obviously I have an opinion on that.

1. We can leave it as it is, with [R]JS being recommended by the leader

From my observations, the [R]JS recommendation gets ignored mostly. To be fair, none of the leaders is actively discouraging anyone to use some proper JS frameworks. It's just not the main focus.

This leaves the community disconnected from the leader (which may not be a bad thing). I've met many people who are worried for the future of Rails. They're not sure if Rails is a good technology to invest their time. For such people it may mean that in the longer run, they'll prefer to focus their education on the JS part more than on the Rails. We already see the increasing number of jobs ads requiring Angular or Ember.

This way, we'll see the trend started with rails-api growing in popularity.

2. Rails can adopt/recommend one of the JS frameworks.

It can be Angular or Ember. The first one has a huge growing trend recently. Ember is led by well-respected people from the Rails community (Yehuda). It's smaller overall but quite popular in the Rails world already.

We've seen a similar situation in the history of Rails, when Yehuda created Merb and then made it to Rails (oversimplifying a bit). Can the same happen with Ember? It's very likely.

What about Angular which is becoming the default JS framework? Can Rails recommend it? There's nothing in Rails that makes it hard to develop with Angular. But Angular is not the default choice, yet. DHH made some bold moves in the past, like making CoffeeScript on by default (thank you!). Can the same happen to Angular?

3. Rails will encourage JS frameworks but stays JS-framework-agnostic.

This is more or less what is happening already in the community. People use Rails together with many of the existing JS frameworks, with success.

4. All of the above

We can see DHH keep recommending [R]JS. The Rails core will make Ember the default choice, but easy to disable it. The community will keep using Rails together with everything.

The future

What is going to happen? I honestly don't know. Rails is doing fine-enough. It doesn't need to react in any way. We need to remember that it's not only about purely rational, technological choice. Rails was always famous for its marketing. We can see some unexpected moves, like coming up with its own JS framework.

What would I prefer?

Personally, the current situation is fine for me. I ignore the [R]JS way of creating the Rails apps. I'm allowed to create the JavaScript apps the way I want. Rails is good for API. I'm fine with any choice.

However, as I said, it's not only about rational choices, it's about the emotions. Do we want it or not, the Rails community is huge nowadays with new people coming every day.

If my main goal was to keep Rails hot for the new people, then I'd suggest choosing Angular as the framework that is on by default in Rails. That would bring a lot of love to the community. Angular is loved they way Rails used to be loved.  I personally don't really like the Angular way, but this choice will be good/easy for the new people for whom it's better to follow choices made by others.

In the meantime, other backend communities keep improving. Did you see PHP and Symphony2? It's a framework which is architecturally ahead of Rails (a topic for another blog post, probably). Did you notice how popular Scala is becoming?

Should we care about the future of Rails? Is it more pragmatic to be backend-independent and start learning more about other backend choices? Should we go the microservices way and have the app implemented in several backend technologies at the same time?

Many questions, lots of guessing :)

If you liked this blog post, you will enjoy following me on Twitter.

UPDATE: I changed RJS to [R]JS in some places. It's not really RJS that is recommended by DHH, but SJR - Server JavaScript Responses - see http://37signals.com/svn/posts/3697-server-generated-javascript-responses

20 comments:

J-_-L said...

I like point 3. Let's have extra "Rails-API-Angular" and "Rails-API-Ember" gems which extend Rails-API with optimizations necessary for the respective framework (build by users of the js framework, not necessarily the rails contributors)

Andrzej Krzywda said...

Interesting idea with Rails-API-Angular|Ember, I didn't think about that. It makes sense :)

Anyone already doing this?

Anonymous said...

I think adding a front end JS framework to Rails is a really bad idea. I haven't come across a use case where a front end framework provides any advantage over the default use of UJS/SJR. It would just be adding bloat and complication.

I built a Wufoo style form builder (single page) using Rails defaults.

It's very possible I'm missing something about the front end frameworks though if someone would care to enlighten.

Drogomir said...

I highly doubt that any javascript framework will be included in rails and I would strongly discourage that. There is an ember-rails gem and it's probably not really hard to provide an angular-rails gem (if it doesn't exist already).

Regarding Symfony2, what are the things that make it "architecturaly ahead of Rails"?

Marta Ryłko said...

Good post!

Andrzej Krzywda said...

Drogomir,

I'll try to blog about it soon.

Meanwhile, you may find those resources interesting:

(hexagonal symfony)

http://www.youtube.com/watch?v=0L_9NutiJlc

https://github.com/MarcelloDuarte/hexagonal-symfony

They have a real DataMapper tool (Doctrine) which makes writing domain and services much easier than in Rails.

Also, they have a DI solution built into the framework, thus it makes handling the external dependencies much easier (you can compare it to Ruby gems being able to be automatically injected into the service layer).

Andrzej Krzywda said...

Marta, thanks, I appreciate it :)

solnic said...

I don't want to go off the track with the discussion (sic!) but I can't help myself. What you mentioned about Symfony is really interesting. It is no news to me but seeing it mentioned here got me thinking, again, about where rails is heading.

These days I'm pretty sure Rails will not change much. In fact it hasn't changed much in years. 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 now we have lots of new goodies in 4.x. So, yes, I agree, it improved...however, it stayed the same when it comes to its core architecture. Same ORM, same controller concept, same view layer with helpers.

Andrzej Krzywda said...

"Same ORM, same controller concept, same view layer with helpers."

This.

When I read your comment, I realised that those things didn't change and those are exactly the things that could be improved.

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.

There is huge value in the Rails brand - from a marketing point of view. No chance that anyone can come up with a competing Ruby stack and 'win' the masses.

I'm still hoping that something *is* going to happen in the Rails core team. I'm hoping for some brave plans, not just 'small improvements'. We need some new energy in the community.

I'm not an Angular fan, BUT, the marriage of Rails and AngularJS would be a huge marketing win for both sides.

Michał Ostruszka said...

I'm not day-to-day rails developer, just doing some small pet-projects to keep eye on stuff but I think bundling frontend framework is not a good idea. I think rich JS apps should be clients of your API only (they can even be in separate repository). Projects can still use rails and tons of its goodies for backend and just expose raw API to clients. There was also a project called rails-api but I'm not sure if it is widely used.
Also coupling yet another frontend thing to rails would complicate things even more (I guess it wouldn't be the only way, so the current view stuff would still exist).

BTW, thanks for posting the PHP Symphony2 stuff. Need to take a look at this. Haven't used PHP for ages, maybe it really matured as you said.

Unknown said...

> Interesting idea with Rails-API-Angular|Ember, I didn't think about that. It makes sense :)
>
> Anyone already doing this?

Yes, we are in a few projects already :). Good combination.

I think this is the way Rails will evolve, views layer will be moved to JavaScript along with large part of logic. If you consider Rails for building a web services, it's actualy really nice framework ;).

ankur said...

Have you checked this out: http://joosy.ws/

Pooyan Khosravy said...

Andrzej, your thoughts means a lot to us, do share them more.
I'm in for more SOA, we can use Symfony2, Scala and even Node with Rails.

IMHO coupling frontend and backend maybe is not that much of a good idea. So maybe adhering to REST is good enough?

Nevertheless we definitely need more conventions.

Andrzej Krzywda said...

Ankur, thank yout for mentioning Joosy, I'll have a look!

Andrzej Krzywda said...

Pooyan, thank you for kind words!

Yes, SOA is more interesting. I'm also involved in our company blog and we recently blogged about SOA:

http://blog.arkency.com/2013/12/rails-and-soa-do-i-really-need-to-have-this-big-app/

Patrick said...

Nice discussion.

For sure, the design of ActiveRecord and the idea of scaffolds was revolutionary back in 2005/2006. Actually, I blogged about it too: http://thinkingonthinking.com/Here-Goes-Your-Web-Stack/

To me, the influence of Ruby on programming is still very important. The idea to develop software with fast feedback with a REPL is just great.

But I can't see why the same principles from Ruby that made Rails great, can't be applied to JavaScript development too. My bet is a trend towards more full-stack JavaScript applications, one of the drivers might be the JavaScript used for better schema(-less) development with Node.js too.

Andrzej Krzywda said...

Hey Patrick, good to see you again :)

You're right, Ruby brought many interesting features into programming. It can influence the way we do JS apps as well.

The trend of full-stack JS is visible, indeed.

At this very moment, I'm playing with Opal, which, at least in theory, could give us full-stack Ruby. Quite intriguing :)

Piotr Sarnacki said...

For anyone interested in a subject of Rails direction in context of new approaches to web development, I wrote a blog post as a response to "Rails should fundamentally change": http://piotrsarnacki.com/2014/01/01/i-am-tired-by-rails-should-fundamentally-change-crowd/

Karthikeyan A K said...

I would like to see Opal http://opalrb.org and its framework vienna

Andrzej Krzywda said...

I took some time to hack with Opal yesterday. It's not fully stable yet, but it has a fantastic vision behind it.

I didn't try Vienna, but the idea of using Ruby on the frontend is quite appealing.

It may be a new direction for Rails devs :)