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

141–150 of 302 posts

Re: .NET Blazor

#141

Post by neonsunset »

devjab wrote: post #99
KronisLV wrote: post #75

Earlier quoted context omitted.

> 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. Oh, hey, I have something relevant to say about this setup. Currently I'm bootstrapping a platform with .NET Core on th…

I spent a decade with C# and .Net and even in its current form which is easily the best it’s ever been I vastly prefer to work with Typescript. Yes, you do need to set up some rather strong governance around it for it to work for multiple teams, but you should really be doing that with any technology, and once you do, it’s just excellent. Part of the reason for this is that it’s basically designed from the ground up…

Previously from this account: https://news.ycombinator.com/item?id=38228674

The tldr of both the previous and this posts is OData being bad yet the author extends his grievances regarding it to the entirety of ecosystem.

Re: .NET Blazor

#142

Post by codegeek »

louthy wrote: post #124
michaelteter wrote: post #123

Earlier quoted context omitted.

Have you been to JavaScript land in a while?

Sure, do you have a point you'd like to make?

The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't build. The errors want you to go take a cryptography course to understand WTF is happening.

And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer.

And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? Webpack, Vite, blah blah.

Re: .NET Blazor

#143

Post by bsuvc »

andsoitis wrote: post #130
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…

> a proper front end framework Do you think a WASM approach has merit or do you think it is doomed?

Not sure. We haven't used the WASM version, but it is possible that it works better.

I still think there is a rug-pull risk by Microsoft, so not sure I would choose it for that reason alone.

Re: .NET Blazor

#144

Post by sebazzz »

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…

We've created the need front-end and back-end developer distinction by creating overly complex front-end build systems, and overly complex SPA frameworks.

Re: .NET Blazor

#145

Post by pier25 »

osigurdson wrote: post #140
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?

React will die too, eventually. Or at least stop becoming the default.

Re: .NET Blazor

#146

Post by francisofascii »

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.

On a phone, 5MB it not ideal. On a corporate desktop, not an issue.

Re: .NET Blazor

#147

Post by no_wizard »

louthy wrote: post #120
kumarvvr wrote: post #117

Earlier quoted context omitted.

When it comes to web, MS has been focused on ASP.NET since forever. With evolution of the web, ASP.NET too has evolved quite a bit. Building a simple web app with Razor pages is incredibly easy and the output is fast and scalable. Their WebAPI in ASP.NET is very good. Blazor is an additional way to do web apps, but very much in line with the structure and core of ASP.NET. In the desktop world, MS has jumped a lot of…

> When it comes to web, MS has been focused on ASP.NET since forever. What's your definition of 'forever'? Are you talking about ASP, or ASP.NET, or ASP.NET Core? Or, Web Forms, MVC1, MVC2, MVC3, Silverlight, 'minimal APIs'? ... Honestly, it's just one clusterfuck after another. --- EDIT: There's a number of sub-comments here that seem to be missing the point. So, I'll expand here: * For those who are questioning my…

Don’t forget Web API 2! And their other API recommendations (OData anyone?)

Re: .NET Blazor

#148

Post by Capricorn2481 »

brtkdotse wrote: post #136
Capricorn2481 wrote: post #133

Earlier quoted context omitted.

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

What about the CPU usage?

Facebook loads a lot of information. I don't think we should be comparing the download size of a hello world app with loading dozens of images on a facebook feed.

Re: .NET Blazor

#149

Post by patates »

jadbox wrote: post #108

Honestly I'm pretty happy with just the stack: server html jsx templates + htmx boost + css view transitions. It's simple, easy to troubleshoot, fast to build, and crucially provides most of the important benefits of a SPA (seamless updates) without hardly any frontend JS.

Wanted to give htmx a try. I have a form, in which multiple text editors can be added. Apparently here we need an endpoint to deliver the extra field and I can tell htmx where to append it, so some extra work but okay.

Then the user should be able to click a button and the additional text editor should disappear.

> Oh for that you need this custom language called hyperscript, it's so easy to get st...

no.

Re: .NET Blazor

#150

Post by osigurdson »

pier25 wrote: post #145
osigurdson wrote: post #140

Earlier quoted context omitted.

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?

React will die too, eventually. Or at least stop becoming the default.

Agree, but a dying star creates new life and pathways from old to new. A dying snowflake, just evaporates.
Post reply on HN