I would say which one is better depends a lot on the person and on the project.

For example, you might ask: 6-12 months from now, how quickly can you still add features and fix bugs? When there is a new framework version, how much time can you afford to spend on upgrading it?

Being a one person project goes both ways. It also means the penalties of version upgrades, maintenance, dealing with spikes even at low scale falls on the shoulders of a single person, who now won’t have the time of doing any new feature development.

EDIT: @stefanchrobot also has a very good point below. The Phoenix stack is also leaner, you need Phoenix and a database. Most other frameworks will require additional components by the time of deployment.

Overall, I agree with DHH, that we have seen a huge ramp-up in complexity in the last decade when it comes to web development. Much of it was necessary and caused by improvements in standards and practices around security, privacy, user experiences, etc.

However, some of this complexity was brought by moving the logic to the client, which naturally creates a split between client and server. The movement started with Phoenix+LiveView shows the server is equally capable of powering rich and interactive user experiences. And now, with esbuild, sass, and tailwind-standalone, we can get rid of npm and limit JavaScript to the front-end only, as it was 10 years ago.

But the truth is: there is still a huge amount of complexity and best practices in place, and I think you are right that the best one person frameworks are likely to be Wordpress, Shopify, and projects like Supabase.

I also must say that, in general terms, this is really a fight for JavaScript to win. Most LiveView-like solutions focus exclusively on using the server to push updates. LiveView goes further to provide form handling, file uploads, JS commands, etc. Therefore it provides a better one person experience but you still cannot run from JavaScript!!!

Theoretically speaking, the JavaScript community could create the “most compact” one person client+server framework, with fewer moving parts and integrations, but for some reason there doesn’t seem to be a lot of interest in doing so. When it comes to the client, most JavaScript solutions treat the server as an additional step or dismiss it altogether. Or maybe my lack of experience makes me unable to see how hard it actually is to create an all encompassing solution in JavaScript.

I think Rails is well described as the one person framework, and I mean that in both positive and negative ways. What a single person can accomplish in rails and within the broader rails ecosystem is generally exceptional. There are a ton of libraries, and a ton of “batteries included” stuff within the set of core Rails gems.

The downside is that, in my experience, as more people work on the code base and the application becomes heavier under the weight of complexity and history it often develops bottlenecks. I don’t really mean in the performance sense, but rather in the workflow or conceptual sense. Certain core data models often grow immensely large as they start to be used in many different situations, and various details tend to have cross cutting implications across the whole code base.

Phoenix also puts a lot of power in the hands of a single developer. I think the library ecosystem in Elixir is good, but quite as comprehensive or plug and play as in Ruby. Phoenix / Ecto tend to require more boilerplate for any given feature in the spirit of explicitness (which I think is a good thing) but this can make churning out 15 different CRUD pages a bit slower.

Phoenix and Elixir in general have a much stronger notion of internal modular functionality. Phoenix contexts try to group related database tables, and supervision constructs tend to create clusters of process management code that I think lend themselves to better scaling as teams and companies grow.

I’ve spent a fair amount of my professional life building and/or maintaining one-person apps in production (or two-to-four-person apps, which is not as catchy of a name but has many similarities). I don’t think you should focus too much on the idea of a literal single person, but rather, on the ability to maintain an application with a very modest input of developer resources. IMO both Rails and Phoenix are both best in class in this category.

What DHH mentions in passing is that there was a golden era in which Rails really did make it possible for a single person with mid-level experience to maintain a complex web application and even enjoy doing so! The rapidly escalating demands and complexity of the frontend have dashed that possibility for many web applications. These days, rich UI experiences are a baseline expectation for many apps, and rich UI experiences are very hard to build without committing to a heavy frontend framework, which these days is typically React. Not only is React a different language, it’s a completely different paradigm with almost entirely novel conceptual models, performance concerns, development tooling, etc. It’s a lot for even a very senior dev to keep a handle on while simultaneously maintaining a backend. To make matters worse, the huge amount of churn in Javascript packages means you are perpetually on the hook for breaking updates, abandoned modules, etc. Adding React to a non-toy project introduces a huge maintenance liability and puts you on a swift track out of one-person-app land.

To me, one of the biggest value propositions of LiveView is that it greatly expands the scope of which projects can avoid introducing React and incurring all this liability. LiveView makes it possible to build UIs that are rich and performant enough to satisfy the needs of many modern web apps, and it is powerful enough to remain in one-person-framework land while doing that. A lot of Rails apps have React dependencies even though they’re not doing anything especially fancy, simply because Rails hasn’t historically had a good answer for what to do when you need more than “a sprinkle” of JS but less than the whole enchilada. I haven’t used Rails 7 yet but it will be interesting to see if it makes headway in this area.

To answer the original question about when I would choose one versus the other, here’s how I would look at it in the current moment:

• If my app needs very little rich UI, I can write a little bit of vanilla JS, skip React, and use Rails or Phoenix. Either one is good.
• If my app needs a lot of rich UI, I can suck it up and use React, and the backend can be Rails or Phoenix. Either one is good.
• If my app needs some rich UI, I can use Phoenix+LiveView and skip React. Phoenix is the clear winner at the moment.