9 ms·

The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there. The interop layer than you have to go through to do a lot of stuff

by R0b0t1 5y ago

The .NET frameworks (blazor, etc) are too complicated. Peak FizzBuzzEnterpriseEdition there. 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.

tester756 5y ago
>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
- R0b0t1 5y ago
  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.
  - nightski 5y ago
    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.
    - emteycz 5y ago
      They probably mean .NET Core, it's somewhat true in that case.
  - immutology 5y ago
    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.
    - withinboredom 5y ago
      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-screen-is-turned-off-in-linux/ https://withinboredom.info/blog/2019/11/26/detecting-if-a-sc...
    - ok123456 5y ago
      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.
userbinator 5y ago
That's the normal Java culture, which is not surprising given that MS created .NET as a competitor to Java.
Shalomboy 5y ago
> 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.
kumarvvr 5y ago
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.
- starik36 5y ago
  > 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.
  - deleted 5y ago
    [deleted]
  - kumarvvr 5y ago
    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.
    - spaetzleesser 5y ago
      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.
      - 5y ago
hackerfromthefu 5y ago
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!

by R0b0t1 5y ago

tester756 5y ago

>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

R0b0t1 5y ago
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.
- nightski 5y ago
  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.
  - emteycz 5y ago
    They probably mean .NET Core, it's somewhat true in that case.
- immutology 5y ago
  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.
  - withinboredom 5y ago
    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-screen-is-turned-off-in-linux/ https://withinboredom.info/blog/2019/11/26/detecting-if-a-sc...
  - ok123456 5y ago
    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.

userbinator 5y ago

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

Shalomboy 5y ago

> 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.

kumarvvr 5y ago

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.

starik36 5y ago
> 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.
- deleted 5y ago
  [deleted]
- kumarvvr 5y ago
  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.
  - spaetzleesser 5y ago
    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.
    - 5y ago

hackerfromthefu 5y ago

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!