Hacker News new | ask | show | jobs
by ptrwis 981 days ago
Blazor is not intended for websites, it is intended for enterprise, intranet CRUD applications with interactive forms, tables, etc. Especially if you already have .Net on the backend. I just finished one such application on Blazor Server and it works great. Programming was easy having previous experience with Angular.

Edit: And the most important advantage, next to productivity, is maintainability, without the entire JS/TS/Node toolkit.

7 comments

Getting these kinds of applications out of Silverlight or desktop apps was one of the greatest steps forward I've seen in at least a couple large enterprise shops - and Blazor definitely feels like a step back in that regard.

Honestly, it's one of the issues I see with WASM as a whole. The JavaScript ecosystem is almost implicitly supportive of open source, since that's essentially what gets delivered to the browser. WASM feels like it take us back towards walled gardens where you have to buy Telerik or Dundas libraries to get the widget you want to use, and then find out they don't play nicely with some other part of your stack. For all but the must graphically intensive use cases, or companies that can afford to own their stack from the ground up, I see little reason to adopt it.

>Getting these kinds of applications out of Silverlight or desktop apps was one of the greatest steps forward I've seen in at least a couple large enterprise shops - and Blazor definitely feels like a step back in that regard.

The thing my enterprise customers wanted to avoid was deploying software on their desktops. They didn't even like rolling out Office. Presumably Blazor eliminates that problem because the whole thing is delivered over http.

> The JavaScript ecosystem is almost implicitly supportive of open source

JS is basically a compilation target nowadays. Don’t tell me that a minified, tree-shaken JS file somehow helps open-source. Sure, .NET is definitely not the panacea of open-source, but that is not inherent in the technology, but the politics around.

The person you're replying to is talking about Blazor Server which does not involve WASM at all.
How does that work in the modern age of ubiquitous cloud, BYOd, international corporations and global hiring pools? In this world, there's basically no difference between internal and external websites, maybe except for authentication and/or needing a VPN to access, which just exacerbates these problems.
My applications run on intranet/VPN behind IIS with Windows Authentication. If not WA, I would always choose Blazor Wasm, it gives you more control over what you do.

When building internal applications, you can make many assumptions - where are your users and how good is their network connection, how many of them do you have - dozens? hundreds? maybe even thousands, but not millions, so scalability is not a problem. Whether the app will be used on a mobile phones or not. Will it be a problem if your application takes 20 seconds to open? :) If the employee will use it half of the day, then probably no.

> ubiquitous cloud, BYOd, international corporations and global hiring pools

My org does none of these so Blazor was a great option for us.

That I do not need consumer grade performance with the people I employ. Sucks but is true for internal apps.
Blazor Server is completely inappropriate for an internet facing site.

The same is not true for Blazor Webassembly, which operates as combination of client and server projects, typically communicating via standard REST calls.

You can, but then JavaScript frameworks or "old" SSR/MVC are just better.
Nope. Being able to write in C# using a vast array of C# libraries in the browser is orders of magnitude better than writing in JS or even TS. C# is enormously superior to JS and superior to TS.
If you care more about development experience than users, that's fine, but in the case of SPA, JS frameworks will be faster and lighter.

For me the problem with TypeScript is not the language, JS/TS are fine for me, the problem is the entire toolchain - NodeJS, all the node_modules, configuration files, the need to compile.

Maybe Svelte, where they got rid of TypeScript and the types are now in JSDoc, could be a compromise.

But...back to the original topic, is drag and drop laggy for those use cases?
In Blazor Server, for things like drag and drop or any mouse movement events, you should avoid tying them to server-side handlers, but you can also just write JavaScript code. The backend needs to know what to render, not necessarily where, you can keep it on the frontend.

You can also just use Blazor WASM, but I've had trouble setting up Windows Authentication when in Blazor Server it works out of the box.

No. This website is slow because its a liveview style websocket on each drag and drop action. A wasm implementation would not exhibit these characteristics.
Also, internal-use apps are typically accessed over the LAN with much lower latencies than random Internet users.
On the other hand, remote work is very popular today, but if employees want to work remotely, it's their problem to have a good internet. I tested the Blazor server on a poor cellular network where packets could be lost or there were random long delays in packet delivery, and the application was unstable. It was better to set long-polling and enable compression, which is disabled by default. This is also a problem with websockets - messages are not compressed. Long polling again was less resposnsive on good internet connection. I'm curious how this would work in various configurations of quic/http3.
It's possible to enable compression for WebSockets, but the real problem is latency, not bandwidth. You can't fix the speed of light.
Blazor on Webassembly is not really slower than react or angular. Just the initial load (which is very cacheable) is the problem.
That made sense back in the day, but I can slap some crappy CRUD app together with Next and Formik in a few hours now.
Blazor provides a number of render models or modes. You can now create SSR websites with streaming.
There is now SSR with partial late loads (aka streaming) in .NET 8. That might make it applicable, but IMHO not in the spa space.