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

151–160 of 302 posts

Re: .NET Blazor

#151

Post by jen20 »

keyle wrote: post #71
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 professionally saw the rise, the peak and the burn of Director (Shockwave), Flash and Silverlight... By far, the most devastating one, was Flash. One good thing came out of Silverlight, and it's not really getting the credit it deserves: MVVM. As far as I know, Silverlight brought that pattern to light, before that, it was MVC and OO hell. And MVVM paved the way to modern paradigms, imho.

MVVM was also the prescribed pattern for WPF (which shares some other things like XAML with Silverlight). WPF debuted a year earlier though!

Re: .NET Blazor

#152

Post by Capricorn2481 »

sebazzz wrote: post #144
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.

I have the complete opposite view. I'm a fullstack dev, so I'm comfortable using Javascript and a backend language.

JS replacements like Blazor clearly serve backend engineers who don't want to deal with JS. That's fine, and it's a valid way of developing, but it's clear that using JS with C# is a more holistic way of developing.

Re: .NET Blazor

#153

Post by fuzzy2 »

spzb wrote: post #114
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 enjoyed using ServiceStack. Write your data model in the C# API, run a tiny CLI command and it spits out Typescript definitions to match your data model. https://docs.servicestack.net/typescript-add-servicestack-re...

TypeLite used to offer something similar, but it's somewhat dead nowadays.

OpenAPI client generators are probably what's popular today.

Re: .NET Blazor

#154

Post by kqr »

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?

You get a little closer with Fable to compile F# to JavaScript. It lets you model your domain using F# types (which are just as good as – if not better than – C# types) and then you can use them both from your C# backend and F# or JavaScript frontend (whichever you prefer.)

It does require you to faff about with toolchains for building frontend code though (WebPack and the like), and it's not always completely seamless, but if you want to invest in a shared domain model it's the most compatible I've been able to go at least.

Re: .NET Blazor

#155

Post by george_sp »

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…

I feel like your comment touched a million different places so I'll try to compose my arguments in a compact manner, hopefully to make some sense.

> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for.

Where does this conclusion come from? At least from my humble experience,I've been doing them for ~10 years with various tools, both JS and Blazor/Razor Pages and the fact that they "work" does not mean they stand on solid ground.

I've written apps in Blazor, yet I don't understand its existence. Most apps, even LOB as you said, Razor Pages are more than enough. Razor Pages are amazing. What seems to me to be the source of the problem is the whole mentality: > But, as a developer who has done exactly one complex web app for a client, let me tell you, the ability to use C# models, directly from your domain, in web app markup code, using Razor components is a god send... You can ship server side generated HTML with Razor and just LEARN a bit of JS. I don't understand the allergy of the so called "back end" developers with JS. Yes it's shitty. Yes it feels better writing C#. I also like my bike more than my car. Will I take my bike to drive 500km? No. There's a time and place for everything. I feel efforts like Blazor just fight against the (unfortunate yet inevitable) current that JS is the only language that can manipulate DOM. I really think all of us should be open to use whatever makes sense for the job, even if it occasionally makes us feel uncomfortable. This is the dev community I want to be a part of.

Re: .NET Blazor

#156

Post by citizenkeen »

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

Blazor Hybrid looks promising to completely negate the load time for Blazor WASM.

Re: .NET Blazor

#157

Post by jmnicolas »

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?

Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.

Re: .NET Blazor

#158

Post by [deleted] »

Capricorn2481 wrote: post #148
brtkdotse wrote: post #136

Earlier quoted context omitted.

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

[deleted]

Re: .NET Blazor

#159

Post by failbuffer »

DonnyV wrote: post #119
useerup wrote: post #60

Earlier quoted context omitted.

Blazor - until .NET 8 - came in Blazor Server and Blazoe Webassembly variants. Blazor Server renders the DOM at the server and sends it to the browser. The server also holds on to some state for each client - notably the "current DOM" - so that it can calculate diffs on changes and only send the diffs to the browser. Blazor Webassembly does the rendering in Webassembly in the browser. The .NET stack runs in the brows…

"The server also holds on to some state for each client" If this is how Blazor is architected. Then I have no interests in using this and really anyone doing any type of web development shouldn't bother with this. Internal apps eventually need to be used externally. This is a time bomb waiting to explode on the users and the developers. I use VueJS with Asp.net Core with multi-page single load architecture. Meaning o…

It's how Blazor Server apps are architected. Blazor WebAssembly apps don't maintain client state in the server and can be load-balanced like normal.

Re: .NET Blazor

#160

Post by strich »

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?

You can't be blamed for having that opinion given history. But Blazor is I think standing on the graves of those previous attempts and is looking extremely strong - it is as of even a year ago mature, well supported, and a deep ecosystem.

I think it's pretty safe to be optimistic at this point.

Post reply on HN