Excellent presentation. Steve has been working a lot, behind the scene, with authentication for Blazor. Kudos to Steve for all the good stuff he has developed on Blazor, much appreciated.
I love this presentation. Just the facts. They hide nothing,. All the source code is on GitHub. Most of their discussions about the code are on GitHub. They acknowledge two 'issues of concern' with server side Blazor, latency and memory use. Latency is simply not an issue if your users are on the same continent as you, and if they are not you can use something like Azure Front Door. Memory use applies to *all* applications that store any "state" for their users in memory (I guess it would be possible to maintain state in a persistent file system, but then performance would suck).
I am trying Blazor server but facing issue in load balancer, we are not enabling sticky sessions as per security reasons. So my load balanced web server app hosting in iis is not working.
What if you rum blazor server and dont want an external api? Passing round the token and checking it everywhere seems like a huge hassle. Normal asp just signInAsync and you are done..
People keep saying that threading isn't really necessary or important within Blazor but I would argue that completely. The whole idea behind Blazor / WebASM is to execute compiled target code in the browser to give a performance boost for things such as games and other intensive applications. Without threading, there's really no point in adopting a whole new paradigm like Blazor over the traditional options such as React or Vue, other than to unify your tech stack which IMO isn't a good enough reason.
Let me argue in the opposite direction: my "whole idea" behind Blazor IS unifying the tech stack and using a great language and ecosystem (.NET) on the web front end. I don't need insane performance, just acceptable performance. You can't make your own primary need that of everyone else. It doesn't hurt to voice your opinion, but don't pretend like the "whole idea" that you put out there is actually fact.
@@zacharybecknell4757 So you'd drop JavaScript with its years of battle tested strength, the community support and resources that have been developed over decades to provide a rich experience, all to have to learn a whole new framework so that you can write UI components in C#? Its also not just me asking for this, many members of the community are actively awaiting this feature. FYI, that's literally WebASM's intent. webassembly.org/docs/faq/ Specifically read the section: "Is WebAssembly trying to replace JavaScript?" Lets not bullshit each other, threads are necessary, if they weren't, they wouldn't have proposed a specification for it.
@@KieranDevvs I didn't say your desire is invalid, I questioned your assertion that the "whole idea" is what you desire. C# and .NET are not exactly new to the world, and to assert that JS is somehow this rock solid area instead of an ever-shifting landscape of tools is a bit strange to me. I hope you get what you want from Blazor, but it's not what I need and so I'm actively going forward with, and enjoying, Blazor today.
How could you not blocking the UI if you don't have threading? If you have to compute some expensive stuff client-side, then you are not allowing the user to interact with the UI. Threading (or web workers) is absolutely necessary
Kieran, threading is coming to Blazor. The Mono Team are working on it. Versus Vue or React I think it's great that you now have the opportunity to think of development for browser apps differently. These frameworks can be difficult to learn, build and deploy, and you're more often than not working in several different code bases (which is perfectly fine, but it is more cumbersome). If Blazor/WebASM can bring your preferred language to the browser you get a lot of benefits...no duplicate validation logic, no duplicated business logic, a single debuggable experience, hopefully making development easier and quicker. If this isn't worth it, I don't know what is. Are we there yet? Nope....but getting much, much closer.
It's a cool thing, and Steve works very diligently on it, but I can't see Blazor succeed in any way at all. Why: - 5000 concurrent connections sounds really bad, even on a small vm. - Attack surface like DoS is HUGE with something like Server-Side-Blazor, WASM on the client doesn't help either as it's relatively new. I wouldn't get it approved. - Many things you could achieve with Blazor can also be done using DotNetify (github.com/dsuryd/dotNetify), which is imo the better approach in almost all cases. - Personal opinion, but Razor is worse than attempting to parse HTML using Regex, EJS and anything else I've worked with. Also, every IDE I've worked with has some personal issues with parsing Razor as well, highlighting issues and so on. - Competing technologies are way more mature and efficient. A lesser development effort cannot win against that.
@@user-mr-m12312 fair enough, hey maybe it'll pan out. 🤷♂️ I've just been burned by Xamarin before, little sceptical it'll pan out to be a top notch experience. But hey, weirder stuff has happened I suppose
