Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Blazor

dusted.codes

Post reply on HN
Print view View original

31–40 of 302 posts

Re: .NET Blazor

#31

Post by bragh »

The whole discussion around why a .NET shop might choose Blazor over Javascript ecosystem misses these critical things when it comes to developer experience:

1. Antivirus scans — it will take a lot more time for an antivirus to scan the tens of thousands of files in node_modules than whatever dotnet is doing. Especially on Windows

2. Corporate proxy support — the story of proxy support and importing custom certificates for the MITM proxy is still pretty much horrible (although improved since middle-2010s) in the Javascript ecosystem. dotnet is not perfect here and still has some warts in some specific tools, but much much better.

Re: .NET Blazor

#32

Post by xupybd »

sebastianbk wrote: post #27

In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time. So, when I started my own company last year, I quickly jumped on Blazor Server, which has been an absolute joy from a dev…

As someone in New Zealand that's crazy. The ping to Europe is terrible. To the point that video calls to the UK are painful.

Re: .NET Blazor

#33

Post by ChicagoDave »

I honestly thought some version of WASM would be popular, performant, and easy to use by now, and not reliant on js/html/css.

Like desktop app development in a browser or an actual good version of Silverlight.

Re: .NET Blazor

#34

Post by ktsangop »

Nice article, very well researched.

Since other web frameworks struggle with performance optimizations for a decade (see Angular, React), Blazor seems like something you wouldn't pick unless you didn't care much about performance (mostly network traffic I suppose)

But for teams that already have invested in .NET and need to migrate desktop apps to the cloud, this seems pretty reasonable. There are millions of boring corporate apps that need something like that, and most of us work on those boring companies, rather than "on the edge" of tech...

Also it's much harder to reverese engineer WASM than de-obfuscate JS so maybe there's another use case for Blazor (and WASM in general)..?

Re: .NET Blazor

#35

Post by ttymck »

smokel wrote: post #2

A lot of people seem to think that front-end and back-end developers are intrinsically different people. This would be the reason why full-stack frameworks (Kotlin for JavaScript, Scala.js, JavaScript backends, and now Blazor) never really take off. I find this rather strange. I can understand that people specialize, but it's not like typical application front-end or back-ends are rocket science and require a PhD or…

Because I can learn javascript, and work at myriad companies using any backend language. Or I can learn Blazor and work at the half dozen firms deploying it to production (maybe there are more in Europe).

Re: .NET Blazor

#36

Post by xupybd »

xnorswap wrote: post #3

Despite working with .Net for decades, I've not jumped to blazor. The reasons are varied, many of which are well articulated in the article, but the most notable throughout various workplaces I've worked at, there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight. Silverlight burned a lot of small businesses hard, almost everywhere I've worked has had a silverlight horror story of a p…

I was helping to maintain an Adobe Flex system a few years back. It really sucks when your framework is simply obsolete like that. I don't know how to protect against that with the rate of change.

Re: .NET Blazor

#37

Post by BitterAmethyst »

At a previous job we adopted Blazor WASM in order to rewrite an interal React-based app that was basically a hardware test ticketing system + asset tracker. It was very productive, ended up feeling more responsive to users (after the initial page load which was definitely worse) and allowed us to share some code from the WPF app it integrated with. Adding more complex features was much easier than it would have been with React (the years of C# experience on the team was much higher than the JS/TS experience).

I think like most MS products it suffered from being not quite ready for production when they claimed. We started using it in dotnet 6 and there were a lot of features that I ended up implementing or rough edges I worked around myself that were subsequently included / fixed in the dotnet 7 version.

I am hopeful that WASM GC + dotnet linking & trimming + the auto thing mentioned in the article will make it an acceptable choice for public-facing websites as currently I'm not sure how well I could justify it despite my personal feelings on JS vs C#.

I am eager to try Fable at some point though, probably on a personal project first.

Re: .NET Blazor

#38

Post by taspeotis »

bragh wrote: post #31

The whole discussion around why a .NET shop might choose Blazor over Javascript ecosystem misses these critical things when it comes to developer experience: 1. Antivirus scans — it will take a lot more time for an antivirus to scan the tens of thousands of files in node_modules than whatever dotnet is doing. Especially on Windows 2. Corporate proxy support — the story of proxy support and importing custom certificat…

Windows Defender handles node_modules fine, and if you're dumb enough to choose something other than Windows Defender on ... Windows ... that's on you.

If you really want you can cut Defender out of the picture too: https://learn.microsoft.com/en-us/windows/dev-drive/#underst...

Re: .NET Blazor

#39

Post by ttymck »

siquick wrote: post #7
huytersd wrote: post #4

Earlier quoted context omitted.

Yeah and then why don’t devs learn to administer their own databases as well. While they’re at it, writing some QA test cases can’t be all that hard. Continuous integration is pretty straightforward to set up so that as well. To be fair, it’s rather formulaic to come up with UI designs as well. Also security, load balancing and requirement docs just take a little dabbling to learn.

There are many of us working at smaller companies who do all of the above.

And are you hiring? Does your situation represent the bulk of available opportunities for developers looking for work? I think it's not, which is why these frameworks don't gain traction relative to javascript, which is portable to any backend stack.

Re: .NET Blazor

#40

Post by mythz »

I take the opposite view, as a recent Blazor convert since the just released .NET 8 we're now recommending Blazor for any new .NET Web App (excl. CDN Hostable, SSG websites).

I was short on Blazor before .NET 8 and could only seriously recommend it for Internal Apps since the compromises for using either of Blazor's Server or WASM Interactivity delivered a poor UX for Intranet hosted Apps as covered by this post.

However that's changed in .NET 8 Blazor's default Static Rendering where you're effectively able to develop traditional Server Rendered Apps like Razor Pages/MVC but with Blazor's superior component model, advanced features like Streaming Rendering and its built-in (smart) Enhanced Navigation which gives simple Server Rendered App's SPA-like responsiveness without any of npm's build tool complexity, need to manage separate client routing, heavy client state, npm dependencies, large JS bundles, etc.

Even better is that you no longer need to use Blazor Interactivity for any Web App features, e.g. which we avoid in our "Blazor Vue" (100% SSR) Tailwind template that progressively enhances statically rendered Blazor content with Vue.js. I cover this approach in detail in our ".NET 8's Best Blazor" [1] blog post.

As it embraces the simplicity of "No Build" JavaScript Modules (i.e. avoiding npm deps + build tools) it's now become my preferred approach for most .NET Web Apps.

Blazor Diffusion [2] is an example App built using this template, originally developed in Blazor Server, deployed as WASM but now converted to "Blazor SSR + Vue", source code available at [3].

[1] https://servicestack.net/posts/net8-best-blazor

[2] https://blazordiffusion.com

[3] https://github.com/NetCoreApps/BlazorDiffusionVue

Post reply on HN