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

101–110 of 302 posts

Re: .NET Blazor

#101

Post by GiorgioG »

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…

Batteries are included, but you aren't forced to use them.

Re: .NET Blazor

#102

Post by pacifika »

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.

Re: .NET Blazor

#103

Post by andrewxdiamond »

Mountain_Skies wrote: post #94
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…

Seems like server vs client would also come with a set of security tradeoffs.

It’s just moving the work that would be happening in the browser to the server. There is no reduction in security with either of these styles

Re: .NET Blazor

#104

Post by Tao3300 »

In the one illustration, there's just an extra disembodied hand sitting on the one guy's laptop. Another one has one finger branching from another instead of connecting to the palm. Is your illustrator okay?

Re: .NET Blazor

#105

Post by eliasson »

I used Blazor Server to build a hobby project of mine [1] and must say I am pleasantly surprised. Not having to build a separate client and duplicating code and models is really nice. I use my project daily and it is surprisingly fast to use, and the dropped connection does not bother me too much.

I would not recommend using it for anything other than smaller applications where users are expected to have a steady connection though. But for smaller applications it’s a nice alternative, cutting some of the effort required to get an application out there.

[1] https://github.com/eliasson/quarter

Re: .NET Blazor

#106

Post by cxr »

jsiepkes wrote: post #46
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…

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

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

Who could have foreseen that hitching your horse to derpy, single-vendor RIA frameworks that were closed source proprietary and worked on the basis of shoving foreign content into the browser to get it to do non-Web things was a bad idea? Oh wait, anyone.

In that vein, in response to the earlier remarks by the original commenter:

> Silverlight burned a lot of small businesses hard, almost everywhere I've worked has had a silverlight horror story of a project they experimented in it with only for it to languish. So now they either have some outdated dependencies they'll never update or had to re-write it back into something else.

Yeah, good. That pain is well-deserved. Almost self-inflicted, even.

Re: .NET Blazor

#107

Post by rqtwteye »

throwaway2990 wrote: post #97
jve wrote: post #82

Earlier quoted context omitted.

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 upg…

Xamarin for iOS and Android just works… Maui on the other hand is a turd. It’s such a pain to work with, workloads just plain suck. And if you install . Net 7 and your project targets 6, It will download .net 7 workloads and fail to build. Then 8 comes out and same problem. Have to pin the SDK.

And by the time Maui starts to mature and work, they will announce a new framework and the cycle starts again. I still don’t understand why they couldn’t keep working on WPF instead of cranking out a new framework every three years.

Re: .NET Blazor

#108

Post by jadbox »

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.

Re: .NET Blazor

#109

Post by throwaway_0235 »

sanitycheck wrote: post #77
keyle wrote: post #71

Earlier quoted context omitted.

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.

Oh, me too. So much now-obsolete knowledge accumulated! Flash was always going to die someday though, as HTML/JS caught up with it. In the end it was killed (arguably) prematurely, but it probably wouldn't have lasted more than another 5-6 years anyway. Silverlight, I think, was worse - only a few years between initial launch and discontinuation. Pretty much every client app based on Silverlight would have had to hav…

> Flash was always going to die someday though, as HTML/JS caught up with it.

I'm not sure that would happen. I think Flash would evolve to just "compile" to HMTL/JS. IOS/Android could be other targets as well, once they found a way that would not upset the Eye of Apple.

Re: .NET Blazor

#110

Post by bob1029 »

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…

> However, now that we have many customers using the application in production, we're starting to see some of the not-so-pleasant side of Blazor Server. When experiencing a lot of requests, the experience is degraded for all users of the app. In addition, it's not very good at re-establishing the WebSocket connection if it fails, giving a poor impression to the user.

We've been using Blazor server for ~3 years now and have had similar experience. We only use it for internally-facing administration sites, and even then it's still quite annoying to hear team members complain about the inevitable reconnecting to website warning, even when everyone knows exactly why its happening.

This experience with using websockets to move state between client and server has pushed us away from the idea that the client could ever be made responsible for any meaningful amount of state. In our current stack, we return final server-side rendered HTML and handle multipart form posts. There are no more websockets in our stack. Everything is stateless HTTP interactions - the client only manages a session token.

SPA was a fun experiment, but I am completely over it. If you are trying to fix some weird UX quirk, reach for a little bit of javascript. Don't throw away everything else that works over something small. There was a time when I would have agreed that you need frameworks, but that time has long since passed.

In 2023, approaches like PHP feel more valid than ever. I know way more about what doesn't work than what does these days. If you want something like PHP but you don't know where to start, you should think really deeply about what PHP is actually doing and if your preferred programming language does not also have a similar string interpolation concept.

Post reply on HN