As a student learning their way around Ruby on Rails I’ve had many rough patches, but once I started learning how to maneuver around in the back end I wanted to create an efficient way for the user to maneuver around the front end!

As a beginner in the coding world we have many questions and an overwhelming amount of resources that we can learn from. Finding out the differences between buttons and links is too much, and that’s why you’re here.

Buttons are written like this:

           <%= button_to("button", path, method) %>

Let’s break this down. The begging of the button, before it even says “button_to” is an ERB tag. There are only three important ERB tags that a beginner should know about. They are:

<% Ruby code that isn't shown %>
<%= Ruby code that is shown %>
<%# Comments that aren't shown 'nor run %>

These lines allow us to write Ruby within HTML pages.

Further down the line, you have “button_to”, this in essence is a helper method that the people that created rails have included within the framework. This helper method takes three arguments

  1. The name of the button
  2. The path the button takes
  3. The method that the button uses

The first argument is quite simple, It’s just the words that are on the buttons face, you can make it say anything and it wont effect the way that it works in any way (it’s for the user to understand what smashing that button will do.)

The second argument is a ‘bit more rough. This will consist of the path the button will bring you to. There are many routes and the button can essentially bring you to any. If you are in in your terminal and you have all of your routes set up. You can run ‘rails routes’ and it’ll bring you to a page that looks a little like this (but not as cool.)

On the left column you see the top line that reads ‘prefix.’ These are the routes that you are able to take. For example, if you wanted to create a path to link to the dogs index page, all you need to do is reference the right column and trace it alllll the way down to the left. In this case the prefix will be dogs. To create a path all you need to do is add a _path after the word. And boom you’ve created a path. Yes I understand there are verbs that don’t have prefixes, and thats because they don’t really have a path. The verb associated with them isn’t get, therefore you aren’t actually displaying anything for those actions. But that’s all we will talk about for pathing.

The third argument takes the method/ verb. Buttons are initialized with a method of ‘post.’ But, if you are using a button to navigate around your website (which you shouldn’t do, you should use links (but buttons are more fun.)) You would want to write the third argument as

method: :get %>

You can do any method you’d like i.e put, patch, delete, blah blah blah. They will change the way that the button functions.


Links and button have ALLLOOOT in common, from my understanding. The distinct difference between the two are two things. The first argument a link_to helper method does is it makes the first argument clickable. On the other hand a button_to just makes the face of the button with the words on it. The second argument for a link and a button is essentially the same (path.) The last difference between the two is that a button_to is initialized with a ‘post’ verb, and a link_to is initialized with a ‘get’ verb. That’s it… Links make you go places, and buttons make things happen. The thing is though, they can both be overwritten to do anything you really feel like. You can add a third argument to a link i.e:

<%= link_to "words", path, method: :post %>

ANNNNNDDD Boom, your link_to now can post things. Lastly, don’t stress over the difference between the two, once you start incorporating css into your code, you can make your links and buttons look like anything you’d like!

TLDR: Buttons and Links are pretty much the same thing. The key difference between the two is that buttons implicitly perform a post action (which can be overwritten) and a link implicitly performs a get action (which can also be overwritten.)

An aspiring coder, trying to make sense of The World (of coding.)