Thoughts as I conclude Ruby and RoR

When I started at the Flatiron School, I had never coded Ruby before. I’m embarrassed to admit I also thought Ruby on Rails was the same as Ruby. Spoiler alert: it’s not. Now that I’ve concluded Module 2 of my program, here are a few of my thoughts on this language and framework, as compared to vanilla JavaScript:

  1. Rails is incredibly intuitive.

Prior to Flatiron, I was learning to code alongside Codecademy, Youtube tutorials, FreeCodeCamp, and took a few bootcamp prep courses with Codesmith. I’d never worked with a framework and remember wondering how I would go from writing a function to creating a CLI application to creating a responsive app. Where did my coding fit in the grand puzzle of a hypothetical tech company?

Rails is a framework built on Ruby. Rails bring our code to the browser, and its intuitiveness I’ve deemed “Rails magic”. Rails handles our join tables, but in addition to that, there are so many built-in helper methods that make our lives easier. For example, Rails has generators that will create migration files, models, controllers, and even routes for you. When I first learned about this, I thought “Well, what do you need me for? You did everything!” While this is almost entirely true, Rails — and Ruby — don’t provide the logic that a human can (at this time, at least).

2. Rails is conventional, JavaScript is…not

Part of what makes Rails so intuitive is because it follows the MVC convention: Model-Views-Controller. Your views are what you see on the browser. Your controller directs where the User goes when interacting with the app. Your model is where you designate your associations and validations, and other necessary logic. There seems to be very little delineation from convention with Rails, which can be a good or bad thing. Since it’s conventional and follows the RESTful routes for the most part, it’s easier to debug once you understand.

In comparison, there are various ways of achieving the same goal if you code in JavaScript. For example, finding a sum. You could use a for loop (which would probably take a longer time when working with a big data set) or use a .reduce() method. There really isn’t a “right” or “wrong” way to do things in a sense.

3. Ruby goes out of its way to be nice

It’s only been a year into my coding journey/career, and already I can tell how friendly Ruby is compared to JavaScript’s…fickleness. In Ruby, you don’t need to declare variables. The const, let, and var absences were hardest to wrap my head around when I started coding in Ruby. It just…knows what you’ve written is a variable somehow. It implicitly returns for you as well. In addition, you’ve a multitude of array methods that get you the value or result you need faster. In comparison, JavaScript has fewer but equally powerful methods. They just require you be very intentional in how you use it, otherwise you get unintended consequences.

Overall, it’s been really interesting to learn a web framework and programming language, and to see the many differences and similarities between the two I currently know (to a certain extent). I’m looking forward to learning more languages and becoming familiar as I move forward with my coding journey.