Hacker News Reader

Comment by unsupp0rted | Hacker News Reader

I'm genuinely wondering: what's the benefit of using Blazor/ASP to build a web app as opposed to Vue (or React/Svelte, etc)

View on HN

One fundamental difference is that if you are building a React or Vue static app, you're going to need a backend anyways. If you're building a React or Vue SSR app (Next.js, Nuxt.js), you'll probably want a separate backend anyways.

If you're going to have a separate backend, .NET has some advantages compared to Node that's worth considering. It's higher throughput than Node for the same compute resources, it's multi-threaded and you can run background workers in-process, it has some nice built-ins for concurrent processing (Task Parallel Library, System.Threading.Channels), the nuget ecosystem is less prone to security risks compared to NPM [0], EF Core is a really mature ORM and possibly one of the best ones out there for productivity, it has serviceable hot reload for productivity, and modern C# is really, really close to JS and TS in syntax [1].

One often overlooked advantage for high security contexts is that .NET has a large standard library that's maintained by Microsoft for really core things like encryption, hashing, database drivers, network code, etc. You get the benefit of having an army of professional engineers maintaining that core code and patching it when security issues arise versus the Node/NPM ecosystem's strong dependency on the community.

C# and .NET are the backend runtime that most teams probably want when they think of moving on from Node to Elixir, Go, or Rust because of how close it is to TypeScript now.

And if you're going to use .NET on the backend, then why not consider Blazor for SSR and static HTML?

(Disclaimer, I'm not a big fan of Blazor, but I can see why teams would choose it).

[0] GitHub State of the Octoverse 2020: https://octoverse.github.com/2020/static/github-octoverse-20...

[1] https://github.com/CharlieDigital/js-ts-csharp

    C# and .NET are the backend runtime that most teams probably want when they think of moving on from Node to Elixir, Go, or Rust because of how close it is to TypeScript now.

Bold statement. Looking like typescript doesn't seem like it should be the most important concern in a backend lang.

I don't think it's that bold. It's like saying learning Spanish is easier than learning Japanese if you're a native English speaker. The basis in the shared Latin characterset certainly makes it easier to learn Spanish, no?

Similar syntax equates to similar constructs and concepts. The way async/await works -- from a dev perspective -- is the same. Exception handling is more or less the same with try-catch-finally. Lambda closures work largely the same (some differences due to how JS binds `this`). TypeScript object hierarchies like interfaces and abstract classes are more or less identical in function (obvious differences, though in underlying implementation and capabilities). Same null coalescing, same nullability constructs. Array methods like `map`, `filter`, and so on are subset of System.Collections.Linq operations like `Select`, `Where`.

Certainly having similar syntactic language constructs makes it easier to adopt if you are already comfortable with try-catch-finally and async/await versus entirely switching paradigms in Go or Rust, for example.

Tooling is very similar from a CLI perspective and DX isn't that different. Hot reload, .csproj = package.json, main.ts or index.ts = Program.cs

I'm questioning whether learning the syntax of a language is the main difficulty in backend development and should be the main decision point.

If you are primarily a C# shop then being able to stay in that ecosystem is quite valuable.

I’ve found C# pleasant to write in, and I get a bad feeling every time I deal with npm. On the other hand the library support for React is just so much better so I put up with it.

EDIT: I’m not a web dev, the web is just the most consistent UI platform for supporting mobile and some desktop we have now so that definitely influences my opinion.

I can think of a few, starting with lack of fragmentation given Blazor's now the "premier" Web Application framework for .NET which has the full focus and developer resources of Microsoft, millions of .NET Developers and 3rd Party Component Developers.

Low platform churn, i.e. Blazor has essentially kept the same development model for 5 years, uses the same MS Build/.NET SDK and Framework libraries that are actively supported by Microsoft. Whilst the JS/FX landscape see's frequent fragmentation, new incompatible major versions, new module loaders, new build tools, 100's of deps which are often abandoned/incompatible after upgrades, etc.

Blazor SSR App's gives you SPA-like responsiveness to traditional SSR Apps by default, i.e. without needing to manage decoupled client routing, complex state, npm deps, build tools, large JS blobs, etc.

Blazor makes it very easy to create encapsulated reusable components, which already sees a large number of 3rd Party component vendors available for it.

The .NET Platform overall is very performant, works flawlessly cross-platform, C# is a very IDE-friendly statically typed language with great tooling e.g. JetBrains Rider is one of the best IDE's available for any language and works cross-platform.

You can use your domain model objects to build sites and never again have to worry about conversion between json and native models.

The main benefit that I keep hearing is that you don't need to split your attention between different languages.

JS does have its own gotchas, so I guess there's something to that... But I can't imagine building things for the web without a solid foundation in html, css, and js.

That's the main idea of Blazor really - to start imagining what building the web without javascript really means.

Hard to imagine web development without Javascript now, but with work of projects like this, maybe it will be easy to imagine web development without Javascript in 10 years time.

> That's the main idea of Blazor really - to start imagining what building the web without javascript really means.

To start? This is not new. We've been down this road a dozen times.

It is mostly for .NET shops, and also the upgrade path for folks still stuck with WebForms.

There's an upgrade path from WebForms to Blazor?

Edit: I guess there is supposed to be [0] I can't imagine it that would actually be any easier than moving to any other technology.

[0] https://learn.microsoft.com/en-us/dotnet/architecture/blazor...

It isn't zero effort, however Blazor is the closest in modern .NET to how Web Forms used to work.

There is even a .NET Conf 2023 session regarding it,

"Bye ASP.NET WebForm, Welcome Blazor"

https://www.youtube.com/watch?v=yhwunQ6XQCg

NPM doesn't work behind my company's firewall

Reply on news.ycombinator.com