I grew up on C# and tried server side JS recently, and my god, the decision fatigue of picking every little library to do every little thing! C# is just so batteries-included. I'm not sure Blazor is ready for prime time but I like the promise of being able to use C# everywhere.
The Case for C# and .NET
21–30 of 376 posts
Re: The Case for C# and .NET
#22> For the front-end, JavaScript is unavoidable (for now) Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment. I've learned I can add events and event handlers to elements without ever leaving C#. Then…
In theory, blazor is really neat. But last I checked you have to either go fully thin-client (server side blazor) or have an annoyingly large initial download (client side blazor). Which is probably fine if everyone's wired to the company network, but maybe less so if there's mobile involved or the general public needs access from the local coffee shop.
I'm currently playing around with server side Blazor and it works well. It's definitely not for general public applications but it seems great for internal corporate apps.
The issue that I have is since it is a thin-client re-deploys kick everyone off immediately. Where the web is totally stateless this is 100% state full. I'm used to being able to deploy production fixes rapidly without disturbing anyone's work but with Blazor server that's impossible. I've started to look into load-balancing solutions or something but not being able to roll out fixes throughout the day is almost a deal breaker for me.
Re: The Case for C# and .NET
#23> For the front-end, JavaScript is unavoidable (for now) Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment. I've learned I can add events and event handlers to elements without ever leaving C#. Then…
Blazor server was not executed on well. It's a poor react clone before react had hooks. The ecosystem is also small and not flexible. I would choose javascript over it, unless I already had a large investment in C#/.NET.
Re: The Case for C# and .NET
#24> For the front-end, JavaScript is unavoidable (for now) Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment. I've learned I can add events and event handlers to elements without ever leaving C#. Then…
Can confirm, we’re developing in Blazor now and it’s fine. Not as loosey goosey as js, but makes as much sense as any other js framework. And having such tight integration with Entity Framework makes development a breeze.
Blazor server or wasm?
Re: The Case for C# and .NET
#25Mostly agree with the author. But just wanted to point out that if we're doing C#/Java style OO patterns in JS (as in the Repository example shown), the value of using JS diminishes to almost nothing. JS works better without classes (and interfaces against them if using TypeScript).
Re: The Case for C# and .NET
#26Earlier quoted context omitted.
They also have a history of randomly deciding to dump a technology (including full languages) too, leaving those invested in it holding the bag. I like F# too, but I'll stick with one of it's non-MS controlled alternatives.
any software project or language can die, but I honestly struggle to think of a company that has a better history of long term support than Microsoft. You can fault Microsoft for quite a few things but their ability to maintain software and provide stable interfaces for devs is second to none.
MS discontinues a UI library project and then hypes up a new one every few years. Today Blazor and Maui are hot, but there's a lot of abandonware that came before.
You can see it in Windows too, where you can burrow deeper and deeper into progressively older settings dialogs, because they reshuffle the Control Panel every few years.
Re: The Case for C# and .NET
#27Earlier quoted context omitted.
They also have a history of randomly deciding to dump a technology (including full languages) too, leaving those invested in it holding the bag. I like F# too, but I'll stick with one of it's non-MS controlled alternatives.
Not with their core languages. For example, Windows still comes bundled with the old VB6 runtimes and Microsoft still supports the language even if they no longer add features to it. I'm not really sure of any major Microsoft languages that Microsoft has just dumped, unless you count their smaller more esoteric ones. Also keep in mind that .NET Core is not only open source, but comes with complete protection from any…
> still supports the language even if they no longer add features to it
This is what I assumed the parent post was referring to. Mostly because it mirrors complaints I've heard (and maybe had) about the .net gui story. WinForms -> WPF -> whatever the windows store app framework was called -> I think MAUI now?
Re: The Case for C# and .NET
#28Earlier quoted context omitted.
They also have a history of randomly deciding to dump a technology (including full languages) too, leaving those invested in it holding the bag. I like F# too, but I'll stick with one of it's non-MS controlled alternatives.
any software project or language can die, but I honestly struggle to think of a company that has a better history of long term support than Microsoft. You can fault Microsoft for quite a few things but their ability to maintain software and provide stable interfaces for devs is second to none.
I hear some of IBM's stuff has a pretty long history to it.
Re: The Case for C# and .NET
#29C# and TypeScript seem to be far and away the most popular programming languages today. At least from the perspective of recruiting in Australia. Python is on the way up and third most popular but well behind C# and TypeScript. Golang is on the way up but very small in terms of number of developers. Java is on the way down but will never vanish, it's just not super popular any more. Ruby is small enough to just be a…
> Python is on the way up and third most popular but well behind C# and TypeScript. lolwut. TypeScript is niche compared to Python.
> from the perspective of recruiting in Australia.
Even accounting for that line from the comment?
Re: The Case for C# and .NET
#30I wouldn't lose a second to C# or any MS platform unless required for employment reasons.