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)
For the most part, I think there is a lot of feature parity between the .NET and Ruby on Rails frameworks when it comes to developer tooling.
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.
> 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
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.
I would advise against Blazor Server. In contrast to standard frontend SPA frameworks, Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state. I found that connection is easily/fequently disrupted resulting in an app reset, lost state, and poor user experience, to say nothing of the scalability implications.
Though, for a purely back-office app with minimal state, that might be OK
> Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state
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).
It sounds like you have been using Blazor a lot more than I have so I’ll take your word for it. I haven’t any massive traffic yet. Is this something I can reproduce with a benchmarking tool?
But your comment comparing Blazor to Rails seems to be about the current state of Blazor and Rails. So currently Hotwire for Rails is production ready. So with Rails, you don't necessarily have to introduce React as you comment claims.
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.