Live data from Hacker News

.NET Blazor

dusted.codes

61–70 of 302 posts

Re: .NET Blazor

#61

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 a backend dev, I love the technology. The problem is that you have to choose between a not-so-scalable solution (Server, signalR) or a minimum 2mb initial payload (WASM) that can easily go to 5mb. Interested on how many concurrent users you have for Server to be a problem. Can you elaborate more on your performance issues?

Is 5MB a real problems? Theoretically it may look big, but I have seen many websites much bigger, not to mention all video/image we download are already skewing download by a lot. Considering runtime is cached for long time, I don't see a real blocker. First page render would be an issue but SSR solves that.

Re: .NET Blazor

#62

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 a backend dev, I love the technology. The problem is that you have to choose between a not-so-scalable solution (Server, signalR) or a minimum 2mb initial payload (WASM) that can easily go to 5mb. Interested on how many concurrent users you have for Server to be a problem. Can you elaborate more on your performance issues?

I may have made a mistake in designing the architecture of our app. Since we're a small team, I opted for a big ol' monolith, hosting our APIs on the same server as our Blazor Server app. We normally serve a few hundreds requests per second on our APIs, which is totally fine. However, sometimes we got some spikes up to thousands of requests per second, which has the unfortunate consequence that our Blazor Server app becomes laggy and starts to drop WebSocket connections frequently. So, now, we are in the process of moving our API controllers to another project, which will be hosted on a separate server.

Re: .NET Blazor

#63

Earlier quoted context omitted.

> there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight. That's not really fair to MS since all the web frameworks which were born in that era (Adobe's AIR, JavaFX as a web tech, etc.) died because IE died. And also because Apple killed off browser plugins since they didn't work on the iPhone. Chrome and Firefox took over and there was no longer a need to use browser plugins for SPA…

Don't forget all the other products Microsoft managed to screw over developers with. Like discontinuing Xamarin.

[dead]

Re: .NET Blazor

#64
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…

> there's been a hesitance to jump on MS web frameworks in fear of a repeat of silverlight. That's not really fair to MS since all the web frameworks which were born in that era (Adobe's AIR, JavaFX as a web tech, etc.) died because IE died. And also because Apple killed off browser plugins since they didn't work on the iPhone. Chrome and Firefox took over and there was no longer a need to use browser plugins for SPA…

You can say that, but at the same time, whenever people complain about technology changing, leaving them behind, they usually mean tech by Microsoft.

The reason Java and JavaFX survived is that they went Open Source, with a large FOSS ecosystem, targetting FOSS operating systems as well, all while there still was interest. And their maintenance and evolution continued. Adobe RIA and Flash were proprietary platforms, just like Silverlight.

In fairness, projects that survive tend to be FOSS, and AFAIK, .NET Blazor is open source. OTOH, the .NET ecosystem tends to prefer Microsoft's solutions, with alternatives languishing, they basically killed Xamarin's projects, and they have had several noteworthy conflicts with the FOSS community. So the jury is still out on whether Microsoft's projects can escape the deprecation curse.

---

The lesson here, for all, if you want for your knowledge and work to stay relevant, look towards Open-Source platforms and open standards. If seeking stability, the older, the better, actually. FOSS platforms age like fine wine.

Re: .NET Blazor

#65

Earlier quoted context omitted.

People don't realize this. Blazor is about the developer. I am a `DevOps/Backend` guy and in my previous job some internal tools were made with Blazor. It was such a joy to work with. Productivity was so high. You add Blazor Radzen components[1] or Syncfusion[2] and suddenly feels like magic. Super complex grid tables can filter, re-order columns, aggregate them and much more functionality for free in 10 lines or few…

It's funny you're being downvoted, I've used Blazor on less important side projects and I love it for the same reasons, but a subset of HN hates it because their uBlock Origin no-Js anti-tracker cookieless oddball browsers choke on it. Interestingly enough Google's crawlers don't even choke on it: my fully SignalR based site was indexed soon after getting a spike in traffic without an issue. Does it annoy me that lea…

No, people hate it because it's a massive downgrade in UX, especially the wasm variant, just because backend devs don't want to use the right tools for the job. I'm fine with it in internal apps, but public facing apps using blazor would be horrible for the users, which is why it is thankfully very rare to see.

Javascript seems downright lightweight and unbloated compared to shipping an entire dot net runtime for a crud form app. For what it's worth, I don't care about turning off javaScript or even bloat in general, but this is extreme.

Re: .NET Blazor

#66
post #47

Earlier quoted context omitted.

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

Sorry, but you seem to be missing the context here — this is an environment where these kind of decisions are not made by the developers, but are in the hands of other departments. So the choice of antivirus or other corpoware or disabling the antivirus is not something that the development team has any say in.

I hassled my IT guys to get rid of Symantec Endpoint Protection on my PC and leave me with Defender. You can too.

Re: .NET Blazor

#67

Anyone tried Blazor in production? I checked it out (BRIEFLY) back when it was released, and it looked pretty cool - but there was really not a whole lot of info back then. It's been 4-5 years now, so I'm curious if anyone has actually integrated it into prod

I knocked up a quick prototype for a friend about 4 years ago (client side blazor wasm .net core 3.0) and he turned it into a successful small business. About 15 simple screens communicating with restful services all in one solution. He found some cheap developers to hack on it for some extra screens but he eventually unpicked their work. The amazing thing is the system is so simple that he, a someone new to programm…

> But dammit, at least leave the old SDK’s up for a decade for this very reason!

You can get .NET Framework 4.8 from the Visual Studio installer, no problem. It's not even marked as deprecated. If you know where to look, all the other versions are available, too.

Re: .NET Blazor

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

Yes, how dumb of me to not make a completely weird request to interview the corporate IT department of my job after I had been laid off for two months and was struggling to find anything in my area.

Re: .NET Blazor

#69
post #47

Earlier quoted context omitted.

Sorry, but you seem to be missing the context here — this is an environment where these kind of decisions are not made by the developers, but are in the hands of other departments. So the choice of antivirus or other corpoware or disabling the antivirus is not something that the development team has any say in.

I hassled my IT guys to get rid of Symantec Endpoint Protection on my PC and leave me with Defender. You can too.

Trust me, there are environments in which you can't. Keywords: "DoD" and "consulting".

Re: .NET Blazor

#70

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 a backend dev, I love the technology. The problem is that you have to choose between a not-so-scalable solution (Server, signalR) or a minimum 2mb initial payload (WASM) that can easily go to 5mb. Interested on how many concurrent users you have for Server to be a problem. Can you elaborate more on your performance issues?

.NET 8 solves that exact problem as far as I can see. You can opt into auto mode and it uses server side Blazor until the client downloads all assets, then in subsequent visits it uses the WASM runtime. Seems to be a good compromise.
Post reply on HN