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

81–90 of 302 posts

Re: .NET Blazor

#81

Post by brainwipe »

Trying to program the web front end like you do the API backend feels like an antipattern. I'm all for productivity but you eventually hit issues that cannot be resolved because the client/serverness of your solution has been abstracted away from you. Those of us with WebForms scars remember those days.

Like the article suggests right at the end, I want a C#-compile-to-wasm with new language structures for common web browser features such as shadow DOM. Perhaps also without the .NET core lump unless you really need it - and even then importing only the dependencies you need. I almost love Typescript but only because I spend my life wishing it was really C#.

Blazor looks cool but it's not quite native enough to client/server. I've been burnt by Silverlight and have a lots of ReactJS at work so the benefit isn't quite worth the cost and risk. I wonder if in a future role I might be tasked with a greenfield app for which it's a brilliant fit but I can't see that in any of the SME roles I've had so far.

Re: .NET Blazor

#82

Post by jve »

BurnGpuBurn wrote: post #58
jsiepkes wrote: post #46

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.

Sorry for not being up-to-date. I can't read anything about discontinuing Xamarin on wiki: https://en.wikipedia.org/wiki/Xamarin

Ok, MS says this: https://dotnet.microsoft.com/en-us/platform/support/policy/x...

> Xamarin.Android, Xamarin.iOS, Xamarin.Mac are now integrated directly into .NET (starting with .NET 6) as Android, iOS, and Mac for .NET. If you're building with these project types today, they should be upgraded to .NET SDK-style projects for continued support.

> Xamarin.Forms has evolved into .NET Multi-platform App UI (MAUI) and existing Xamarin.Forms projects should be migrated to .NET MAUI.

So to those of you using Xamarin: how painful it is? How compatible Xamarin.Forms or not is with .NET MAUI? Are they totally different tech?

How easy/hard it is to go from Xamarin.{Android,iOS,Mac} to .NET6+ ?

Re: .NET Blazor

#83

Post by jddj »

mythz wrote: post #40

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

Very interesting, and the first time I might have been nearly sold on it. Maybe next new project I'll try it out.

Razor pages with JavaScript on the front end and automatic diffing on the backend is definitely appealing. As much as I don't like the idea in general of serverside session state.

By the way, I think if you used a light-dom framework like alpine or petite-vue you would avoid most of the issues with the page not recalculating the front-end state on navigation.

Re: .NET Blazor

#84

Post by rbanffy »

I believe there is a simple lesson to be learned from all ambitious frameworks of the past that now lie in ruins covered in sand.

It's wise to decouple the front and back-ends. Run away from tools that pretend you can do everything within one single framework. Run away from tools that make it more complicated to decouple both. Manage front and back separately. Develop them separately. If it takes a full article to explain a technology, it's probably too complicated.

Re: .NET Blazor

#85

Post by oaiey »

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…

I share your perspective. It is the most productive environment I have seen in many years. Blazor WASM for internal company applications, PWA or Blazor Hybrid (basically Cordova/Electron Shell just with C#) is just awesome.

I share the article's fear of overloading the technology, but do not see it overall that negative.

Re: .NET Blazor

#86

Post by sebastianz »

blackoil wrote: post #61
marcos100 wrote: post #57

Earlier quoted context omitted.

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.

> Is 5MB a real problems?

Well if you want to make small fast loading html pages with a minimal js library, and end up at a few hundred KB that you can understand, profile and optimize, then that is impossible with blazor. So it's a very real problem.

If you want 5mb blobs and do not care about what is going on inside, how to optimize or reduce the memory and bandwidth usage, then it's not a problem, works just as well as the websites you have seen, with 200 node dependencies.

Re: .NET Blazor

#87

Post by diarrhea »

sebastianbk wrote: post #62
marcos100 wrote: post #57

Earlier quoted context omitted.

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…

Sounds like you did everything right then. Started off simple, now your business is taking off, failures aren't catastrophic (they're grey, not black, from what it sounds like) and splitting out a component shouldn't be too hard, so you'll be ready for more scale soon. All while maintaining the business!

Re: .NET Blazor

#88

Post by mythz »

jddj wrote: post #83
mythz wrote: post #40

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

Very interesting, and the first time I might have been nearly sold on it. Maybe next new project I'll try it out. Razor pages with JavaScript on the front end and automatic diffing on the backend is definitely appealing. As much as I don't like the idea in general of serverside session state. By the way, I think if you used a light-dom framework like alpine or petite-vue you would avoid most of the issues with the pa…

> By the way, I think if you used a light-dom framework like alpine or petite-vue you would avoid most of the issues with the page not recalculating the front-end state on navigation.

Unfortunately it's how Blazor Enhanced Navigation works where it compares the rendered content of the new page and diffs in the changes so I'm not expecting it to work by default (i.e. without adopting a workaround) with any JS FX that dynamically generates the UI as it'll get replaced back into an empty div when Blazor patches in the new page elements.

Also I wouldn't recommend "lite-dom" FX's like PetiteVue which has basically been unmaintained since 2021, has poor composition/component model and pretty glaring bugs/limitations you're likely to hit very quickly for any complex UI. We ended up having to rewrite all our Built-in UIs [1] with Vue 3 [2] to overcome its limitations. The 40kb increase in minified/compressed .js size vs vue.min.js is not worth the pain of working within its limitations.

[1] https://servicestack.net/auto-ui

[2] https://docs.servicestack.net/releases/v6_07#new-locode-api-...

Re: .NET Blazor

#89

Post by oaiey »

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 have to disagree. What you describe is every legacy stack and 20 years evolvement. Java with how many EE systems. JS with how many SPA frameworks. Python I know too little. Go/Rust are too young to have history.

Re: .NET Blazor

#90

Post by tcfhgj »

_s_a_m_ wrote: post #29

Strange discussion here. I'm a developer in everything for 20 years and the last 7 probably in large JS/TS applications. I switched to Blazor Server for the last year in a new company and it has a montrous amount of benefits. First of all, do not pretend that you are Google or Facebook. This is a repeated mental illness that developers suffer from. No won't face any performance issues. The contrary, Blazor is blazing…

It's fast if you have fast internet and CPUs.

I like the Leptos approach more. Smaller binaries,lessoverhead, website already works completely during loading WASM and turns on client side rendering once it is loaded.

Post reply on HN