A bit about me; my name is Leah I’m a Java developer and a reformed rails spruiker…
I used to tell everyone who was learning ruby to get onto Rails, while I will still use Rails for my projects I no longer suggest it to people trying to learn, one might say I have gone “off the rails.”
Good, you have now also witnessed my terrible humour and are soon to witness my lack of desire to sugar coat this article.
This article is aimed at people learning to be web developers, considering learning web development, or teaching someone else who is learning web development… It’s NOT aimed at established web developers…
As part of the “Springboard to tech” program at my workplace, I took a 3 month fully immersive web development course and now am on placement in a Java-based team, this article is about Ruby, and more specifically, learning web development with Ruby.
The course I took taught us first Ruby, then Sinatra, then Rails… afterwards, so many things about Rails suddenly made sense to me. What I then realised was, I wished I hadn’t learned Rails first… This article will go into why…
Ruby is great for learning code, it’s forgiving and has a lot of inbuilt magic.
The two main web frameworks (libraries that allow you to write code for the interwebs) are Sinatra and Rails. There are others such as Grape, but we wont be going into those in this post.
Sinatra – http://sinatrarb.com/
Sinatra claims to be: “a DSL for quickly creating web applications in Ruby with minimal effort.”
Rails – http://rubyonrails.org
Rails claims: “Learning to build a modern web application is daunting. Ruby on Rails makes it much easier and more fun. It includes everything you need to build fantastic applications, and you can learn it with the support of our large, friendly community.”
I have highlighted “includes everything you need” in Rail’s claim as it’s the main point of my article.
Rails includes everything AND the kitchen sink, to show this, I wanted to take a high-level look at the process for creating a simple app in each framework:
Let’s say we want to create a basic CRUD (Create, Read, Update, and Delete) application with people records containing information such as name age location, etc.
Here are the steps I would take… (Don’t worry if you don’t understand them all yet)…
|Design my model/data structure||Design my model/data structure|
|Create the model in the database||Generate a scaffold for my model|
|Connect the database to my Sinatra app||Fiddle with CSS|
|Set up some routing|
|Return the data somehow|
|Set up forms|
|Return the views|
|Address basic security concerns i.e. SQL injection|
|Fiddle with CSS|
Looking at the steps above, it seems clear to a lot of people that Rails may just be the simplest way to go if all I have to do is type a single line in a command prompt to create a fully functional app, why would I even bother using Sinatra?
Most experienced developers will tell you that using Rails scaffolding is not a great idea in a production environment, given that it the code generated will likely not produce exactly what the environment requires, or possibly more than it requires. There are also some who just plain do not like the general implementation of certain facets of the code scaffolding produces… In the end, the code needs to be manipulated later anyway.
But why not use scaffolding when you’re just learning? Learning code by reading an already established code base can be a useful way to learn a language, but when you’re learning a core concept such as web development, MVC, REST, CRUD, etc. I truly believe that it’s a hindrance and can lead to bad habits and poor understanding.
In the table above, you can see 2 common steps, Design my model/data structure and Fiddle with CSS. The steps in Sinatra that are skipped by Rails’ scaffolding process are vital parts of any web app, not ever having to set those up denies you a rich understanding of how web apps work, understanding these not only helps with problem-solving but also the design which I will come to later down the track.
In the following Reddit post, the original poster (OP) u/when-shit-hits-hard is a classic example of what I’m talking about:
I am beginner
and I couldn't find a learnrails
sub so please forgive me.
I have scaffolded a Post model, controller and views using rails g scaffold Post name:string
It generates everything for me and if I navigate to http://localhost:3000/posts/new I can add new posts and all.
But I am having a hard time expanding this to other views. Say, I want to be able to add a new post from views/Dashboard/index. How do I achieve this? I should be using form_for? But I did use form_for but i
get errors like nilClass or NoMethodError.
I learned the hard way that unless the action and the view names are same, Rails shits on you with lots of errors.
class PostsController < ApplicationController
This is my PostsController. Now say I got another controller called dashboard_controller.
class DashboardController < ApplicationController
I also have a view called index.html.erb
inside views/dashboard. I want to be able to add posts, delete and update from this controller.
I am not posting this here after an hour of debugging. I have been on this for more than 30 hours already with my StackOverflow posts downvoted to hell and one account banned. Please help me.
After Rails has done everything for them that it can, the Original Poster (OP) has decided to take on an additional task of putting a form for their model in another view for a different scaffold. This is a relatively simple task if you’re able to build out a web app without scaffolding, however, given that OP has not had to think about the design, nor structure of the app they are unable to expand upon it.
If OP had started learning web development with Sinatra, they would have had the opportunity to learn how controllers, models, routes, etc. work from end to end, they would have understood that their new Controller wouldn’t have passed through any information about their model to their view, and thus, the view wouldn’t be able to understand what a “post” was, resulting in the controller returning nilClass or NoMethodError.
This is why it baffles me that people who teach code can say “make sure you don’t copy and paste from stack overflow,” and yet teach people Rails first before teaching the basics of web development/MVC/CRUD apps. The sheer fact of the matter is, ladles and gentlespoons, just like that snippet you took from stack overflow, although Rails is good, it’s not your code, you didn’t write it, so if you’re starting out, I’d bet my bottom dollar you don’t understand it either, (nor should you be expected to…) there’s a lot of magic involved.
Now on to the people who have done web development, but are maybe starting out in the Ruby world, you’re thinking, “Hey, cram it with walnuts, ugly… I know all about MVC and CRUD and REST and life, I’m just going to use Rails…” Well first of all, ouch… but let me tell you why maybe that’s not such a good idea either… because Rails and I have something in common… we’re both very opinionated.
Again, using opinionated frameworks in the world of enterprise can be a good thing, it means that you can onboard new developers quickly as they will have a good idea where to find what they’re looking for,you also have much less to argue over, which means less meetings, which I’m sure suits everyone just fine. In the world of learning, however, the more opinionated a framework, the less the person using it has to think about design, the less they learn.
That’s not to say that using Rails you don’t need to think about design at all, but a hell of a lot has been thought out for you. This is not conducive to learning best design practices and, quite frankly, the thing that boils my broccoli the most, is how cookie cutter frameworks can actually be harmful to innovation in design.
In Rails the controllers go in the “controllers” folder, the models, in the “models” folders… which currently, yes, I do think is a nice design, however, if we were to take that design for granted we may miss out on something better to come, perhaps an innovative way of designing things and grouping them by business logic instead of code function,sorting them by team responsibility, sorting them by how fuzzy a-feeling they give you… who knows? We certainly won’t if we rest on our laurels and take Rails’ implementation for granted, I honestly think that giving people a template for how to structure code from day one will produce lazy developers.
In a nutshell, Rails is not your code, it can be a crutch for learning and can inhibit innovation as far as design goes. It’s fine for established web developers who know what they’re doing but for someone learning web development, I truly believe that despite being able to have a tangible app much sooner than one would if using Sinatra, Rails can well and truely be a hindrance to your learning journey.
In saying this, if you read all this and still believe that Rails is better for your learning journey, that’s okay! We all have different learning styles. I hope this helps to inform and influence the way you use Rails to learn, and, first and foremost, well done on taking the first steps – the journey is yours and what you want it to be… happy learning.