Why Rails?

Rails is a highly productive full-stack framework. There’s ample documentation on “Why Rails,” so I won’t cover that here, but I will cover the question of “Why Rails and Phlex?”

Ruby on Rails website

Rails has most of the parts you need to build a web application

Rails prides itself on “compressing the complexity of modern web apps.” That means when you run rails new, you’ll get most of the parts you need to build a web application:

And much more. All of these parts work together seamlessly out of the box.

Rails will be around for a while and is the de facto standard for Ruby web frameworks

If you build a web application on Rails, you don’t have to worry about whether it will be supported in 5, 10, or even 20 years. Huge companies including GitHub, Airbnb, Shopify, and many more have built hundreds of billions of dollars’ worth of businesses on it and have a vested interest in keeping the ecosystem alive and healthy.

Rails is very modular

One amazing thing about Rails is how modular it is. Don’t like the default frontend of templates, partials, and helpers? No problem, swap it out for something else and Rails still works great.

Phlex can be dropped into Rails

The traditional Rails view layer (ActionView with ERB templates, partials, and helpers) works, but many developers prefer component-based architectures. Two popular options have emerged:

Phlex takes a Ruby-first approach where components are plain Ruby classes with methods. It’s lightweight, fast, and feels natural to Ruby developers. You write HTML using Ruby method calls instead of templates:

class CardComponent < Phlex::HTML
  def template
    div(class: "card") do
      h2 { "Hello World" }
      p { "This is pure Ruby" }
    end
  end
end

ViewComponent is GitHub’s component framework that uses Ruby classes paired with ERB templates. It’s more traditional, keeping the separation between Ruby logic and HTML templates:

# ./app/components/card_component.rb
class CardComponent < ViewComponent::Base
  def initialize(title:)
    @title = title
  end
end
<%# ./app/views/card_component.html.erb %>
<div class="card">
  <h2><%= @title %></h2>
  <p>This uses ERB templates</p>
</div>

Both work seamlessly with Rails, but Phlex’s pure Ruby approach means no context switching between Ruby and ERB, better IDE support, and easier testing. In fact, Rails applications are so flexible that it’s possible to build a fully functioning web application with no ERB and 100% Phlex.

Less JavaScript with Hotwire

One of the most difficult things about working with JavaScript is managing all the dependencies. Running npm install can be painful when dusting off a project and updating dependencies.

Rails’ approach to JavaScript is to use less of it through an approach known as “HTML-over-the-wire” with a library called Hotwire.

Hotwired screenshot

The idea behind Hotwire is to let the server handle data binding, render HTML, and send it to Hotwire to patch into the browser’s DOM. This is a departure from a React-style approach that is dramatically more complex, involving JSON API backends, complex JS dependencies, and more parts that can break during development and runtime.

Hotwire works with native mobile apps

There’s also an entire framework around Hotwire called Hotwire Native that makes integrating your web application with native mobile apps more straightforward and lower effort.

A pragmatic community

Rails developers generally focus on shipping products to people with the minimum amount of effort possible. When someone develops a solution, like using Bundler to manage Ruby gem dependencies, it’s widely adopted by the community so they don’t get bogged down in redundant solutions to the same baseline problem.

Checkout in minutes

Use Apple Pay, Amazon Pay, or your credit card to order this course and we'll email you the receipt.

Purchase video course for $379 $379