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.
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.
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).
Do you know about Hotwire? It's Rail's html over the wire solution and seems comparable to Blazor.
