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

131–140 of 302 posts

Re: .NET Blazor

#131

Post by mbesto »

LaGrange wrote: post #118
kumarvvr wrote: post #113

All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem. With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc. But, as a developer who…

> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. The disadvantages: the _actual user_ is going to have a horrible time with the application. It will load slowly, work slowly, probably break the moment you inevitably will have to touch JS, and if the browser the user hates anyway is out of sync with the forced updates, the entire thing will blow up. But enterprise LOB…

Serious question - do you know this to be in fact true of Blazor specifically, with real life comparisons, or is this just conjecture based on analogous frameworks?

Re: .NET Blazor

#132

Post by ptrwis »

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…

In my experience, long polling is more stable and you can enable transfer compression. Maybe it would be good in Blazor to disable the persistent connection completely, having only requests and responses. Often we just want to call a backend method and update the view in response.

Re: .NET Blazor

#133

Post by Capricorn2481 »

brtkdotse wrote: post #129
LaGrange wrote: post #118

Earlier quoted context omitted.

> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. The disadvantages: the _actual user_ is going to have a horrible time with the application. It will load slowly, work slowly, probably break the moment you inevitably will have to touch JS, and if the browser the user hates anyway is out of sync with the forced updates, the entire thing will blow up. But enterprise LOB…

> It will load slowly, work slowly Why do you think this will be the case?

Well for Blazor Webassembly at least, you need to download the entire .NET runtime and WebAssembly isn't quite as fast as JS in browsers yet.

Couple that with the fact that interoping with JS can be a lot more annoying than just using JS

Re: .NET Blazor

#134

Post by codegeek »

kumarvvr wrote: post #113

All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem. With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc. But, as a developer who…

For me, just the fact that I don't have to deal with JS bullshit and ecosystem including node/npm hellhole is a win for me. Before these shiny JS frameworks came along, .NET already had great UI component libraries as well including syncfusion (my favorite) and many others.

I only do VueJS when I do use JS but man I can't wait to not write any code in JS.

Re: .NET Blazor

#135

Post by codegeek »

louthy wrote: post #115
kumarvvr wrote: post #113

All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem. With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc. But, as a developer who…

It's still relevant when MS decide to drop it and focus on yet another new shiny web-framework, like the 10 - or whatever number previous they've built - in the past 20 years. And, let's face it, they're not very good at it. If they were they wouldn't need to shelve so many previous attempts. Or, they decide to completely upend the entire ecosystem (Framework → Core) which then makes all previous web-frameworks (buil…

" yet another new shiny web-framework"

Funny you say that. JS..cough..JS.

Re: .NET Blazor

#136

Post by brtkdotse »

Capricorn2481 wrote: post #133
brtkdotse wrote: post #129

Earlier quoted context omitted.

> It will load slowly, work slowly Why do you think this will be the case?

Well for Blazor Webassembly at least, you need to download the entire .NET runtime and WebAssembly isn't quite as fast as JS in browsers yet. Couple that with the fact that interoping with JS can be a lot more annoying than just using JS

> Well for Blazor Webassembly at least, you need to download the entire .NET runtime

It's a one-time download that's smaller than the initial load of the Facebook feed

Re: .NET Blazor

#137

Post by sebazzz »

pacifika wrote: post #102
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…

Picking up full stack is a long way from innovating in it.

Innovation in the technology is not something every company has to do.

Re: .NET Blazor

#138

Post by isbvhodnvemrwvn »

bsuvc wrote: post #125

Here is my personal experience. I've been working on a large-ish Blazor (Server) application for about a year. The choice to use Blazor was not mine, but I went into it with an open mind. For context, I have used React and Angular in the past. I will never used Blazor again. Performance is not good, with CPU always at some base level, even when idle. My machines fan is always cranking while developing it. Hot reload…

Sounds a bit like Adobe Flex.

Re: .NET Blazor

#139

Post by TheRealDunkirk »

This feels like a move to be more like Rails, and I'm there for it. The problem with Microsoft is that, every time I think, hey, this new thing might be useful for such-and-such kind of app or problem, by the time I get around to trying to use it, they've moved on to something else.

Re: .NET Blazor

#140

Post by osigurdson »

kumarvvr wrote: post #113

All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem. With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc. But, as a developer who…

The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?
Post reply on HN