4 ms·

The technical platform is strong but the ecosystem is weak, so it's advanced in some areas but lacking in others. Basically if a technology can't be hosted on A

by mythz 3y ago

The technical platform is strong but the ecosystem is weak, so it's advanced in some areas but lacking in others. Basically if a technology can't be hosted on Azure or monetized in some other way it doesn't get first class attention from MS and therefore rendered a niche since .NET's 3rd Party OSS ecosystem is weak. But the C# language is a well-designed modern statically typed language that enjoys best in class IDE tooling from JetBrains and Microsoft. The .NET Runtime is also a stellar performer, especially for a productive high-level language like C#. It also has some great tech that doesn't exist elsewhere, like Blazor which allows you to build entire websites (backend and frontend) with C#, although there are tradeoffs for pages needing interactivity where you can choose between Blazor Server which maintains a stateful rendering session on the server or WASM which requires a large download with slower initial start times. Personally I avoid both Blazor Interactivity options and go with Blazor Static Rendering enhanced with progressive JS which avoids both tradeoffs whilst enjoying great SSR/FCP performance and SPA performance without SPA complexity with the intelligent fine-grained updates in Blazor's enhanced navigation [1]. Blazor's Streaming Rendering is also the most elegant solution I've seen for delivering a live auto updating page with minimal effort [2]. [1] https://servicestack.net/posts/net8-best-blazor https://servicestack.net/posts/net8-best-blazor [2] https://learn.microsoft.com/en-us/aspnet/core/blazor/components/rendering?view=aspnetcore-8.0#streaming-rendering https://learn.microsoft.com/en-us/aspnet/core/blazor/compone...

JackMorgan 3y ago
Frankly, having lived and upgraded many projects through asp web forms, wpf, silverlight, and razor, I've decided "never trust .NET UI libraries to survive". So I'm avoiding Blazor entirely and just sticking with the react ecosystem. I trust that 100x more than I trust Blazor, partly because the ecosystem and user base is 100x larger. I won't be the slightest bit surprised to see Blazor tossed in the trash in three years, but I'll eat my hat if react is gone by then. Sure, maybe it's popularity will wane for some other similar library, in which case I'll switch to that. But I'm sticking with the beaten path on the front end.
- cjk2 3y ago
  Ha we still have all of those (apart from Silverlight) in production. A number of years ago I had to get an overexcited architect to not rewrite everything in Silverlight. Front end .Net is a shit show. You are right to stay the hell away from it.
- mythz 3y ago
  You've got good reasons for not trusting any .NET GUI libraries from Microsoft, I don't either since they all ultimately end up abandoned however that doesn't definitely doesn't apply to their premier Server frameworks which enjoys first class long lasting support. Razor didn't go anywhere, it's still the predominant language .NET Server HTML Views is written in since its release in 2010, whether it's in MVC, Razor Pages or even Blazor which enjoys the same familiar statically-typed syntax with great tooling and high performance compiled views. There's no chance that's going to happen with Blazor, which has become the future of .NET Web App development, it's a unique technology that's highly versatile whose multiple rendering options supports a wide number of different use-cases that's enjoyed by most of .NET developers. Personally I think it's a fresh of breath air after several years of fragile npm SPA development with broken upgrades stemming from its 100s of deps of varying quality and uncoordinated releases. All I liked from SPAs is its fast navigation, but we also get that from Blazor's Enhanced navigation without SPA complexity, heavy client state, maintaining client side routing, poor SEO, large complex builds, etc.
  - JackMorgan 3y ago
    It's a bold claim to say that the team that produced a half dozen failures in a row has "no chance" of producing another failure. I will set a calendar reminder for five years "is Blazor still around" and I'm pretty confident the result will be "well yes but it's terrible for these reasons, but this new library Tazor is the future of .NET web UI and it's not going anywhere!"
    - mythz 3y ago
      That's not all from the same team, Microsoft is a 2T company with software in every industry. Their GUI suffered through lack of investment and neglect. Their Web Server frameworks are producing software running on their cloud, Windows servers and infrastructure products like SQL Server, all enjoying multi-billion dollar businesses. Extrapolating abandonment of Windows GUI software with poor business models, with cross-platform libraries running on growing revenue centers is foley, I'll happily take any "5 year Blazor" bet.
bborud 3y ago
I think your initial sentence summarizes .Net well. I'm not a .Net developer and never have been. But I used to do a lot of technical due diligence work. Which sometimes means sitting down and going through the most critical code, and sometimes nearly all of the code in a project. When you do this kind of work you encounter lots of different languages and software cultures. One thing I notice about .Net in particular is that it is often the choice of companies that have a weak software development culture. My guess is that people choose .Net in these companies because they already have a "relationship" with MSFT products. MSFT is what management knows and trusts. Often because they're not qualified to make technical decisions and they think MSFT is somehow a safe choice. This is also why they tend to choose Azure. It isn't so much a conscious choice based on the merits of the technology. They almost never tried AWS or GCP first, and there is very often some financial incentive to choose Azure (eg licensing package deals). The .Net projects I've reviewed are often often mediocre software engineering. In particular during M&A, you encounter a lot of code bases that use old .Net versions, old libraries and critical code that hasn't been touched for years. Presumably because the companies that tend to choose .Net often do not invest in the codebase once it is "done". It also isn't unusual that much of the code is written by junior consultants. This is my experience and it is what it is. It isn't so much about technology as it is about certain types of companies. But it does result in me having certain prejudices when I hear that something is written in .Net. It is easy to expect bad things when people say "we use .Net".
- no_wizard 3y ago
  I’m curious to know what you see at Java and Kotlin shops for comparison. My experience is the same, but instead of .NET replace it with Java and Spring, it’s otherwise essentially the same
  - bborud 3y ago
    I haven't reviewed any Kotlin codebases. My guess is that if people choose Kotlin then at least they had some opinions on languages, so I'd expect more. But as I said, that's just a guess. On average Java codebases I have reviewed tended to be slightly better than the C# codebases. The C# codebases I've seen have tended to be more "garden variety meh" while Java tend to be either south or north of "meh" - if that makes any sense. They're more often either terrible or fairly nice. Though I've been lucky and seen more nice than awful Java. (There is a separate circle of hell for Spring and other metastasizing frameworks). That being said, the all-time worst codebase I have reviewed was in Java. An EMV system written in a hurry with almost zero error handling.
josephg 3y ago
> It also has some great tech that doesn't exist elsewhere, like Blazor which allows you to build entire websites (backend and frontend) with C# I won’t comment on whether blazor is a good framework for frontend web dev. But it’s far from unique. These days there’s heaps of languages you can use for both front- and backend web programming. JavaScript and typescript, obviously. Dart. And Go and Kotlin have some blazor-like wasm builds (though they still have a large download size). Lately I’ve been noodling with web dev in rust with Dioxus. It’s crazy fast - it trades blows with the best JS frameworks. And it’s very ergonomic. It’s basically solidjs rewritten in rust. The resulting wasm bundle is bigger than the equivalent JavaScript code, but it’s really not too bad given wasm parses several times faster than JavaScript. Blazor looks nice. And wasmgc should dramatically reduce the resulting wasm bundle size soon. But it’s far from unique. You can make webpages in almost any language now.
- josephg 3y ago
  Sorry - correction, I was talking about Leptos: https://book.leptos.dev/view/01_basic_component.html https://book.leptos.dev/view/01_basic_component.html

by mythz 3y ago

JackMorgan 3y ago

Frankly, having lived and upgraded many projects through asp web forms, wpf, silverlight, and razor, I've decided "never trust .NET UI libraries to survive". So I'm avoiding Blazor entirely and just sticking with the react ecosystem. I trust that 100x more than I trust Blazor, partly because the ecosystem and user base is 100x larger. I won't be the slightest bit surprised to see Blazor tossed in the trash in three years, but I'll eat my hat if react is gone by then. Sure, maybe it's popularity will wane for some other similar library, in which case I'll switch to that. But I'm sticking with the beaten path on the front end.

cjk2 3y ago
Ha we still have all of those (apart from Silverlight) in production. A number of years ago I had to get an overexcited architect to not rewrite everything in Silverlight. Front end .Net is a shit show. You are right to stay the hell away from it.
mythz 3y ago
You've got good reasons for not trusting any .NET GUI libraries from Microsoft, I don't either since they all ultimately end up abandoned however that doesn't definitely doesn't apply to their premier Server frameworks which enjoys first class long lasting support. Razor didn't go anywhere, it's still the predominant language .NET Server HTML Views is written in since its release in 2010, whether it's in MVC, Razor Pages or even Blazor which enjoys the same familiar statically-typed syntax with great tooling and high performance compiled views. There's no chance that's going to happen with Blazor, which has become the future of .NET Web App development, it's a unique technology that's highly versatile whose multiple rendering options supports a wide number of different use-cases that's enjoyed by most of .NET developers. Personally I think it's a fresh of breath air after several years of fragile npm SPA development with broken upgrades stemming from its 100s of deps of varying quality and uncoordinated releases. All I liked from SPAs is its fast navigation, but we also get that from Blazor's Enhanced navigation without SPA complexity, heavy client state, maintaining client side routing, poor SEO, large complex builds, etc.
- JackMorgan 3y ago
  It's a bold claim to say that the team that produced a half dozen failures in a row has "no chance" of producing another failure. I will set a calendar reminder for five years "is Blazor still around" and I'm pretty confident the result will be "well yes but it's terrible for these reasons, but this new library Tazor is the future of .NET web UI and it's not going anywhere!"
  - mythz 3y ago
    That's not all from the same team, Microsoft is a 2T company with software in every industry. Their GUI suffered through lack of investment and neglect. Their Web Server frameworks are producing software running on their cloud, Windows servers and infrastructure products like SQL Server, all enjoying multi-billion dollar businesses. Extrapolating abandonment of Windows GUI software with poor business models, with cross-platform libraries running on growing revenue centers is foley, I'll happily take any "5 year Blazor" bet.

bborud 3y ago

I think your initial sentence summarizes .Net well. I'm not a .Net developer and never have been. But I used to do a lot of technical due diligence work. Which sometimes means sitting down and going through the most critical code, and sometimes nearly all of the code in a project. When you do this kind of work you encounter lots of different languages and software cultures. One thing I notice about .Net in particular is that it is often the choice of companies that have a weak software development culture. My guess is that people choose .Net in these companies because they already have a "relationship" with MSFT products. MSFT is what management knows and trusts. Often because they're not qualified to make technical decisions and they think MSFT is somehow a safe choice. This is also why they tend to choose Azure. It isn't so much a conscious choice based on the merits of the technology. They almost never tried AWS or GCP first, and there is very often some financial incentive to choose Azure (eg licensing package deals). The .Net projects I've reviewed are often often mediocre software engineering. In particular during M&A, you encounter a lot of code bases that use old .Net versions, old libraries and critical code that hasn't been touched for years. Presumably because the companies that tend to choose .Net often do not invest in the codebase once it is "done". It also isn't unusual that much of the code is written by junior consultants. This is my experience and it is what it is. It isn't so much about technology as it is about certain types of companies. But it does result in me having certain prejudices when I hear that something is written in .Net. It is easy to expect bad things when people say "we use .Net".

no_wizard 3y ago
I’m curious to know what you see at Java and Kotlin shops for comparison. My experience is the same, but instead of .NET replace it with Java and Spring, it’s otherwise essentially the same
- bborud 3y ago
  I haven't reviewed any Kotlin codebases. My guess is that if people choose Kotlin then at least they had some opinions on languages, so I'd expect more. But as I said, that's just a guess. On average Java codebases I have reviewed tended to be slightly better than the C# codebases. The C# codebases I've seen have tended to be more "garden variety meh" while Java tend to be either south or north of "meh" - if that makes any sense. They're more often either terrible or fairly nice. Though I've been lucky and seen more nice than awful Java. (There is a separate circle of hell for Spring and other metastasizing frameworks). That being said, the all-time worst codebase I have reviewed was in Java. An EMV system written in a hurry with almost zero error handling.

josephg 3y ago

> It also has some great tech that doesn't exist elsewhere, like Blazor which allows you to build entire websites (backend and frontend) with C# I won’t comment on whether blazor is a good framework for frontend web dev. But it’s far from unique. These days there’s heaps of languages you can use for both front- and backend web programming. JavaScript and typescript, obviously. Dart. And Go and Kotlin have some blazor-like wasm builds (though they still have a large download size). Lately I’ve been noodling with web dev in rust with Dioxus. It’s crazy fast - it trades blows with the best JS frameworks. And it’s very ergonomic. It’s basically solidjs rewritten in rust. The resulting wasm bundle is bigger than the equivalent JavaScript code, but it’s really not too bad given wasm parses several times faster than JavaScript. Blazor looks nice. And wasmgc should dramatically reduce the resulting wasm bundle size soon. But it’s far from unique. You can make webpages in almost any language now.

josephg 3y ago
Sorry - correction, I was talking about Leptos: https://book.leptos.dev/view/01_basic_component.html https://book.leptos.dev/view/01_basic_component.html