Rails and Phoenix as 'one person frameworks'

Phoenix Forum Chat / Discussions
, ,
1

On reading dhh’s latest The One Person Framework it strikes me that Phoenix with LiveView is already pretty much this. However, never having used Rails, and (despite my best intentions when coming across Elixir and Phoenix earlier this year!) not yet having done anything substantial with Elixir/Phoenix, I’d be interested in hearing perspectives from those who have used both in production.

Specifically: assuming sound skills in the respective language and framework (ie. entirely putting aside the ‘use what you know’ argument), what forces would push you to choose one versus the other for to build a competitive one person business?

5 Likes
2

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.

19 Likes
3

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?

3 Likes
4

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.

20 Likes
5

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.

8 Likes
6

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-:tm:. 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.

10 Likes
7

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

8

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 :icon_cry:

9

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.

5 Likes
10

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.

8 Likes
11

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

2 Likes
12

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.
19 Likes
13

Frontend complexity aside, I think Rail is no longer the best for for one person projects. Phoenix is. Rail is probably better than Phoenix for a smallish team project.

With Rail you can whip up an application with many gems in a short time, but the many dependencies will give you maintenance headache later on and will take the fun out of it for the solo developer. With Phoenix, you tend to write a lot of peripheral code yourself because of package availability or your whim. It is harder to get started, but the fun of doing it stay with you.

4 Likes
14

I agree. I think the selling point of Ruby on Rails was and likely always will be “get a prototype out the door super quickly”. I’ve eaten a lot of flak for this statement but I worked for 6.5 years with Rails and I’ve only seen it excel at that and nothing else. Every Rails project I co-wrote, or consulted for, or coached on, or co-architected, always spirals to a near-unmaintainable mess some 2-3 months after the MVP is out and the order comes from above “OK, now make it a full-blown product”, despite the best efforts of me and dozens of others who are much better programmers and architects than myself.

People just pile gems on top of gems and monkey patches on top of other monkey patches and even with super strict and stringent process you’re always just one minor version upgrade away from breaking 15% of your test suite (which is likely at least 5_000 tests). It got to a point where bureaucracy stalled almost all progress and by that time you gotta ask yourself “what’s the point of all this fancy tech if we can’t deliver a new checkbox in a form in the next 3 weeks?”.

But to not make anyone think I am just crapping on Rails (I am not), it is indeed a very good framework for a one person to whip up a business idea and very quickly iterate on it and check its viability. I always liked Rails for that but then again this is not how I live and work – namely producing tons of new projects, throwing them at the wall and seeing what sticks. That, plus its scaling problems – you very quickly get to the point of not being able to service some meager 300-400 requests per second! not cool! – eventually turned me off of it and made me look for alternatives… which eventually led me to Elixir / Phoenix at the beginning of 2016.

Phoenix can be a good one-person framework but as others pointed out very accurately, the frontend part is the real productivity killer. I am excited to try Tailwind and esbuild and not have webpack and React et. al. in a hobby project. But (as also pointed out by other people) many projects will not be able to benefit from this simplicity so they’re stuck with having to manage a ton of extra complexity without the backend framework mattering much.

So all in all, Phoenix too is a good one-person framework but for it, PHP Laravel, Ruby on Rails and a few others, the true blocker is the frontend stack really. I’ve participated in and authored both Plug and Phoenix projects that are only API servers / gateways and they absolutely kill it there. Not to mention data gatherers and scrapers, event buses, message queue routers and what-have-you.

14 Likes
15

Thanks everyone for your interesting thoughts. I don’t have anything useful to add (never having used Rails, and being an elixir/phoenix neophyte). It’s necessarily a very hypothetical question, as the relevant ceteris paribus caveats (exactly equivalent skills in both frameworks, project requirements etc) never really hold true. Every software project really is its own special snowflake. I wouldn’t have it any other way.