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.
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.
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.
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?
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.
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.
Yes. Server-side Blazor is incredibly productive and fantastic for complex UIs, especially for B2B and other SaaS products.
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.
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).
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.
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.
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).
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)
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.
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)!
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).
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
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...
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.
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.
Then there is a Redux-like option and.. No thanks :D
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.