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

251–260 of 302 posts

Re: .NET Blazor

#251

Post by sebazzz »

Capricorn2481 wrote: post #152
sebazzz wrote: post #144

Earlier quoted context omitted.

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.

I'm comfortable with Javascript. I'm not comfortable with constantly having to change and upgrade my code or build system for the next breaking change in Webpack or in an unreadable complex Typescript typing, or the spider web of React libraries.

Doing nothing is not an option either, because that bites you in the ass as well because that newer Node runtime turns out not to support a deprecated md5 hash function the outdated Webpack in this project, which only gets a few weeks attention per year, relied on.

Now I only have Blazor for my frontend with a little bit of gulp to compile some dart-sass with design tokens and do some minification on some glue javascript.

Re: .NET Blazor

#252

Post by mattgreenrocks »

Curious to try SSR to see if it can dethrone SvelteKit for me. SK is pretty great, though the backend side feels under-baked a bit compared to FastAPI.

Regardless, I’m pleased to see more contestants try to wrest mindshare away from JS culture. Cambrian explosion or something!

Re: .NET Blazor

#253

Post by merb »

Capricorn2481 wrote: post #172
ninjis wrote: post #164

Earlier quoted context omitted.

.NET 8 is suppose to greatly improve AOT. Depending on your use case, you might be able to get around bundling the runtime entirely.

As far as I understand, .NET 8 AOT has nothing to do with the webassembly blob that gets served to the client.

Actually dotnet wasm can be further trimmed in .net 8. but for most non rtl people the biggest improvement will be to reduce the locale bundle. Sadly it’s not possible to specify which ones you want. Also it’s not possible to bundle DLLs/webcil. I.e the dotnet compiler will be shipped to the client thus you will also get shipped lots of dlls

Re: .NET Blazor

#255

Post by mattmanser »

jmnicolas wrote: post #157
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?

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

Silverlight, WPF, OData (was amazing for hooking your backend up to client-side tables, rubbish at everything else), WWF (Windows Workflow Foundation), WCF (thank god).

All dead.

And those are just the ones I can think of from the top of my head.

Plus the terrible excel VBA replacement they made, then abandoned, and now it's some fiddly javascript mess.

I'm sure there's a ton more people can add. Those are just the ones I personally wasted time on.

And let's not forget Window Mobile!

Edit: They've also gone through a stupid amount of changes in the asp.net MVC model in quite a short time. Plus constantly seem to overhaul their consistently overcomplicated authentication/authorization system. The state it's in at the moment is shockingly bad.

Re: .NET Blazor

#256

Post by v-erne »

unsignedint wrote: post #232
glonq wrote: post #188

Earlier quoted context omitted.

RIP Silverlight

Silverlight's phase-out primarily stemmed from the browser ecosystem's shift away from plugins. It's worth noting that Silverlight 5 was supported until October 2021, a decade after its release, indicating substantial longevity despite the changing landscape.

Ok first thing first - allow me to vent my existential frustration with few off the cuff (mostly rhetorical) questions ...

You call decade a substantial longevity?

Is this some kind of a joke?

Is your ability to assess being held hostage by js ecosystem expererience?

But seriously - I expect a bit more from platform that could potentially waste my life and my venture. I am still happily supporting some Java (and JSF) code that I have written for clients 15 years ago (don't you just love that sweet support fees that you get mostly for being alive and breathing ?). Meanwhile my friend that build whole company around product written in silverlight almost went bankrupt. Now after few years working in AI (going into it a bit too soon) he is trying to create same product in ... yes you guessed it, Blazor.

Maybe some people do not learn from their mistakes :)?

Re: .NET Blazor

#257

Post by Yodel0914 »

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…

It's not just web frameworks - it's all MS UI frameworks. On the desktop there WinForms, WPF, UWP, WinUI, Blazor, MAUI... it's really seems like a mess with no clear direction.

Re: .NET Blazor

#258

Post by bragh »

cxr wrote: post #216
bragh wrote: post #31

The whole discussion around why a .NET shop might choose Blazor over Javascript ecosystem misses these critical things when it comes to developer experience: 1. Antivirus scans — it will take a lot more time for an antivirus to scan the tens of thousands of files in node_modules than whatever dotnet is doing. Especially on Windows 2. Corporate proxy support — the story of proxy support and importing custom certificat…

If antivirus scanners come up at any point when the topic is things that are "critical" to the developer experience (let alone as the very first thing), that's a really telling baseline—the tip of the iceberg as far as indicators of organizational dysfunction go. You might as well be speaking from a place where every employee starts the day with a nailgun fired through the palm of their hand and then they spend their…

Not sure that I follow... From what I have understood, a lot of corporations have these kind of set ups in place to avoid downloading malicious software, limit the possible impact of malware, monitor employees and so on. And it is clear that no development team can change policy for whole organization — so why shouldn't developers choose the kind of tooling which allows them to deliver within the constraints of the organization?

Re: .NET Blazor

#259

Post by mgh95 »

halfcat wrote: post #239
mdasen wrote: post #195

Earlier quoted context omitted.

Yea, I've been using Blazor in .NET 8 through the previews and it's really nice. The Server Side Rendering is fast like any server-rendered stuff. Enhanced Navigation means that pages load even faster since they're just using `fetch` to get the next page and swapping the content (like Turbo in Rails). When I need some interactivity, the page still renders from the server and then the browser downloads the WASM in the…

> With WASM-GC, .NET won't need to ship a garbage collector and WASM-based stuff won't need to copy between WASM and JS for DOM manipulations. Does this mean the JS-interop performance penalty goes away?

It would both improve the performance of c# performance, reduce alloc overhead for javascript interop and reduce download size. It's an absolute win.

Re: .NET Blazor

#260

Post by keyle »

jen20 wrote: post #151
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.

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

Ah, there you go! TIL.
Post reply on HN