"Ruby on Rails vs JavaScript" puts a framework on one side and a language on the other, and the
mismatch is not pedantry, it is the reason the comparison is usually argued badly. Rails is a
server-side web framework written in Ruby. JavaScript is the language every browser runs, including
the browsers pointed at a Rails application. The question underneath the query is a real one and it
is narrower: should the server side of this product be Rails, or a JavaScript stack, meaning Node
running Next.js, or a separate API with React in front of it. That is the comparison this page
makes, and it ends in a verdict.
How much of the product one person can hold
Rails was built around a constraint that has nothing to do with speed: one person should be able to
hold the whole application. The schema, the queries, the HTML, the forms, the emails, the background
jobs, the WebSocket channels and the JSON API live in one repository, run under one test suite and
ship in one deploy. When something breaks at 2am, there is one place to look and one set of
conventions describing where in that place to look.
A JavaScript stack is assembled rather than handed to you. Next.js gives routing, rendering and a
build. After that, every layer is a decision somebody has to make and defend: Prisma or Drizzle for
the database, a library for auth, something for background work, something for transactional mail,
something for the admin screens. Each of those pieces is good software. What they are not is one
piece, and every seam between two of them is a place where the two disagree about what a user is.
The cost of the Rails side of this is real and worth naming. Rails decides your file layout, your
naming, your database conventions and a great deal of your architecture before you have written a
line. If you enjoy choosing your own stack component by component, Rails will feel like somebody
else's house, and the feeling does not go away.
My read is that the assembled stack charges its price late. In month one the pieces are fresh and
the choices feel like power. In month eighteen, the auth library has had a major version, the ORM
has changed its migration story, and nobody remembers why the queue talks to a different database
than the app does. Rails makes the same decisions once, centrally, and upgrades them together.
Counting the moving parts
Rails 8, released in November 2024, deliberately removed the infrastructure a Rails application used
to require. Solid Queue, Solid Cache and Solid Cable put background jobs, caching and WebSockets in
the database you already have. Propshaft and import maps mean the default application has no Node
dependency and no asset build. Kamal 2 deploys it to a plain Linux box. A new Rails 8 application in
production is Ruby plus one database, and that is the whole list. Rails 8.1, from October 2025,
added a bin/ci runner declared in config/ci.rb, so even the CI configuration is in the box.
The JavaScript equivalent of that list is longer, and not because anyone did anything wrong. A Node
runtime and a package manager, a bundler, an ORM and its migration tool, a queue (BullMQ, the common
answer, wants Redis), an auth library, and a host with an opinion about how your framework should be
deployed. None of those is hard on its own. Together they are the thing you maintain instead of the
product.
Count this axis honestly and it is not close. If fewer moving parts is what you are optimising for,
Rails wins it outright.
Hotwire against a separate frontend application
Rails renders the frontend itself, and this is the half of the comparison that
the pillar leaves to this page. Since Rails 7 the default stack is Hotwire: Turbo
swaps fragments of a page over the wire instead of reloading it, Turbo Streams push server-rendered
updates down a WebSocket, and Stimulus attaches small behaviours to markup the server already sent.
Interactivity arrives without a client-side application, which means no second repository, no API
contract between two teams and no state kept in two places that can disagree.
What Hotwire gives up is fine-grained client state. A screen whose behaviour depends on a dozen
interacting values that change as the user types is work in Hotwire and is exactly what React was
designed for. Text editors, canvases, spreadsheets, drag-heavy builders, collaborative cursors,
anything that must keep working offline: those are React-shaped problems and Hotwire is the wrong
tool for them.
For the screens most products are actually made of, the ones with forms, tables, filters, modals,
dashboards and a checkout flow, Hotwire costs less per screen than any SPA I know of, because the
server already has the data and the markup and does not have to serialise either. You can still run
Rails as a JSON API with React in front, and plenty of teams do. Doing that by default, before any
screen has proved it needs a client application, is paying the SPA's whole bill on the chance that
one page will need it.
Where a JavaScript stack is genuinely faster
Node holds many mostly-idle connections per process more cheaply than a thread-per-request Ruby
server does, because that is what an event loop is for. A product whose job is thousands of open
sockets doing very little is arguing with Rails's architecture rather than with its speed, and that
is an argument you lose slowly and expensively.
One language across the server, the browser and, through React Native, the phone is the other
genuine win. Shared validation, shared types and one set of hiring criteria are worth real money to
a team that ships a mobile application alongside the web one.
And the fastest stack is frequently the one your team already writes. A team of TypeScript
developers will ship a competent Next.js product before they ship a mediocre Rails one, and no
comparison of framework features outweighs that.
Hiring, with the number stated
Stack Overflow's 2025 Developer Survey asked respondents which technologies they had done extensive
work in over the past year. JavaScript came back at 66% and Node.js at 48.7%. Ruby on Rails came
back at 5.9%. Node against Rails is the comparable pair, and it is roughly eight to one.
That ratio is the single strongest argument against Rails, and pretending otherwise is how Rails
advocacy loses credibility. In a mid-sized city, filling a Rails role takes longer than filling a
React one, and everybody who has tried both knows it.
What the ratio does not tell you is how many people one hire replaces. A framework that ships auth,
jobs, caching, mail and an admin story in the box needs fewer specialists around it, and a smaller
team hires less often. If you are scaling to twenty engineers inside a year, the pool matters more
than the box does, and that is a real reason to choose JavaScript. If you are two people, it barely
registers. The size of the pool also says nothing about the ramp: a competent developer of any
background gets productive in Rails quickly, which
Is Ruby on Rails hard to learn works through starting point by
starting point.
The boring things every product needs
Auth, billing, an admin console, background jobs and feature flags are what you actually spend the
first two months on, and this is where a twenty-year-old ecosystem pays. Devise has passed 296
million downloads and shipped version 5.0.4 in May 2026. Stripe billing, Active Admin or Avo for the
back office, Solid Queue in the framework itself, Flipper for flags: these are not new, and not
being new is the feature.
The JavaScript side moves faster in both directions. In September 2025, the Auth.js maintainers
announced that Auth.js was joining Better Auth, that it would receive security and critical fixes
rather than new features, and that teams starting something new should adopt Better Auth instead.
Nothing about that is scandalous, it is a healthy project handing over responsibly, but it is the
tax: the auth library you picked in 2024 is in maintenance mode, and the migration is yours. Churn
is what a fast-moving ecosystem feels like from inside a codebase that is three years old.
Rails has its own version of this, smaller and slower, and
Does anybody still use Ruby on Rails is the page that looks at whether
slow-moving here means stable or means stalled.
The verdict, and what it costs you
For a product with accounts, payments and data that users change, built by a team of one to five,
pick Rails. The argument is not that Ruby is a better language than JavaScript. The argument is that
the fewest moving parts wins when nobody on the team has time to be a platform engineer, and Rails
8 with Hotwire is the smallest production stack available for that shape of product today. If you
want to see what that looks like in a real codebase rather than in a comparison,
a Ruby on Rails example application walks one.
What would change that verdict: the hard part of your product living in the browser, a mobile
application that should share code with the web one, thousands of long-lived connections as the core
workload, or a team that already writes TypeScript well. Any one of those is enough, and the last
one is enough on its own.
The cost of taking my side is not hypothetical. Your hiring pool is roughly an eighth the size. Ruby
is not the fastest language per core and you will eventually meet an endpoint where that matters.
And you will spend some part of your life explaining the choice to developers who last looked at
Rails in 2015. I think that is a good trade for two years of shipping faster than the team that is
still wiring their stack together. I also think anyone who tells you it is free is selling
something.
"Ruby on Rails vs JavaScript" puts a framework on one side and a language on the other, and the mismatch is not pedantry, it is the reason the comparison is usually argued badly. Rails is a server-side web framework written in Ruby. JavaScript is the language every browser runs, including the browsers pointed at a Rails application. The question underneath the query is a real one and it is narrower: should the server side of this product be Rails, or a JavaScript stack, meaning Node running Next.js, or a separate API with React in front of it. That is the comparison this page makes, and it ends in a verdict.
How much of the product one person can hold
Rails was built around a constraint that has nothing to do with speed: one person should be able to hold the whole application. The schema, the queries, the HTML, the forms, the emails, the background jobs, the WebSocket channels and the JSON API live in one repository, run under one test suite and ship in one deploy. When something breaks at 2am, there is one place to look and one set of conventions describing where in that place to look.
A JavaScript stack is assembled rather than handed to you. Next.js gives routing, rendering and a build. After that, every layer is a decision somebody has to make and defend: Prisma or Drizzle for the database, a library for auth, something for background work, something for transactional mail, something for the admin screens. Each of those pieces is good software. What they are not is one piece, and every seam between two of them is a place where the two disagree about what a user is.
The cost of the Rails side of this is real and worth naming. Rails decides your file layout, your naming, your database conventions and a great deal of your architecture before you have written a line. If you enjoy choosing your own stack component by component, Rails will feel like somebody else's house, and the feeling does not go away.
My read is that the assembled stack charges its price late. In month one the pieces are fresh and the choices feel like power. In month eighteen, the auth library has had a major version, the ORM has changed its migration story, and nobody remembers why the queue talks to a different database than the app does. Rails makes the same decisions once, centrally, and upgrades them together.
Counting the moving parts
Rails 8, released in November 2024, deliberately removed the infrastructure a Rails application used to require. Solid Queue, Solid Cache and Solid Cable put background jobs, caching and WebSockets in the database you already have. Propshaft and import maps mean the default application has no Node dependency and no asset build. Kamal 2 deploys it to a plain Linux box. A new Rails 8 application in production is Ruby plus one database, and that is the whole list. Rails 8.1, from October 2025, added a
bin/cirunner declared inconfig/ci.rb, so even the CI configuration is in the box.The JavaScript equivalent of that list is longer, and not because anyone did anything wrong. A Node runtime and a package manager, a bundler, an ORM and its migration tool, a queue (BullMQ, the common answer, wants Redis), an auth library, and a host with an opinion about how your framework should be deployed. None of those is hard on its own. Together they are the thing you maintain instead of the product.
Count this axis honestly and it is not close. If fewer moving parts is what you are optimising for, Rails wins it outright.
Hotwire against a separate frontend application
Rails renders the frontend itself, and this is the half of the comparison that the pillar leaves to this page. Since Rails 7 the default stack is Hotwire: Turbo swaps fragments of a page over the wire instead of reloading it, Turbo Streams push server-rendered updates down a WebSocket, and Stimulus attaches small behaviours to markup the server already sent. Interactivity arrives without a client-side application, which means no second repository, no API contract between two teams and no state kept in two places that can disagree.
What Hotwire gives up is fine-grained client state. A screen whose behaviour depends on a dozen interacting values that change as the user types is work in Hotwire and is exactly what React was designed for. Text editors, canvases, spreadsheets, drag-heavy builders, collaborative cursors, anything that must keep working offline: those are React-shaped problems and Hotwire is the wrong tool for them.
For the screens most products are actually made of, the ones with forms, tables, filters, modals, dashboards and a checkout flow, Hotwire costs less per screen than any SPA I know of, because the server already has the data and the markup and does not have to serialise either. You can still run Rails as a JSON API with React in front, and plenty of teams do. Doing that by default, before any screen has proved it needs a client application, is paying the SPA's whole bill on the chance that one page will need it.
Where a JavaScript stack is genuinely faster
Node holds many mostly-idle connections per process more cheaply than a thread-per-request Ruby server does, because that is what an event loop is for. A product whose job is thousands of open sockets doing very little is arguing with Rails's architecture rather than with its speed, and that is an argument you lose slowly and expensively.
One language across the server, the browser and, through React Native, the phone is the other genuine win. Shared validation, shared types and one set of hiring criteria are worth real money to a team that ships a mobile application alongside the web one.
And the fastest stack is frequently the one your team already writes. A team of TypeScript developers will ship a competent Next.js product before they ship a mediocre Rails one, and no comparison of framework features outweighs that.
Hiring, with the number stated
Stack Overflow's 2025 Developer Survey asked respondents which technologies they had done extensive work in over the past year. JavaScript came back at 66% and Node.js at 48.7%. Ruby on Rails came back at 5.9%. Node against Rails is the comparable pair, and it is roughly eight to one.
That ratio is the single strongest argument against Rails, and pretending otherwise is how Rails advocacy loses credibility. In a mid-sized city, filling a Rails role takes longer than filling a React one, and everybody who has tried both knows it.
What the ratio does not tell you is how many people one hire replaces. A framework that ships auth, jobs, caching, mail and an admin story in the box needs fewer specialists around it, and a smaller team hires less often. If you are scaling to twenty engineers inside a year, the pool matters more than the box does, and that is a real reason to choose JavaScript. If you are two people, it barely registers. The size of the pool also says nothing about the ramp: a competent developer of any background gets productive in Rails quickly, which Is Ruby on Rails hard to learn works through starting point by starting point.
The boring things every product needs
Auth, billing, an admin console, background jobs and feature flags are what you actually spend the first two months on, and this is where a twenty-year-old ecosystem pays. Devise has passed 296 million downloads and shipped version 5.0.4 in May 2026. Stripe billing, Active Admin or Avo for the back office, Solid Queue in the framework itself, Flipper for flags: these are not new, and not being new is the feature.
The JavaScript side moves faster in both directions. In September 2025, the Auth.js maintainers announced that Auth.js was joining Better Auth, that it would receive security and critical fixes rather than new features, and that teams starting something new should adopt Better Auth instead. Nothing about that is scandalous, it is a healthy project handing over responsibly, but it is the tax: the auth library you picked in 2024 is in maintenance mode, and the migration is yours. Churn is what a fast-moving ecosystem feels like from inside a codebase that is three years old.
Rails has its own version of this, smaller and slower, and Does anybody still use Ruby on Rails is the page that looks at whether slow-moving here means stable or means stalled.
The verdict, and what it costs you
For a product with accounts, payments and data that users change, built by a team of one to five, pick Rails. The argument is not that Ruby is a better language than JavaScript. The argument is that the fewest moving parts wins when nobody on the team has time to be a platform engineer, and Rails 8 with Hotwire is the smallest production stack available for that shape of product today. If you want to see what that looks like in a real codebase rather than in a comparison, a Ruby on Rails example application walks one.
What would change that verdict: the hard part of your product living in the browser, a mobile application that should share code with the web one, thousands of long-lived connections as the core workload, or a team that already writes TypeScript well. Any one of those is enough, and the last one is enough on its own.
The cost of taking my side is not hypothetical. Your hiring pool is roughly an eighth the size. Ruby is not the fastest language per core and you will eventually meet an endpoint where that matters. And you will spend some part of your life explaining the choice to developers who last looked at Rails in 2015. I think that is a good trade for two years of shipping faster than the team that is still wiring their stack together. I also think anyone who tells you it is free is selling something.