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

261–270 of 302 posts

Re: .NET Blazor

#261

Post by [deleted] »

bragh wrote: post #258
cxr wrote: post #216

Earlier quoted context omitted.

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

[deleted]

Re: .NET Blazor

#262

Post by miffy900 »

v-erne wrote: post #256
unsignedint wrote: post #232

Earlier quoted context omitted.

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

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

Maybe some people do learn, and in this case it's Microsoft, who are not repeating the same thing with Blazor as they did with Silverlight.

Re: .NET Blazor

#263

Post by solarkraft »

cl0ckt0wer wrote: post #192
george_sp wrote: post #155

Earlier quoted context omitted.

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

I spend most of my dev time in typed languages. Going to untyped languages feels like going from K'nex to clay.

Same here. I'm a web developer. Very few people use Javascript without types (through Typescript).

Re: .NET Blazor

#264

Post by LaGrange »

brtkdotse wrote: post #129
LaGrange wrote: post #118

Earlier quoted context omitted.

> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. The disadvantages: the _actual user_ is going to have a horrible time with the application. It will load slowly, work slowly, probably break the moment you inevitably will have to touch JS, and if the browser the user hates anyway is out of sync with the forced updates, the entire thing will blow up. But enterprise LOB…

> It will load slowly, work slowly Why do you think this will be the case?

Literally a quote of one of the dismissed drawbacks. The post didn't question whether the drawbacks are real, just said they're irrelevant.

Re: .NET Blazor

#265

Post by LaGrange »

littlecranky67 wrote: post #238
guhidalg wrote: post #230

Earlier quoted context omitted.

I'm not who you're replying to but designing for excess resources is the kind of thinking that leads to slow software. > And dont forget business workstations are usually connected via at least 1GBit Ethernet. NOPE! More likely they are WiFi connected Dell shitboxes running Windows 11 with 8GB of memory, half of which is taken up by all the browser tabs, Teams, Office, and the 30 horrible little programs that IT depl…

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.

Re: .NET Blazor

#266

Post by LaGrange »

mbesto wrote: post #131
LaGrange wrote: post #118

Earlier quoted context omitted.

> All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. The disadvantages: the _actual user_ is going to have a horrible time with the application. It will load slowly, work slowly, probably break the moment you inevitably will have to touch JS, and if the browser the user hates anyway is out of sync with the forced updates, the entire thing will blow up. But enterprise LOB…

Serious question - do you know this to be in fact true of Blazor specifically, with real life comparisons, or is this just conjecture based on analogous frameworks?

This is silly. I mean sure, I did try out Blazor - and ended up unimpressed despite otherwise quite liking C#/.Net - but ultimately it's Blazor making extraordinary claims.

And some of what I wrote is about the programming model itself - by now my experience is that domain models should generally stay on a whiteboard - it's quite rare that's actually what's more convenient in any specific place in the codebase. Trying to "streamline" that tends to end up just introducing even more complexity due to poor abstraction match.

Re: .NET Blazor

#267

Post by LaGrange »

cl0ckt0wer wrote: post #192
george_sp wrote: post #155

Earlier quoted context omitted.

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

I spend most of my dev time in typed languages. Going to untyped languages feels like going from K'nex to clay.

This is hilarious, because clay is just such an amazing material.

Re: .NET Blazor

#268

Post by unsignedint »

v-erne wrote: post #256
unsignedint wrote: post #232

Earlier quoted context omitted.

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

Yes, I would call that fairly substantial considering its underlying architecture is no longer viable -- not because of Microsoft's fault, but as the industry as whole moved away from the plugin-based AIR.

Silverlight was somewhat of a unique situation, as it was a platform where it heavily relied on the platform that was phasing out. (And to clarify, that "decade" is the period that Microsoft was committed to support for latest Silverlight 5. Their first version was released in 2007, so it had about 14 years of history.)

As with Java or any other languages, you can still run it if the environment it runs can be resurrected. (I would not connect that to the internet, though) And many parts of what actually powered Silverlight still thrive in a form of .Net.

I mean where they can support, Microsoft tends to keep its compatibility fairly intact, for instance modern Windows still can run many of the 32-bit binaries from early days. (And you even could do the same for 16-bit apps on a 32-bit platform, not sure if that's still possible, though.)

Re: .NET Blazor

#269

Post by mythz »

feoren wrote: post #226
mythz wrote: post #40

I take the opposite view, as a recent Blazor convert since the just released .NET 8 we're now recommending Blazor for any new .NET Web App (excl. CDN Hostable, SSG websites). I was short on Blazor before .NET 8 and could only seriously recommend it for Internal Apps since the compromises for using either of Blazor's Server or WASM Interactivity delivered a poor UX for Intranet hosted Apps as covered by this post. How…

> Blazor SSR + Vue I'm sorry, but WTF? You spend 5 paragraphs talking about how great Blazor Server-Side Rendering is and then throw a "+ Vue" right at the end? WTF? So it's not SSR at all !? How are you avoiding npm and JavaScript builds when you're literally using Vue? That little example app you showed has ~3500 lines of JavaScript in it ...

> So it's not SSR at all!?

It is 100% using Blazor SSR, i.e. uses Blazor Static Rendering on all Blazor Pages and never uses Blazor Server or WebAssembly Interactive render modes.

> How are you avoiding npm and JavaScript builds when you're literally using Vue?

Because all interactivity is implemented by progressively enhancing Blazor Static Rendered pages with an ESM build of vue.min.js, which doesn't require any npm dependencies or any build tools. Vue.js is a dependency-free 60kb gzip download loaded directly by browsers using its native JavaScript Modules and Import Maps support, i.e. same approach DHH has moved to [1] for all his new Rails Apps precisely because it lets you develop modern Web Apps without any npm dependencies or build tools since it uses the Browsers native module support for loading JavaScript modules.

> That little example app you showed has ~3500 lines of JavaScript in it ...

https://blazordiffusion.com is an example of how you can build highly interactive Web Applications without ever needing to resort to Blazor Web Assembly or Blazor Server Sockets for any interactivity features. For a more traditional Web Application that's primarily server rendered, including a markdown powered Blog and Auto CRUD UIs which uses pockets of Vue.js for any components requiring interactivity, checkout a Live Demo of the empty (100% SSR) blazor-vue template [2]:

https://blazor-vue.web-templates.io

[1] https://world.hey.com/dhh/you-can-t-get-faster-than-no-build...

[2] https://github.com/NetCoreTemplates/blazor-vue

Re: .NET Blazor

#270

Post by LaGrange »

codegeek wrote: post #142
louthy wrote: post #124

Earlier quoted context omitted.

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…

> You install a package today. In 3 months, that code won't build.

Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine.

> And I did I get to the 100s of config files that need to be set just so I can run "npm build" ?

..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.

Post reply on HN