Blazor IMV is more sane than React. It is an SPA that is structured around routing and pages, which happen to have component hierarchies in them.

React is the other way around. Routing in React seems to be an afterthought. And I hate it with a passion.

Page based way of thinking (or "screens" if you will) is a better way to do web dev.

Also, the Dependency Injection system is extremely productive. State management in Blazor is very easy and a breeze to use.

If not for the intricacies of hosting models, and a slightly large default build size for the full WASM client mode, Blazor would have replaced React / Angular / Vue by now.

> Dependency Injection system is extremely productive

Sure, but there is a downside to it. You want to add a feature to the class that uses DI? Great, just add an injected object to the constructor. Except now a 100 unit tests broke because you changed the constructor. A 10 minute functionality change turns into a massive cut and paste operation in your Tests project.

I solved this with a test helper method that creates a fully mocked instance and returns a struct with the mocked instance and all the mocks that it consumes. Unit test setup starts by getting a new instance and overriding the mocks that it cares about. Now constructor breakage is isolated to fixing the default mocks in the helper method.

Maybe I should write this up somewhere.

>Maybe I should write this up somewhere.

Please do, as it sounds interesting.

I did that too and it should be the default. Constructor injection is a bad pattern.

What do you mean by "constructor injection"?

In .NET a lot of DI is done by adding another interface to the constructor. So if you need some service way down the stack you add it to the constructor. This then in turn can require adding this dependency to all the tests that use this service.

Comments like these really amaze me. What sort of competent editor cannot handle such simple refactorings?

My comment describes a way to organize unit tests to work around this issue.

Maybe but in Blazor you have the choice of Property or Constructor DI. This choice is in all the major DI container libraries I've worked with in .NET, around a dozen over the years.

We use a tool called AutoFixture to automatically generate objects being tested. It will automatically mock constructor dependencies, so a change like you described doesn't require any test changes unless the new mock requires some setup for the test to pass.

Sorry, if tests are not adaptable to changing code, why are they called tests?

I thought tesring was to check software,not be a constraint on software development.

Also, I think using DI in the test process itself will mitigate the issue.

Some tests are not adaptable to changing code because of the way MS uses DI. A lot of DI is done by adding new parameters to the constructor.

It’s the same with async. Needing an async function somewhere can result in a huge cascade of changes.

Constructor inject is generally a positive here, though, as the compiler will tell you where you need to add the new dependency. If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.

“If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.”

Sure in theory this is correct but you can’t always anticipate future needs. The class may still have very clearly defined responsibility but it just needs another piece of information that you can get only with DI. I feel this over dependence on DI in .NET forces you to design around the framework and not around what makes sense.

I have seen that too. They do way too much DI.

>The interop layer than you have to go through to do a lot of stuff is actually quite tame. It just needs more time on Linux.

What do you mean?

I have software on prod on Linux for years and the only problem I had was lack of some fonts installed that made some problem when it comes to pdf generation

Binding to C/C++ libraries or other system libraries is not something that's well documented, officially. On Windows there's a lot of 3rd party effort that is easily searchable. But for a long time the interop layer was not (and still may not be?) working on Linux.

The first iterations of .NET were just for webapps. You could only work with and call .NET code, the only functions provided were basic IO and network.

Native interop in .NET has always been via what they call "P/Invoke". On .NET Core, P/Invoke is cross-platform and you can also call .so/.dylib functions on Linux/MacOS just like you could always call .dll functions on Windows on .NET Framework before we had .NET Core.

I'm curious to know what you needed to do with native libraries. I've been programming with .NET around 20 yrs and find it fairly rare that I need to use P/Invoke... But I'm sure it depends on what you're building.

I maintain a thingy written in C# that does cool things with keyboard backlights on System76 machines in Linux. Like make the left-third respond to CPU usage, right third blink when you have unread notifications, etc. The biggest one was turning off the keyboard when the screen blanked[1]. Almost all of the fun stuff requires native interop.

1: https://withinboredom.info/blog/2019/11/26/detecting-if-a-sc...

You end up using P/Invoke any time you need to control hardware. In the last few months I needed to use P/Invoke to control cameras, motors, and compute FFTs with the GPU.

You need to use them if you need to control raw GDI objects like bitmaps.

Hmm, I've been using .NET since beta 1 in 2000. Maybe you had access to earlier bits? It was never just about webapps. In fact, Windows Forms was meant as a more sane MFC if anything.

Interop with native code was always very easy. From PInvoke to managed C++ there were a lot of ways to do it with ease. Things have changed but I still think this is one area where .NET has great support.

They probably mean .NET Core, it's somewhat true in that case.

> The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there.

I dunno, Blazor feels like the one ASP framework that makes sense. MVC, Web Apps, Web Forms all feel impenetrable to me.

Compared to JS SPAs such as React/Vue/Angular, Blazor obviates a huge amount of toolchain complexity, multi-language and transpilation impedance, and jank of leaky abstractions building a component model on top of Javascript.

Having worked with a mix of these, I found Blazor to be clearly much simpler, approaching though not quite reaching the simplest possible implementation for a component based UI.

I think it's probably more a matter of what you are used to than inherent complexity. The things you are familiar with seem 'easy' and the unknown seems 'hard'.

Stick with it, it really pays dividends when you get good at it!

That's the normal Java culture, which is not surprising given that MS created .NET as a competitor to Java.