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?”
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:
- ActiveRecord - Database integration with an ORM for models and migrations
- ActionController - Controllers that handle HTTP requests and responses
- ActionView - HTML templating system with ERB, partials, and helpers
- ActiveJob - Background job processing
- ActionCable - WebSockets for real-time features
- ActionMailer - Email delivery system
- ActiveStorage - File upload and storage handling
- ActionText - Rich text editing
- Routing - URL mapping to controllers
- Testing - Built-in test framework with fixtures and assertions
- Environments - Configuration for development, test, and production
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.
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.

