5 ms·
Now do the same using Blazor Server (C#). For convenience use https://www.fluentui-blazor.net/ https://www.fluentui-blazor.net/ or https://mudblazor.com/ https:
by webprofusion 2y ago
Now do the same using Blazor Server (C#). For convenience use https://www.fluentui-blazor.net/ https://www.fluentui-blazor.net/ or https://mudblazor.com/ https://mudblazor.com/ for your UI components.
It has it's compromises but it's great for just building stuff, with UI updates streamed to the client, no JS (or as much as you want), no extra API building just for the sake of your SPA. Note that I'm not talking about Blazor WASM.
If you're interested in working as a developer for corporations outside of the SF bubble (e.g. the other 80% that use Windows instead of macOS) it's worth checking out, especially for internal corporate stuff.
- thanksgiving 2y agoI am not convinced. I have tried using blazor and it has been painful at best. I know of at least one internal tool at Microsoft (Azure) still using razor pages. I don't know how much I am allowed to talk about this but most teams as far as I can tell at Microsoft use react. You should too. This is not a fight worth fighting. For internal applications, stay with asp net razor pages. It doesn't need anything fancy. Don't run after a fad that even teams within Microsoft refuse to chase.
- devjab 2y agoWe use GO (with templates) and HTMX for internal apps in enterprise which is completely tied in Microsoft. It’s a much better experience than Blazor. I think that any productive language (think what you would likely have used Python for) with templates that can be mixed with HTMX is easily the best experience you’re going to have writing internal enterprise applications. We use GO because we’re slowly replacing our C# and TS backends with GO, but you can achieve the same with many techs. Probably even C# and (ironically) web forms. It obviously has some limitations, and if you need complicated role based access control you’re going to want to use something else. But for 95% of your use cases it’s soooo easy to build an app with JS with server side functionality with HTMX and templates. The major disadvantage is that it introduces multiple frontend techs as you do not want to use it on anything facing customers / investors / whatever on the internet.
- tinco 2y agoAs someone who hasn't written C# regularly for over a decade, but has done Go every now and then recently, why would you replace C# with Go? It sounds like it would be a step down in maintainability with not much advantage.
- neonsunset 2y agoYou are about to hear a long tirade how OData is terrible (has little to do with .NET) or some arbitrary reason from this particular HN account. In practice, it’s often management decision and has little value as .NET usually has better tooling like gRPC one.
- devjab 2y agoYou should get a healthier hobby than stalking me.
- ledgerdev 2y agoLong term c# dev, who's used golang on a few projects. I really want to love go with an htmx+templ, amazing speed and gc, but find it sort of weird/quirky and just plain tedious in use. Linq in c# is so nice, and lots of little c# features(maybe too many) in recent years has made it quite nice for daily use. With aot definitely prefer c# the language over golang. I do sort of loathe aspnet/mvc and especially blazor stuff. We desperately need a better web framework than asp but nothing will ever gain enough traction because of the ms dominance. Microsoft the sprawling corp never fails to disappoint, but damn the .net framework team does do some awesome work. That said, I'm instead putting future efforts into python because let's be honest, uv/fastapi/fasthtml are more than fast enough for nearly every single project I've ever worked on.
- devjab 2y agoWe work with solar data, which involves a myriad of data formats and delivery systems. This is mainly because solar inverter engineers didn’t think anyone would put solar inverters directly on the internet. It even said so with big red block letters in one of their manuals. Anyway, basically the entire industry decided to never read the manuals and just put the inverters directly on the internet. Which means we’ve collected data with various services. Especially because it used to be done by different parts of the business, which means some of it is in power apps, some of it is in Python some of it is in C#, some is in Typescript and some is in C. We want to lessen that and GO fits our purpose better than C# because of how async/await has been inherently flawed from its creation. A big part of this is developer based, because of how it was designed it’s just very easy to fuck it up. It’s very leaky and you need to propagate everything, it’s very easy to create deadlocks and you can’t cancel tasks in any meaningful way. On the technical side it’s just terrible for our use case, we’ve cut our Azure cost immensely with go-routines compared to C#. The biggest cost saving has obviously been with power apps, followed by Python but because of the amount of data we handle C# is also very expensive. On the philosophical side of things. We prefer things like explicit error handling and not having to create a class to have a function. So a lot of it isn’t technical, and some of it is.
- rco8786 2y ago> the other 80% that use Windows instead of macOS https://www.statista.com/statistics/869211/worldwide-software-development-operating-system/ https://www.statista.com/statistics/869211/worldwide-softwar... Even amongst those numbers, .NET itself is a pretty small fraction of the overall dev community. I'm not sure why you're posturing as though it's some huge majority.