Any interest in doing a short comparison? As in, why are you in no rush to switch back to rails? Any features you miss from rails? (edit: register beat me to it. I'll leave my post as a +1)
As I grow older I guess I am growing more fond of statically typed languages. It's easier for my decaying/distracted brain to reason about. There is less mental overhead I suppose [might be a good blog post?]
They both have a good database migration system and various generators for scaffolding views, controllers, etc. To be fair I believe Entity Framework does most of the work for the .NET side on the database developer tooling but I just consider it part of the .NET ecosystem since it seems to be the go-to ORM/database tooling library. I want to be fair to Rails -- I really think they set the bar very high for other frameworks. Productivity w/ Rails was unprecedented when it first came out. I started during the Rails 3 to 4 upgrade.
Both ecosystems have easy access to outside libraries using Nuget/Gemfile. So pulling in a background processor like Sidekiq [Ruby] or Hangfire [C#] is fairly easy.
Cross platform support is acceptable across both frameworks as well. I can setup an EC2 instance and run both Rails and .NET applications side-by-side. So deployments are going to be similar but I would argue that .NET has the upper-hand because it can deploy do a self-contained deploy so you don't have to worry about installing dotnet in the deployment environment.
I am using Blazor Server and I am not going to say something drastic like it will kill React but it is pretty awesome. I can build my entire web experience with C# but with Rails I have to introduce React when I sometimes dont want to. Blazor prevents me from having to write HTTP code from my front to backend systems and as an indie developer that is a godsend.
Both have gorgeous documentation -- I thought Rails was good and thorough but .NET ate their lunch.
Do you know about Hotwire? It's Rail's html over the wire solution and seems comparable to Blazor.
Though, for a purely back-office app with minimal state, that might be OK
Blazor Server retains the circuit for up to 3 minutes if the connection is lost, so you do not loose the connection even if the websocket connection is interrupted.
It is also not correct that it needs a websocket connection. It builds on SignalR which will use websockets if available but will fall back to other methods such as long polling to emulate a persistent connection.
Blazor Server absolutely has it's place, but you need to know when that is. You can even scale it out on multiple servers, but at least until .NET 7 you'll need to ensure "sticky" connections (the client must connect to the same server based on e.g. IP address, cookie or similar).
I'm not even sure it's an "older" thing -- it's nice just to have less mental overhead.
The things that used to turn me off from static languages (eg: most of the benefits dynamic languages have) have disappeared. Generics allows creation of some powerful re-usable code (eg, List<T> or RunningAverage<T>). Tools to easily convert any random JSON or XML to concrete classes make it a simple extra step to consume any API.
The benefits are massive. Code-completion just frees your brain from having to remember or deeply think about what's available. Type-safety giving compile-time (or even coding-time) errors prevents so many stupid problems that, in a dynamic language, take a runtime check to find.