If you have been following me on X for the past few months, you might have noticed that I've moved on from ASP.NET Core to Ruby on Rails. Some people asked why...
TL;DR
If you are looking for a detailed technical - or even performance - comparison between Ruby on Rails and ASP.NET Core, this article is not for you - it only contains opinions, learnings and stories from everyday usage.
Back in early 2015, I've said Farewell.
It was a farewell to Windows and .NET for technical reasons.
Windows felt bumpy and .NET wasn't available on Linux (I know there's been Mono).
So I went along with Linux and Node.js for several years.
Time moved on and somewhere between 2020 and 2021 I gave .NET - now fully cross platform - another shot. This would not have happened without JetBrains Rider, btw.
I've started building some stuff using C# and F# and ASP.NET Core, of course.
Stars really seemed to align again, when I discovered Marten and Wolverine for Event Sourcing and Messaging.
With ASP.NET Core MVC, HTMX, Marten, Wolverine, Vertical Slice Architecture and Rider I've enjoyed software development like I didn't for ages.
I've written almost 30 articles for a major German .NET magazine during that time about these topics.
[Narrators voice: Scene 1]
However, there was an elephant in the room: Microsoft.
Back around 2018, I had the questionable joy of dealing with Microsoft Germany in a customer project.
After finishing it, I've decided to never do anything related to Microsoft Azure again.
"Why is this important?" you may ask.
While .NET is open source software (OSS) at first sight, it is still tied to Microsoft. Back in the days when it has been Windows only, it has been a vehicle driving sales for Visual Studio and kept people on Windows.
As cloud has become Microsoft's major business, .NET has aimed at getting developers to use Azure for their deployments.
Not by making it the only choice, but by making it the default and easy one - and nobody gets fired for choosing Microsoft.
As I've been using Docker since it's early days, this hasn't been much of an issue for me - I could re-use my deployment scripts from Node.js with almost zero changes - give me a VPS and I'm good to go.
While I could ignore most of this stuff, it has always been around - the well known ".NET Drama" like not releasing the debugger as open source, constantly re-inventing successful community packages and stuff like that.
Speaking of re-inventing stuff: Microsoft has a knack for building UI frameworks nobody likes (except the chosen few). Be it Silveright, MAUI or whatever year you pick.
Back in 2018, Microsoft announced "Blazor", their latest idea of how component based web development should be done. Driven by the pressure of client side frameworks like React and whatever Next.js is, they started building something similar based on .NET and Web Assembly.
Over the years this has evolved into something with several hosting models.
I don't know what's its current state, but several people tried to make it work with libraries like HTMX and it seemed to be a PITA to me - do it the way Microsoft invented it or just stick with ASP.NET Core MVC.
I did the latter because "what should possibly go wrong?". I was wrong. Over time, Microsoft started to make "optimiziations" in ASP.NET Core which started to more or less break stuff in MVC.
Furthermore, it is virtually no longer actively maintained, as can be seen from the GitHub issues.
[Narrators voice: Scene 2]
With short breaks, Linux has been my daily driver (speaking of Desktop OS) since mid 2014 - Ubuntu most of the time.
Ubuntu has become more and more mainstream and at some point they've decided to switch to Gnome Desktop as their default.
While it became more polished, it also became less of a developer OS and it felt like the Desktop got in my way when I wanted to do things.
Mid-2024 Linux got a new advocate: David Heinemeier Hannson (DHH) came up with Omakub, "An Omakase Developer Setup for Ubuntu 24.04+".
It has been a nice match for my new TUXEDO Desktop. At least for while...
While Alacritty and Tactile have been some nice improvements for Window management, it felt sort of unnatural with Ubuntu.
As it turned out, DHH felt the same and Mid-2025 he came up with the real banger: Omarchy:
A super polished Linux Desktop environment for developers based on Arch Linux and Hyprland, a tiling window manager.
It has hit like a bombshell, and it is unlikely that you have not already heard about it.
It's the daily driver on my Gen5 ThinkPad L14 since then and I've installed it on several outdated Apple hardware like a Late 2012 Mac mini and a Mid-2012 MacBook Pro.
It also got me back to vim as my primary editor by making neovim the default for a lot of stuff in Omarchy.
I even started using it for ASP.NET Core development and I already started to write a blog post on how to do full time ASP.NET Core development using neovim in summer 2025.
[Narrators voice: Scene 3]
I've been a software developer most of my career but for some reasons I became a CEO in manufacturing by the end of 2024.
At that time, the company has been running on a typical stack:
While I could accept things, I haven't been happy with it.
The whole stack has been maintained by several companies via support contracts.
Side note: back in the late 90ties I've been a sage Partner myself so I know a thing or two about the software in question.
Apart from the relationship with the system vendor, which is responsible for the network infrastructure, Windows and Office, user satisfaction with support is rather low.
Given all the "you're not the customer, you're the product" features in Windows 11 and Office creeping in, I've avoided the migration from Windows 10 for the company as long as I could.
This paid off when Microsoft announced that Windows 10 support would be extended for another year in the EU.
Speaking of SolidWorks: you get more support from the forums on the Internet than from official Partners you're paying for it.
Regarding sage, things got worse when we tried to pull some data out of it and eventually getting rid of the software at all.
Back in the days, this has been a no-brainer using pure SQL until 2008 and later DCOM.
Trying this in 2025, DCOM has stopped working - as it turned out, libraries haven't been installed on intent (make the customer pay as often as you can).
They tried to sell us a "project" where our "requirements would be evaluated" and then the typical dance would start - for a problem that could be purely solved using a single SQL SELECT statement until 2008 or roughly 10 lines of C# Code via DCOM.
When I discovered this on a Saturday in mid-September 2025, the topic of proprietary ecosystems was finally dead to me.
On that day, I decided that we would end our collaboration with all of the aforementioned software manufacturers by mid-2026 and also replace Windows entirely with Linux - remember: we're a manufacturing company, not a software business.
As mentioned earlier, Omakub and Omarchy are based on the principle of Omacom.
Omacom stands for Omakase Computing. The word Omakase means "I'll leave it up to you" or "chef's choice" in Japanese.
It's the idea that most people don't actually know what they want, at least not at first. That they're better off getting something beautifully curated and integrated from someone they trust to make competent, tasteful decisions rather than suffer from the paradox of choice.
By watching DHHs videos on Omarchy, I found out that Ruby on Rails has been following this principle for a long time already.
As I've been happy with the chef's choices in Omarchy, I've decided to take a closer look at Rails.
I managed to completely ignore it until this time - I didn't even look at it when I was looking for an cross platform alternative to ASP.NET back in 2014.
Setting Rails up was a no-brainer thanks to mise which is the default in Omarchy to manage dev tools.
After reading some Rails Guides on their website, I wanted to get results fast, so I opted for AI ("Vibe Coding") to build some applications I would have built using ASP.NET Core anyway using Rails.
Mid-September 2025 I've been using ChatGPT most of the time and vibe coding a Rails app that would use Postgres and Tailwind started off quite well but at some point it got me bad vibes.
As I've posted some of my progress on X, people started to recommend Claude instead of ChatGPT and now things really took off.
Within a few days I've built an end-to-end app to track material requirements from the shop floor, incoming goods and invoice verification. This included stuff like stamping PDFs for approval.
One thing I wanted to verify early has been deployments and this is where Rails and the "majestic monolith" you build really shines.
When creating a new Rails app, it also initializes Kamal - Omakase for deployments based on Docker.
After providing a minimal set of credentials and settings I got the app deployed on our staging VM in our Proxmox setup.
That has been the time when I was hooked already.
But I wanted to build more - on the one hand, to continue testing Rails, and on the other, because I needed alternatives to the existing software for the reasons mentioned above.
We've been using Word for product documentation - customers don't want Markdown when they purchase industrial machinery or equipment.
As I've been looking for an alternative for this process, I came along AsciiDoc. So I made a manual proof of concept for one of our machinery documentation first.
Next, I wanted to have a platform to manage documentations (versions, text modules etc.).
So I set up another Rails app using Claude and a few days later we've been using this already to create a documentation for a just finished machinery project.
The Rails app at this time already had HTML/PDF live preview and automated translation using the DeepL API. You could also manage the assets like images and pictograms (via Rails ActiveStorage).
Sometimes the universe sends you a message.
In October, the employee who prepares the time sheets for payroll accounting fell ill.
I then did the payroll stuff and realized how little the current software supported us in this process.
This made it clear what would happen next: software for time tracking and reporting using Rails.
This time, however, using Event Sourcing.
I picked Rails Event Store and let Claude do it's job.
Long story short: since December timesheets run on Rails.
So as not to bore you further with apps, here is a short list of what else I have built with Rails and is already in use at our company:
I am also working on a system for instant piping quotes that will be connected to Shopify.
While I relied almost entirely on Claude at the beginning to quickly produce code (which I still reviewed), I naturally became more and more involved with Rails over time.
In the process, I have also grown to appreciate and love Rails more and more.
What excites me is the open approach, and that is exactly what I still found lacking in ASP.NET Core, even though it is open source. What do I mean by an open approach?
When reading the ASP.NET documentation, there are repeated references to how to perform certain tasks with Visual Studio.
This distracts from the actual problem you want to solve and shows what Microsoft really wants to achieve: buy our tool.
When it comes to deployment, the "easy way" always points to Azure.
As already mentioned, Rails has no preference here: if you have a server running Docker, you can deploy with Kamal. End of story.
But even beyond that, it's always exciting to see that the people who maintain and develop Rails also use it to develop applications.
This is evident in many small details.
If you use includes, for example, you can see where an include begins and ends in the HTML code in the browser during development. This makes visual debugging much easier.
Another example is setting up a new project with Rails.
You can configure so many options - and it's easy to do using the Rails CLI: which type of database, the CSS framework and which parts not to scaffold at an insane level of granularity.
Another great feature is the Rails Console. You can easily interact with your application and database.
With Hotwire and Turbo, Rails offers an approach to integrating JavaScript into Rails applications.
With Turbo, it takes a similar approach to HTMX.
Everything is opt-in and lightweight.
Finally, I would like to circle back to the TL;DR at the beginning and briefly address the topic of performance comparison:
Ruby - and therefore Rails - is not the fastest platform on the planet.
But at the very least, a platform like Shopify has been running on it since the beginning, managing billions in sales for tens of thousands of companies.
So if I ever need to scale Rails to this extent with our company, which has fewer than 20 employees, I will gladly take on the challenge and still have fun doing it.