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.

More projects than tend to be emphasized in the tech infosphere (dominated as it is largely by startup culture) don’t grow far along many of the salient dimensions (scale, complexity, team size, etc). These could be considered ‘intrinsic’ one-person projects rather than proofs of concept or MVPs waiting for growth. For these I would think the Rails limitations you point out may not come into play. Of course Wordpress and, increasingly, Shopify, cover most of the simpler cases adequately.

Given your assessment, it looks like Rails would come out a little ahead of Phoenix for true single person projects with few growth expectations?

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.

One additional point I think Phoenix has speaking for it over OOP (never did Rails, but PHP) is the fact that modules/functions will continue to be easier to reason about and therefore be easier to change. To me maintaining a “one-person” project this is a huge leg up when I can quickly and easily make incremental changes to the system even when not living continuously in its codebase.

The second part here is a great fact to keep in mind. Things are not only becoming more complex for the sake of it, but also for valid reasons, where in todays world we expect things to work different than years ago. E.g. we no longer put files on the app server, because that gets in your way when trying to add another one if traffic spikes. That made handling files and uploads more complex. But that doesn’t mean we cannot find new abstractions, which hide the complex boilerplate around the need to use cloud storage.

I’d go towards a solution that has fewer moving pieces and comes with reasonable default solutions to common problems - they don’t have to be perfect, but they should be viable for most use cases and should have good (invisible) glue.

The ideal example here is the new Tailwind integration: unless you have a conceptual dislike for Tailwind, it will get the job of styling your app done; the integration is super simple and just-works-. You don’t need to spend time figuring out how to make the pieces work together which is a huge win.

The opposite of that would be various shim scripts that are generated with the app - I don’t like code that I don’t understand, I don’t like having to understand some cryptic Bash or un-google’able magic that “needs to be there”. It’s not about not having to learn anything (e.g. using mix releases + Docker for packaging is well worth figuring out), it’s rather about getting rid of accidental complexity.

What do you think about the newly announced JS Framework: Remix? As I understood, they go to that direction.

Marko, the framework powering Ebay, has been doing that for ages now and made some quite impressive achievements(and maintainers are super nice). But it’s still Javascript

I dislike npm and javascript as much as any Elixir developer (we are spoiled); however, javascript is a fact of life in this field and I see no point to fight the trend. It is better to use it in a cautious way.

A “one person framework” does not necessarily mean a one language framework. As we know, many of the one language (javascript) frameworks are more complex than Phoenix and are harder to wield by a solo developer.

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.

Isn’t this what Meteor.js was trying to be? I was super into Meteor.js for about 18 months around 2014 - 2016, but by the end I absolutely hated the framework.

Meteor.js made a big deal about the fact that you could write one JavaScript function and it could be executed on either the client or on the server – but this never really made much sense to me because the client and the server are different environments with different concerns.

Then, of course, Meteor.js ended up adding ways for you to specify that some code was only allowed to run on the server, or only on the client, because apparently the distinction between the client and the server turns out to be relevant after all. Sheesh, what a circular waste of everyone’s brain cycles.

Also, moving the logic to the client means you have to concern yourself with all the different clients in the world, whereas doing almost everything on the server and keeping the client dumb means you have complete control over the environment where the main code is running and you don’t need to worry as much about testing your code across 12 versions of 7 browsers and devices.

Meteor is/was something like that, and I wished it was successful and easily scalable.