Learning the Ruby Software

Is Ruby worth learning now?

What are the reasons that still make it potent?

The same reasons why it was a framework worth learning in 2004. The more things change, the more they stay the same. While we’ve seen a lot a progress in the JavaScript world, we’ve also seen a regression to the complexity-laden world that Rails offered refuge from in the early days.

Back then the complexity merchant of choice was J2EE, but the complaints are uncannily similar to those leveled against JavaScript today. That people spent hours, if not days, just setting up the skeletons. The basic build configurations. Assembling and cherry-picking from lots of little libraries and frameworks to put together their own snowflake house variety.

 

 

The core premise of Rails remains in many ways as controversial today as it was when it premiered. That by formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application, we can make dramatic strides of productivity.

It’s somewhat surprising that despite the astounding success of Rails, that there haven’t been more competition for this proposition. The vast majority of activity today is for yet another option on the a la carte menu. Yet another build system, yet another view library, yet another ORM. Very little activity in integrated solutions.

The answer is that the foundational proposition of Rails continues to cut against the psychological grain of most programmers. By reducing choices, accepting community conventions and  answering  most of the basic questions in web development, you end up better off with Ruby on Rails. It is less unique and less tailored, but in ways that just don’t matter anyway.

Anyway, that’s the big ideological appeal of Rails.

On top of these ideological choices, we’ve built an incredibly pragmatic and multi-paradigm web framework. And in that definition, some might see it as though Rails competes against something like React.

Rails has an incredibly ambitious mission. In the full-stack goal lies a pursuit to deal with just about every piece of code needed to connect databases and no-SQL stores to a business domain model written in Ruby to a set of controllers that expose that model via REST and then, yes, finally to HTML. But that last step is a small minority of the code and focus of Rails.

So if you think that client-side MVC, React, Angular, or whatever is The Future, then you’re still squarely in the target audience for using Rails. Because the bits you use to design your HTML/JavaScript-based UI still needs to connect to a back-end domain model that saves stuff to the databases, computes things, enqueues jobs for later processing, sends out emails, triggers push notifications, and all the other stuff that real apps need to do.

And that’s where the meat of Rails sits!

In what happens once that POST or PUT or GET is triggered. Now, as mentioned earlier, Rails is full-stack by default. So of course we also include answers for how to generate and update HTML.

We have some phenomenally productive answers in Turbolinks and SJR, but even if that path doesn’t appeal, everything that leads up to generating that JSON is still stuff we’ll have in common.

Most importantly, if you learn Ruby, you get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language we’ve yet to encounter.

Just look at some code. We dare you not to fall in love.