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?
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."
> 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 :-)
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
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.
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.
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.
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.
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.
.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.
I can't really say how the web UI side holds up to alternatives, tho.
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 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.
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.
> 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."
