Hacker News Reader

Comment by labrador | Hacker News Reader

> For the front-end, JavaScript is unavoidable (for now)

Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment.

I've learned I can add events and event handlers to elements without ever leaving C#. Then when I need to use a JavaScript library, I can load it just in time for my component. Once I got the hang of it I really felt like I've found the sweet spot for front end development.

Blazor is in development and will only get better. I believe it will eventually be recognized for what it is, but it's still early.

View on HN

Have you actually tried Blazor ? Just the schism between WASM and Server and the feature matrix there, and generally shit quality of early stage Microsoft product - I wouldn't touch it with a 10 foot pole, likewise for MAUI - I've seen coworkers prototype both for some greenfield projects in last month or two and both projects gave up on it because it just isn't there yet for mainstream development.

I mean .NET core was pretty much in this boat pre v3, it took them years to move past the .NET standard mess, Xamarin never cleaned up and they are hoping MAUI will eventually just sweep it under the rug.

I wouldn't bet on any Microsoft stack that hasn't had 3+ years of successful use in the wild - I've been burned too many times. You might say the same is true for any other project/stack - but even when they moved to OSS .NET projects have this Microsoft level of complexity and boilerplate that makes diagnosing trivial things a slog. And Microsoft likes to put "stable" label on a lot of things these days with the pressure to ship. Good rule of thumb - not worth my time until v3.

I've tried Blazor. I built and deployed 3 apps for clients over the last 3 years while consulting and was able to deliver the projects for 33% what it would have cost to deliver them with react or angular.

Clients have been very happy with the results.

Then I built my own startup with it, and we have a solution that 3 devs have been working on for 2 years.

I can't recommend Blazor enough. I love it.

I have run into a fuck ton of problems with MAUI though. It's a fucking dumpster fire of a technology.

* Blazor server side I have very limited experience with client side.

They should really just dump MAUI..calling it a dumpster fire is being polite. Rather let their devs spend some time on Avalonia.

> was able to deliver the projects for 33% what it would have cost to deliver them with react or angular.

That’s a pretty extraordinary claim.

I know single stack can be more productive, but that sounds very impressive. Could you perhaps talk details of:

- styling blazor (eg. Bootstrap, tailwind); is it just drop in? How do you use it, eg. Without the tailwind preprocessor npm package?

- interactive front end components (eg drag and drop) that lag badly when using SS blazor in examples.

- bridging to native js (which is ultimately unavoidable in situations where you need integration like maps as far as I know)

- scaling load on concurrent users (one ws per user right? Are you using the signalr service & functions? I tried this and found the long running azure functions are quite expensive to run. Do you have advice?

Sorry I misspoke I meant a 33% reduction in the size of the projects. So projects that would have taken 6 weeks in React took 4 Blazor server side.

1. We just dropped in a wrapbootstrap template.

2. We wrote some javascript for interactive front end components like drag and drop or rich text editors. It was a little more work than it would have been in React but not much and everything else more than made up for it.

3. We found it wasn't particularly difficult. We'd just put JSRuntime.InvokeAsync in a C# method. Used it for things like popups and initializing some js libraries.

4. We're only using Azure App Service and Azure SQL database. Our long running functions we just run as a scheduled service on the app service. (though eventually we'll to do some refactoring when we need to scale horizontally). We're a B2B SaaS company so our revenue is quite high compared to our compute usage. By our back of the envelope calculations we won't have to add another server until we're somewhere between 5 and 15 million ARR. We think we'll need to do about 2-3 months of refactoring at that point to allow for horizontal scaling.

I wouldn't recommend Blazor-Server Side for B2C typical applications that have a low ARPU.

The big advantage in development speed is we got the functionality of a SPA but at the development cost of a classic multi-page application.

>* Blazor server side I have very limited experience with client side.

That's part of my problem with it - from what I see they are pushing two independent tech stacks (WASM and dynamic server rendering/JS updates) under the same name - but the APIs underneath and the architecture is very different.

The problem I have with Blazor Server side is that it requires a stable internet connection otherwise client socket connection drops and the browser issues a full page reload.

Or at least those were my findings last time I tried. I would be very happy if that isn't the case currently.

For intranet web apps it looks amazing though.

Definitely agree with you. Blazor is absolutely amazing and makes development extremely fast. Makes me wonder if people commenting have even tried it.

> "Have you actually tried Blazor? "

Yes. Server-side Blazor is incredibly productive and fantastic for complex UIs, especially for B2B and other SaaS products.

Server side Blazor is really like webforms in terms of client state management and scalability. I am not sure I would really use it for anything.

> Blazor is in development and will only get better.

How good can it get though? Blazor WASM suffers from the huge initial, multi-megabyte download of the .NET runtime. How is that expected to come down to something in the range of 50-500kb what we have with most JS frameworks now? I just cannot do that on public-facing parts of an application. It is unusable when accessed from a slow mobile network. Company-internal stuff sure, who cares.

I really wanted to love Blazor, and evaluated replacing some of the complex frontend UIs at work which are a JS nightmare with either Blazor Serverside or WASM. But serverside seems like an afterthought to me. I recently learned about Phoenix Liveview here on HN, and according to what I read, it seems like a much better option if you want that server-side rendering stream model. With Blazor-server, I get the feeling it is only a makeshift-solution until WASM takes off, and that makes me even more reluctant to use it.

I know that newer frameworks are slim but in practice bundles still seem pretty huge. Maybe that’s just asset bundling going on but I feel like people are still able to get away with.a lot

While the total download size is unlikely to go below 2MB with Blazor due to .NET Framework binaries, they are working hard on AOT and binary stripping, meaning your app could consist of a base framework download, served from a CDN, and subsequently cached, and a small app specific library that's comparable to a bundled JS lib in size.

>...served from a CDN, and subsequently cached

Due to cache partioning in browsers now, this will still be a big issue for all clients. Don't also forget that many clients are in poor internet speed zones.

A 2MB "buy in" will be unacceptably high for lots of projects (but not all, obviously).

I know I'm coming across ad a blazor fanboy, but I'm curious what made you feel like server side was an afterthought?

The biggest way server side fucked us was originally db contexts are bound to scope via IOC in asp.net similar to MVC or razor pages.

Which is fine when your scope is a single request, but when the scope is a circuit you get so many weird fucking errors. We worked around this by disabling tracking. But the right fix is we should have used factories, but we didn't figure this out until it was too late and we had written a fuck ton of code.

This is such an obvious issue and should have been in the docs but wasn't.

But other than that it seemed fined.

The vast majority of complex JS SPAs are also multi-megabyte payloads. You can also prerender components the same was SSR is used to mitigate JS initialization.

As far server-side Blazor - it seems like an afterthought because you read about Phoenix Liveview? How is that a serious evaluation? Blazor is a core part of the framework now and the server-side model is always going to be a serious option because it enables functionality that can be done with the disconnected client/WASM mode (like direct DB access without the serialization + API overhead).

> The vast majority of complex JS SPAs are also multi-megabyte payloads

I suspect you're talking about full apps that include third party deps. The majority of SPAs are < 1MB unzipped and <150KB zipped. Source:

https://gist.github.com/Restuta/cda69e50a853aa64912d

You can't look at some site that has 10MB of third party deps and compare that to what Blazor is doing. You'll still need third party deps with Blazor as well.

The sites that have a large 10MB bundle would have had 100's of 100KB scripts pre-spa days.

I was really excited for Blazor, until I tried developing for it. The DX is not really there yet and in the mean time I stumbled up HTMX (https://htmx.org/) and now I'm having an even harder time being excited for Blazor. And don't get me started on Blazor Server vs Blazor WASM...

The thing is, Blazor will become the lingua franca of (web) UI development for bigcorps, so I just need to suck it up and learn it (I'm a .NET consultant geared towards finance & insurance)

Its funny, after considering Blazor serverside and WASM, I also opted for HTMX + Alpine.js (when needed) + ViewComponents. Considering how nice server-side rendering story is in ASP.NET, I feel like this is a setup that really works well in a lot of situations, from low-interactivity pages to really complex UIs. It is lightweight on the client side (just load the small htmx and alpine scripts), lets me do much of rendering server-side in .cshtml views, and which needs no JS build pipeline of any kind.

This my exact setup and the only thing I’m missing is Blazor-style component syntax instead of the fairly convoluted way with <vc:*>

Man, I tried out Blazor over the last few days. I really wanted to love it (I love C#), and it looks like it might be good one day, but I found it sadly lacking. I couldn't even add a mouse event to a canvas element. I had to install an extension package to even use a canvas (BECanvas), and then that extension package didn't even have mouse events. I have to say, thats so absurdly basic of a thing to be missing that it made me call the entire library into question: what other extremely basic things could it be missing as well?

Anything with canvas, or a very interactive experience I think Blazor is a bad fit for. I'd do just straight JavaScript or typescript.

But so much of the world is user clicks a button, run server side code, update html, and blazor is an amazing fit for that.

Like I'd never build a Google sheets, Microsoft word, or outlook replacement in Blazor.

But I'd totally build a hub spot, Salesforce, Facebook, reddit or hacker news clone with it.

Author here.

I tried Blazor. We used it for one mission critical project.

We found that the development cycle is too long and it has too much friction compared to Node for front-end development.

Back to Node for frontend (Vue)!

I'm a huge fan of C#, but I didn't really like Blazor when I tried it. I had expected to love it too. I found much of Blazor's boilerplate to be very ugly, I didn't like the complication involved in referencing npm libraries or backend code, and I couldn't figure out where several magical authentication related pages in the example app were coming from. I switched back to Typescript and Vue 3 (almost went with Svelte). I'm investigating the HotChocolate GraphQL library this week to see if I can marry the frontend and backend that way. I was hoping Blazor would give me a nice productivity boost, but native frontend development is hard to compete with. I'll likely try again in a few years.

> I found much of Blazor's boilerplate to be very ugly

I call that bureaucratic software because it reminds me of doing taxes. It's put me off from trying a lot of Microsoft tools, but with Blazor I decided to push through the pain. Once I did, I could see the logic of it and it became less of an annoyance

The thing is in .NET 7, they are going to decouple the WebAssembly toolchain from Blazor.

This will allow people to write competing frontend frameworks, or mix and match their JS framework of choice while calling into .NET app logic.

The latter already possible, though a bit hacky with the official tooling at the moment, since Mono can compile regular .NET code to WASM no problem (a fact already extensively used by game engines like Godot or Unity).

Blazor server was not executed on well. It's a poor react clone before react had hooks. The ecosystem is also small and not flexible. I would choose javascript over it, unless I already had a large investment in C#/.NET.

What? It's Razor templating on the frontend. It's also an MVVM framework, and has much more in common with Angular than React.

If you're willing to go down the f# rabbit hole there's also Fable which I need to try but I've heard very good things about.

Yeah, but F# is even worse than C# in the sense that you need really talented developers to get anywhere. Which is not a problem on personal projects, but can be for the majority of companies.

Building a company based on Fable/F# now. We're in process of taking folks with 2-3 years of react exp and teaching them Fable - it's a pretty quick transition. F# tends to attract some pretty talented developers as well.

Fable is pretty nice to work with. Writing bindings is fairly trivial given typescripts influence on the front-end library landscape, and you can just yolo call things dynamically if you want.

Here's a small gist where I use fable-py to use the python prettymaps project that was posted a week ago on HN: https://gist.github.com/Banashek/1cc3d8435843bcff230906fb037...

In theory, blazor is really neat. But last I checked you have to either go fully thin-client (server side blazor) or have an annoyingly large initial download (client side blazor). Which is probably fine if everyone's wired to the company network, but maybe less so if there's mobile involved or the general public needs access from the local coffee shop.

I'm currently playing around with server side Blazor and it works well. It's definitely not for general public applications but it seems great for internal corporate apps.

The issue that I have is since it is a thin-client re-deploys kick everyone off immediately. Where the web is totally stateless this is 100% state full. I'm used to being able to deploy production fixes rapidly without disturbing anyone's work but with Blazor server that's impossible. I've started to look into load-balancing solutions or something but not being able to roll out fixes throughout the day is almost a deal breaker for me.

It's a pain, but there are some optimizations to shrink the large download size.

This person was able to get it from 14.4MB to 4.4MB: https://www.michielpost.nl/posts/reducing-blazor-webassembly...

Whether that's acceptable is up for debate but it is in line with most SPAs/websites these days.

With blazor you need to choose Client or Server Blazor. Client will give you 10MB+ page downloads, Server will require stable and low-latency internet connection. It's fine for intranet systems, but not for general webdev

Blazor WASM is promising but it really lacks some like MobX. There is a Weave based project that's sim to MobX, but hasn't gotten a ton of traction.

Then there is a Redux-like option and.. No thanks :D

Can confirm, we’re developing in Blazor now and it’s fine. Not as loosey goosey as js, but makes as much sense as any other js framework. And having such tight integration with Entity Framework makes development a breeze.

Blazor server or wasm?

Server. From an ergonomic standpoint, the development is basically identical to WASM ASFAICT. This is all internal though, so ymmv if you're developing stuff for the open Internet. I guess it depends heavily on how married your org is or isn't to c#, which we very much are. I vastly prefer this to serving up a separate UI for what we do.

Reply on news.ycombinator.com