The One-Person Framework in Practice
link.mail.beehiiv.com
link.mail.beehiiv.com
The largest one has around 250 views, of maybe 80 are just basic admin views. It is basically comparable to an ERP of a medium-side company with various levels of permissions etc. I was able to get most of the functionality into production in just one month -- I was not working full-time at that time. I have estimated it with some friends, and such an ERP in the corporate world would normally take a team two years to do -- one to spec and another to implement.
It has 1-2M monthly page views depending on the season, and the highest hitting pages are read-only and heavily cached, so the server load is minimal. I am further increasing the performance by making those pages static HTML using django-distill and using Cloudflare to cache/serve them.
The key thing is to keep things as simple as possible. I avoid REST/heavy frontend frameworks whenever possible. For most views for most apps, normal HTML form request-response user interface based on Bootstrap is perfectly fine.
I started by sprinkling Javascript when it was really needed, for example client side sorting so I can avoid server load. Now I use AlpineJS/HTMX for the interactivity. It has been great, although much slower to implement.
I'm doing something similar to OP with Django right now
Why? The Ruby ecosystem is great, as good as ever. What do you think it's missing?
Ruby ecosystem is great, but it's not Python great.
Ruby ≈ Rails
Python >> Django
The talk isn't available online yet, but I'm excited to see what he has to say.
Also a reminder that all the heavy lifting in the AI ecosystem is done by C++ libraries, and Ruby has a great FFI for interfacing with C++. Also most app makers are just interfacing with web APIs anyway. Either way, you're covered.
Edit: basic grammar.
I worked with Rails and Phoenix in their early days and got plenty of value from each. If you're building a traditional web 2 app, look no further...similar to choosing Postgres, start there until you have really good reason to venture off.
Without taking away anything from these frameworks and as someone that spent over 10 years building app frameworks, sometimes it's not what I want.
I'm using Clojure for my current problem space which would stymy me if I tried to use Rails or Phoenix. I spent the past 4 months doing product/domain "shaping". There are no web pages yet..mostly pure server side domain and API calls for data gathering. After this exploration I now have several working subsystems and have figured out the pathway to the mvp which will come together quickly. As a bonus I have a working domain core to leverage for steps after the mvp.
I haven’t used Biff (clojure web framework, does not sound comparable to rails), but there’s a great episode of The Repl with the dev who created it. It’s one of those interviews that reminds you how fun and creative programming can be
I hope this is not as restrictive as it sounds, and you do not have to jump through hoops to do things differently:
"The starter project comes with code for sending emails with MailerSend. Until you add API keys for MailerSend and Recaptcha (which is used to protect your signin forms from bots), signin links and codes will be printed to the console instead of being emailed."
"Stymy" doesn't appear in Merriam-Webster [0] nor the OED [1]. Wiktionary [2] and Dictionary.com [3] do list it as "variant" or "alternative" spellings, but with no indication that it's an American spelling.
[0] https://www.merriam-webster.com/dictionary/stymy
[1] https://www.oed.com/search/dictionary/?q=stymy
> The presentation summarizes a year of my work but it also embeds countless little things life taught me over the 15 years since I started speaking at user groups and regional conferences.
> But this chapter of my life has now concluded. I'm excited to be moving on to other things.
I did a comparison between Rails, Adonis and Fiber (a Go "framework") before settling on Adonis (mostly due to node ecosystem and type safety).
It's been excellent so far, and the creator has an excellent series of tutorial videos that can get you up to speed quickly https://www.youtube.com/watch?app=desktop&v=jf5hHU0KT3Q. The documentation is also good. LLMs can get tripped up by older versions which you need to look out for.
I'm not familiar with Elixir/Phoenix, but from reading other recommendations in this thread and after having a quick look, I need to take a closer look :-)
"AdonisJS ships with a robust and secure authentication system you can use to log in and authenticate users of your application. Be it a server-rendered application, a SPA client, or a mobile app, you can set up authentication for all of them."
What's more is that I'm building mobile applications using Hotwire Native. I'm a solo developer building 2 mobile apps(iOS and Android), supported by a fully functional web application and done with vanilla Rails with Hotwire Native.
I'm surprised how well Rails ecosystem is suited to do everything nowadays.
Sorbet and RBS are okay but they don't really compare
You can do fine without them - Basecamp proved that. There's a good reason basically every other Rails company eventually moved to static typing though
I was impressed at recent changes in the Sorbet syntax but also with the proposal that we make code comments available to the ruby VM.
That would allow Sorbet to adopt the rbs-inline comment syntax for both runtime checks and static analysis.
So there does appear to be a way forward on this, which is pretty exciting.
What holds me, personally, from Sorbet is the fact that it tries (unwillingly) to dictate which features of Ruby are "bad" by not supporting them - specifically, "prepend" and Refinements. Now, Refinements I havent' seen used in the wild, but "prepend" I use the living hell of - both when designing modules and when overriding other libraries (with moderation, and when I do it is gawddam' well necessary).
While I can appreciate opinions, I am not really motivated to adopt a tool which snaps me on the fingers because I use the tools I know the utility of. I am not working at Stripe nor at Shop :-) Another thing I could really appreciate would be ad-hoc interfaces a-la Go - and more support for duck-typing in general. Maybe I missed this in Sorbet, but it seemed the idea was to "inherit like you are told to and shut up" - which is not how truly great things can get done in Ruby, at least in my experience.
Interesting to see where Sorbet goes in the coming years - and stoked for more RBS/Sorbet interplay!
I like static typing when it gives me a 100x speedup (Java, C++, Haskell, whatever), but not solely for the sake of it...
I know a developer who followed a similar approach in PHP.
A relative of mine is running his company as a single dev in node.js + react.
My company runs on Python.
The key skill is being a good generalist willing and capable to do all the roles you need. Every tech stack can be automated for most small business needs, so that you can reduce the time spent on it.
I think we also need to consider how much experience one has with a language. Most can pickup a new language relatively quickly, but it's not the same as having real experience with it.
At work, someone just started a new micro service written in Rust because they were familiar with Rust and thought they would be able to do something "fast". They spent at least half the time struggling with even basic dependencies, how to deploy it, monitor it and make it deployable. If this was a startup, they would have burned a significant amount of time that could have been spent on PMF
Elixir/Phoenix is far and away my favorite framework to build with, but it does leave some things up to the user in a way that Rails doesn't, eg: there is no automatic `class name -> db table` mapping, or automatically inferring what partial or form names to use by a variables name.
In my mind, this is not a downside and there are still idiomatic ways to write Phoenix code, but just to outline some philosophical differences I guess. In the end I much prefer it because everything's a bit more explicit and flexible when I want it.
I think Phoenix also expects read documentation around OTP if you want to really achieve high leverage. This is worth it, and you can sort of drip feed yourself by starting with Phoenix, recognising that Phoenix primitives [sic] are actually Elixir primitives are actually just OTP primitives and you end up with some pretty good examples of how OTP works in a system you're already familiar with.
I highly recommend checking out Elixir & Phoenix.
Working with this with a small team with one simple stack is a breath of fresh air in today's world.
I’ve always heard awesome things about elixir/beam but I only have so much love in my heart for languages without good static types. Right now that love goes to clojure!
I’ve been hearing some buzz about static types landing in elixir, and it’s definitely piquing my interest. This comment of yours has fully sold me though!
having used both, elixir feels a lot like clojure semantics with a ruby like syntax. the big advantage of elixir is the erlang vm. if you want a vm that heavily prioritizes parallelism and network programming, give elixir a try. otherise, clojure is perfectly adequate.
Was it the LiveView stuff that felt foreign? I'd agree there's a learning curve there as someone coming from Django.
https://github.com/elixir-nx/axon -> AI/neural networks
https://elixir-broadway.org/ -> consume streams from kafka or rabbitmq
https://oban.pro/ -> job processing
https://membrane.stream/ -> webrtc (make a video confrencing app)
For a skilled developer who knows any of the major MVC web frameworks, they’re all really productive, just in slightly different ways.
And now with InertiaJS, there are no more API endpoints necessary for any UI stuff. The data just gets prepared in the controller in PHP and gets directly loaded as JSON into the React/Vue/Svelte frontend pages, thats it!
In 4 out of six large, dynamic code bases I have worked in, everything becomes spaghetti. This joins with that which n+1s with yadda yadda. You end up with dependencies that prevent billing options because you can't separate the billing structure from the user model from the product table. Queries start joining and joining and you get monstrosities of queries. The beefy postgres db gets bogged down at less than 2k rps. Everything gets slower. Then the org spends millions and millions on domain separation and breaking teams away from another. Builds get slower. Competing styles of decomposition litter the codebase. Changes take days to release. It takes Herculean effort and heroics to fix a dynamic code bases that grows, eating at growth when it should be compounding.
"But it let us get here, where we can afford to do those changes." Maybe. It is the road less taken's point - you can sell yourself that the dynamic code bases allowed for the success. But that doesn't say the alternative wouldn't work.
</insomnia thoughts>
This is hardly the property of languages or frameworks - just orgs being orgs and incentives being incentives. I don't see why a codebase in a compiled lang would not have queries that "start joining and joining and you get monstrosities of queries" if the business logic demands that queriage to be queriaged?.. Maybe you could make a case to the business that the speed of rework has to be reduced "because static lang and we do things properly here" - but the same can be done with dynamic langs, just with a bit of rigor.
Speed of iteration rules above all.
My speed of iteration in dynamically typed languages is great at first, but after running in production for 8 years, coded by a team that never wrote the original, dynamic typing hurts iteration speed.
If you judge iteration speed by how fast you get to feature #3, I've got a ton of bash programs that will beat any serious language product you have on that metric.
That can be a mix of how you see it, how the business works and how the code does anything.
It is important to understand I’m not referring to dynamically vs statically typed languages or not. It’s a distraction. Code runs fast on pretty much anything these days, and dynamically typed languages have pre-compilers.
These are sometimes matters of personal experience, interpretation, preference and opinion masquerading as facts.
Most languages have to abstract from to the web using a framework and that additional interpretation is where a lot is lost.
Featuritis is the disease, solving problems solely based on customer input (who are strangers) is important. Problems are rarely a single feature, but a sequence or group of them.
The irony of bash scripts is they can be some of the most durable and well lasting parts of a project while everything around it might change and evolve quicker. So if there’s some bash scripts being called by a language in the beginning.. so what.
My original point about Laravel is I have not seen as tightly integrated of any ecosystem to ship solutions and product where so much time is not lost in the product side of it (accounts, billing, migrations, etc). While I’m relatively new to it, at the very least it’s a worth comparison to show the holes in others.
There are always attempts in every language to replicate the convention over configuration and batteries included approach of Rails, but they all lose steam pretty quickly.
I just don’t think there is an alternative to Rails. It’s a giant project that is actively developed for over 2 decades now.
Any other ones are gonna be a little niche but from what I can tell these four (with rails) have the most large and active communities atm.
When I struck out on my own I realised that I no longer had team consideration as a constraint and went a little bit off the beaten path.
Every client I have used it for has had nothing but praise for how maintainable the software is.
All jokes aside, having worked in both languages and frameworks, I’ve enjoyed the Dev experience in either option.
Grateful for both dev communities as well.
As someone who likes Rust, has one project (web based) in production in Rust, and considering starting another one, I'd be glad to learn from the experience of other people.
So far I don't know any better way of doing it and I have tried all the classic ways like PHP, Django etc. This is way superior. The only downside is that I am the only one who can touch the backend, but I guess if some of the projects grows enough, there will be enough incentives to find another Rust programmer besides me.
Both Rails and Django are horribly slow though, so once you get to some critical scale you gotta start doing some real weird stuff like Instagram did with turning off Python's GC [1], etc.
[1] https://instagram-engineering.com/copy-on-write-friendly-pyt...
"Home page should load under 2 seconds at P95", "reports should load under 10 seconds at P99", "this background task should take under 30 seconds at P99".
Having these targets (and, frankly, remembering in the B2B space is that the status quo is _so slow_) can let you set performance objectives without chasing milliseconds that you don't need to.
Django has a lot of intrinsic slowness to it, "easy" DB access patterns often lead to heavy messes, but if at the end of the day most customers are getting served under some benchmark you can reap the advantages of the tooling without sweating perf too much.
And when you set these SLOs, you can then push for even tighter ones as you figure out your problem space!
In the B2B space companies get away with _so much_ sluggish behavior, if you're better than the median that's already improving things.
Things we did: careful about N+1 queries, caching where obvious, API calls/emails/etc running in background queues.
Things we didn’t do: use a fast templating language (we used Django’s built in one and it was often our bottleneck), removing all database queries (we just had Postgres <2ms latency away), renormalising data (we were highly relational for most things).
Django is perfectly performant enough for almost all use cases, and insanely fast to develop with.
I think B2B SaaS, for "normal" teams (read: people not that adept at building scalable systems), when not careful, tend to make omnipages where about 20 different things are happening. Even just navigating to a page ends up triggering random side effects (driven by various needs).
There you can easily find yourself in a performance pit that you have to dig yourself out of (often redesigning features in the process to remove some stuff).
I just find that setting fairly easy performance goals can help to make perf seem more tractable.
.Net has tons of configuration and boilerplate so I can't say that it's exactly the same in that sense, but the more meta theme is that just as there is a Rails way to do things, there is a Microsoft way to do things. Unlike Java where you're relying on lots of third party packages that while well maintained, aren't owned by the same company that does the language, framework, ORM, database, cloud provider, IDE and so on. Having a solid well documented default option that will work for 99% of use cases takes a lot of the load of decision making off your shoulders and also means you'll have plenty of solid documentation and examples you can follow. I've been in JVM land for the past couple years and it just can't compare.
I know Java people will come fight with me after this but I just don't think they know any better.
But I just want to say that I have the same feel when I develop using Spring Boot. I am extremely productive and seldom have to pull dependencies outside Spring for 80% of what I make.
But I guess Spring tried to do that, but probably didn't have the resources that Microsoft does.
https://news.ycombinator.com/item?id=10135825
https://github.com/dotnet/core/blob/main/release-notes%2F1.0...
People aren't just going to jump onto something recently open-sourced by a company that popularized the phrase "embrace, extend, extinguish". For the last decade, they've had to earn people's goodwill, while with a project like Rails, there is no "we used to be closed source but now we're not, use our thing!" to overcome. So in the 20 years since Rails has been released, it has only ever needed to demonstrate its usefulness.
Now that a decade has past, that negative association is starting to wash away a little.
I can't really say how the web UI side holds up to alternatives, tho.
Take a look at this: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
I’m pretty sure even back then Entity Framework was very capable, it has only improved since then.
https://learn.microsoft.com/en-us/ef/core/querying/complex-q...
It’s probably better to compare with other statically typed, compiled languages since both Ruby and Python are an in a different class (and an order of magnitude slower, more painful dependency management, etc.).
With admin, you basically just write models, and the entire rest of your app is free. Not quite, but, not far off.
Just choose anything popular and there should be plenty of help available.
I've been using Laravel for about 11 years now. I hate it, but it keeps on trucking along so I've resisted the urge to do a complete rewrite. I don't think anything is particularly slow to develop.
It's the business side of things that's the hard part.
There's such a high churn to the ecosystem and the way things are wired together, I feel like a beginner every time I use it. Volt is really bad. I need to be clear, it's really bad and adds nothing. We had a separation of concerns, then we had backend logic in Livewire components with Alpine JS, and now everything is in the view again, only with a Frankenstein of all three options. At best, its introduction is change for the sake of change, and at worst, they are trying to make deployment "complicated" to drive adoption to their paid offerings, which are marketed for managing this complexity.
It's easy to have bugs, in general, that are hard to catch due to way things are wired. I think Filament is good tech, but I had a lot of issues using Filament on Laravel 12 with Volt. There was a big impedance mismatch and figuring out why my layout was suddenly broken when navigating to the admin page, in a brand new app, was not fun. That should not be the experience. It should be obvious how things are wired together.
And while I'm definitely not a Laravel ecosystem expert, when I have an issue, I have had to explain how Laravel works to others who bill themselves as experts. I don't think it's because they're fake experts, I think it's because Laravel is so hard to "know." There's so much opaqueness with the OOP magic strings and dynamic calls that people have had to make assumptions on how the code is run. And you can maybe get far doing that. But if you're unlucky enough to run into an issue, you're at the mercy of some poorly laid out (but verbose) docs to find out why a certain bug is happening.
I try to avoid hacking the framework or needing to know it's magic. The point of an opinionated framework is to just do things their way. This works for me 95% of the time. The few times I need to do something non-standard, I don't mind spending time hacking.
It sounds like you're building a lot of new projects in Laravel rather than maintaining a single one over the years.
I find ruby (and rails) to bring the opposite of joy. I find myself frustrated. On the opposite end of magic is Go. I love Go. Tests are just code; no magic needed, not even mocks. Methods behave and usage is consistent. Code is navigable. Types make everything more explicit and easy to follow and more maintainable.
I assert Go leads to org happiness, letting teams work together productively.
For anyone else reading this and considering Ruby I have to say the followings:
1. No, there is no magic in Ruby but there is flexibility and metaprogramming. Everything that appears magic is allowed by Ruby syntax and can be traced down to a few meta programmimg features. It might be hard to get it when you see it first, but please do make sure you understand Ruby and then you will also get the magic.
2. You can choose to use Minitest (which is Rails default testing framework) instead of RSpec and Minitest is Ruby code with few methods for assertion.
3. Mocking is an important part of testing
4. In any programming language and even agnostic of any programming language knowing how to code is different than knowing how to test. The testing framework is just an abstraction that should translate your test cases into executable tests.
But somehow, no one complains about having a GC instead of needing to use `malloc`/`free` or `fetch` doing the DNS query automatically.
And that's exactly _why_ I use frameworks and libraries. So I don't have to write low level code, or as one could call it, to use some magic.
I personally can't handle it. It's completely frustrating. Nothings documents what your system is doing, and nobody on the community seems to have an inch of clue about what exactly is happening on their computers. But you can't deny that it works, and works well... unless you need to override something due to a niche use-case.
Billions of people deal with slow web apps that collectively waste millions of years of people's lives so that the a few developers can save a few hours of work.
We could increase global white collar productivity by 10-20% almost immediately if developers would stop valuing their productivity over the productivity of their end users.
Org dysfunction.
Note that those were web apps - so the user did not have to install the runtime, dependencies etc. to use the software. That is a whole other story (and not a very merry one, at least for all the scripting languages out there).
> The code represented not just PlanGo's evolution, but my own journey from a beginner to a more experienced developer. Parts of the codebase contained decisions made by different versions of myself, with varying levels of experience and understanding.
I've joined a few companies where the codebase was started by a (cough) inexperienced developer. The hardest thing is always breaking down someone's ego about their code. The most challenging is when a person in power needs rather (cough) forceful convincing that something needs to change.
One thing I'd be curious about are situations where Jetten had to let his ego go and learn from his co-worker.
Needless to say, in my other comment in this thread, https://news.ycombinator.com/item?id=43836305 I didn't "fight" the battle against the rewrite. But I did fight, and win, the battle to remove a very poorly designed ORM.
I think that aside from Rails, that makes it one of the easiest languages to pick up and have fun with. I do miss my Rails days for that reason.
Or just don't offer support. :)
> The rewrite took a couple of intense months, during which I maintained the existing application while building its replacement.
Having been through a rewrite in the past: You made the right decision. If a rewrite really is only a couple of intense months, it's worth it.
Otherwise, when your application gets into the "full of bad practices"; the alternative is to do major refactors.
I suspect that the application was small enough that the rewrite made more sense than a refactor.
I can't emphasize this enough. Did the same with a monolithic PHP application. David Heinemeier Hanson used the term 'majestic monolith' and it really feels like that, working on some cathedral in code.
Congrats on your good choices and results. A programming language that you like is important, but I think you should give your own decision making some more credit.
(coming from close to a decade of Rails experience on my end)
I run multiple apps as single developer and Laravel has a great community.
Laravel has a lot of similarities to Rails.
Does Spring Boot qualify in this sense?
No depdancies. Frontend react as well as SSR included as jsx. Faster than fastify. JS/ES/TS runtime agonstic. Native tsx jsx support.
Hono really needs something like axum's debug_handler
For concurrency, async fibres are brilliant but not the only game in town.
Using good old processes works really well in Pitchfork or alternatively JRuby and TruffleRuby both have true non-blocking parallelism right now using Threads.
If anything TruffleRuby shows that there is nothing inherient in the Ruby language that means it cannot catch up in performance terms.
My personal dev speed however is a little slower in Phoenix than Rails. And I've been using Rails for almost 20 years and Elixir for 10.
There are categories of problems that are much easier in Elixir (High concurrency, low latency, etc) and for those I would always pick Elixir. If you're planning "just" a crud like web application, Ruby will probably get you to product-market-fit faster. There are (well maintained) gems for almost everything.
You could build the same thing with nodes or python or golang or whatever.
There’s nothing special about rails, except that the developers speak like it’s special.
There’s nothing that can be quantified in any tangible way to indicate it’s actually better in any way. Rails has enthusiastic words, but it’s not actually better.
"I used technologies and tools I was already very well familiar with: Node.js + Express for the backend and React for the frontend."