A few weeks ago, I started learning Ruby and Ruby on Rails for the first time. I’ve completed the beginner Ruby course on Codecademy, always a good resource for learning the basics of a language. Now, I’m slowly working through the helpful Rails guides provided in their documentation.
Why am I doing this? I have been building websites with PHP since 2016, and I love PHP, WordPress and Laravel. However, there are a few reasons I’ve switched my gaze to Rails in the last few weeks.
What prompted my interest initially was an interview with David Heinemeier Hansson (DHH) on Max Lidman’s YouTube channel, in which DHH does a good job as a hypeman for the Ruby programming language. He talks about how it’s a language meant to be beautiful and to be read like prose by humans rather than like technical instructions for robots.
But the part about the interview that peaked my interest the most was when DHH talked about making Ruby on Rails a no-build framework, meaning that you do not have to pre-compile a bunch of JavaScript and CSS.
That’s the part I hate the most about Laravel these days. All of their starter kits require a complicated build step. You can pick between Vue, React, or Livewire, but what if I don’t want any of those? I understand that they are there for a reason, that they are extremely useful in a real-world situation, but a lot of times I’m just messing around on the weekend. I miss those days in Laravel when you could just build a proof of concept with minimal boilerplate.
I’ve never worked well with starting off with complexity. Whenever I adopt a framework that already has a bunch of stuff going on, I have the same feeling I do when I have to work on a legacy codebase that I didn’t write myself. Sure, it comes with the territory, but it’s not pleasant.
The Laravel docs say that you can opt out of their starter kits and build your own authentication setup. But they don’t really tell you how to do it in the amount of detail I need. Buried deep within their authentication docs, they have a few sample snippets of code you can use to build your own login and registration. But you have to put the rest of it together yourself. The Rails guides walk you through step-by-step building a basic authentication setup from scratch.
Furthermore, all of the Laravel starter kits and other boilerplate is filled with a bunch of Tailwind code. I like Tailwind, but I don’t want to be forced into using it. And I don’t like to have to parse a bunch of Tailwind code when I’m first starting out on a project. In all of the Rails guides I’ve done so far, it is not using any CSS framework, just unstyled HTML elements. I love that. It allows me to understand how Rails works without worrying about CSS, sure in the knowledge I can add whatever CSS I want later down the road.
The jury’s still out. I know Rails does include a JavaScript framework called Hotwire by default. But it looks a lot simpler than the Laravel equivalent, Livewire. In the interview mentioned above, DHH alluded to the fact that he was trying to “go back” in some sense to the ’90s, when you could just upload PHP files to the internet and have a functioning website.
So far with Rails, it feels that way. I have not had to debug any Hotwire code. It’s just kind of there working on its own without me having to worry about it. My understanding is that it handles page transitions between different URLs in your app. I’m not sure I really need that, but it’s there and it’s working and not giving me any problems for the time being.
When I get to the point of having to write my own JavaScript for interactive elements, we’ll see how it goes. It will be hard to top Alpine JS, which is what I use at work and what Livewire is built with.
I should add that if it weren’t for Rails, I wouldn’t be trying to learn Ruby. So far, it’s a fine language, but I’m not sure I agree with DHH about how much more readable it is than PHP. He seems to like it for some of the same reasons I find it confusing at the moment. For instance, he mentions that you do not have to put “unnecessary” parentheses. But to me, that makes it confusing as to when a function is being called exactly. Take the following as an example:
redirect_to new_session_path, notice: "Password has been reset."
The above in PHP would be something like:
redirect_to( new_session_path(), ['notice' => "Password has been reset."] );
Personally, I find the latter easier to read, even if the former looks prettier. Once you have more properties on the Ruby Hash, it gets even harder to parse what’s a Hash property and what’s an argument of the function.
And from what little I know so far, it looks like Ruby handles requests concurrently, which I foresee could throw me for a loop at some point.
But overall, these are minor complaints. It’s similar to PHP in the fact that it’s dynamically typed. So far, I am settling into it relatively well. Not sure what I’m gonna do with it or how I’m gonna put it to use, but it’s fun just to learn something new. Wish me well!