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

281–290 of 302 posts

Re: .NET Blazor

#281

Post by NicoJuicy »

progmetaldev wrote: post #275
v-erne wrote: post #256

Earlier quoted context omitted.

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

The difference is that Blazor is built on web standards (WebAssembly), not a proprietary technology. Sure, Microsoft could discontinue support for Blazor, but WebAssembly will keep running. C#/Blazor are not the only technologies using WebAssembly. I personally wouldn't use Blazor for a public facing website, and would only use it for an internal LOB app where I know I can dictate what browser technologies can be use…

Correct.

Silverlight came when flash was being dismantled shortly after.

Different days back then.

Re: .NET Blazor

#282

Post by NicoJuicy »

jeroen79 wrote: post #236
jmnicolas wrote: post #157

Earlier quoted context omitted.

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

Thats not always true, they keep some stuff that is a success for a long time, but they are also not afraid to drop there failures like ActiveX, SilverLight, VBScript, ... And i am afraid blazer may be next.

Vbscript - deprecated, started 28!! Years ago

ActiveX - same, but 27! Years ago

Those were not failures. But have replacements.

Those are terrible examples tbh. A lot of businesses would sign immediately if they knew something was going to be supported for > 20 years. Additionally, vbscript owners should have long migrated to eg. Powershell

Re: .NET Blazor

#283

Post by NicoJuicy »

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

That's not true since .net 6

https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...

Re: .NET Blazor

#284

Post by patates »

citizenkeen wrote: post #161
patates wrote: post #149

Earlier quoted context omitted.

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.

You don't need hyperscript, you can just do it with Javascript.

If I'm writing JS for something as simple as removing an element, then I can keep writing. Alpine.js would make more sense in that case.

Re: .NET Blazor

#285

Post by littlecranky67 »

LaGrange wrote: post #265
littlecranky67 wrote: post #238

Earlier quoted context omitted.

Any data to back this up?

Any data to back _your_ claims up? Because, y'know, sure, all _we_ have is years of lived experience.

If your point is that companies run outdated, shitty computers connected over unreliable WiFi, _your_ corporate life experience has been vastly different than mine.

Re: .NET Blazor

#286

Post by kmac_ »

zyl1n wrote: post #98

As a java backend dev, I am envious that Java doesn't have a modern equivalent of Blazor.

There was a sort of a equivalent - GWT. And it was really good and ahead of the time: it covered intermediate API out of the box, provided quite nice way to develop FE in plain Java, it was async, it allowed common BE and FE codebase.

Re: .NET Blazor

#287

Post by pjmlp »

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.

Try Silverlight, XNA, C++/CX, .NET Native, UAP,....

The difference is that they stop talking about it, their presence fades away in conference and developer blogs, and eventually from Visual Studio installation workloads.

Re: .NET Blazor

#288

Post by pjmlp »

steve1977 wrote: post #218
jmnicolas wrote: post #157

Earlier quoted context omitted.

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

You can still develop Win32 and MFC apps today - those are more then 30 years old.

Win32 is the main Windows API, and MFC, besides fixing HDPI issues, the hard reality is that after crashing the whole WinRT/UWP story for C++ developers, there is nothing left on the Microsoft ecosystem for doing GUI in C++.

Re: .NET Blazor

#289

Post by pjmlp »

progmetaldev wrote: post #279
rqtwteye wrote: post #107

Earlier quoted context omitted.

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.

It's because WPF was too heavily tied to Windows technology.

Only because they didn't want to put the work to make it portable, as proven by Avalonia folks.

Re: .NET Blazor

#290

Post by steve1977 »

pjmlp wrote: post #288
steve1977 wrote: post #218

Earlier quoted context omitted.

You can still develop Win32 and MFC apps today - those are more then 30 years old.

Win32 is the main Windows API, and MFC, besides fixing HDPI issues, the hard reality is that after crashing the whole WinRT/UWP story for C++ developers, there is nothing left on the Microsoft ecosystem for doing GUI in C++.

Yeah unless you go non-MS frameworks like Qt.

And yes, the current state of affairs is kinda sad.

Post reply on HN