I know MSFT technologies get a lot of hate here, but ASP.NET Core is pretty awesome. Blazor (the wasm based framework) is innovative and a positive step forward frontend web development.
You should leave your prejudices aside and give it a try if you haven't yet.
Are you reading the same HN as I do? In the last couple of years, I see a lot more positive than negative comments whenever Microsoft comes up. From what I see, Google is the company that gets the most hate on HN.
Of course, Microsoft isn't universally loved. There are a lot of people that don't trust them based on their past behavior, and the fact that Windows and Microsoft Office are still an entrenched monopoly. That might not apply to ASP.NET Core, but not everyone is going to let MSFT off the hook.
Interestingly, I ran some very rough sentiment analysis of the comments here and it turns out that Apple gets people the most worked up, followed closely by Facebook. Of Apple, Google, Microsoft, Amazon, and Facebook, posts about Microsoft did seem to have the most positive comments.
Oh, I remember being hit by this. Agree that it's not well documented; I think it's there to prevent "signing services" from spring up (not that it does a great job…)
I thought it was pretty clear even without any Stats.
People know what Microsoft is doing, the good things and Open Sources. They dont use it not because of hate, I think it is
1. It isn't good enough to make the jump into another ecosystem or language yet.
2. Not hating doesn't mean loving them. IE era, that is IE 5 - 6 if you aren't old enough ( Yes, some people still bash WebKit as the new IE and thinks IE era meant IE7... ) along with the pain on early Windows days still hurt a bit, they will have to try harder, and doing so continuously to win those people back.
The thing about Apple isn't hate as in Google or Facebook. It is people have high expectations of Apple and demands quality from them, and when they are not up to that high bar, people complain.
I've noticed for the new things MS introduce, especially open source stuff, there is a lot more love thrown around.
However, if MS does something that could remotely look like Embrace, Extend, Extinguish then a lot more hate is thrown around. This is occurring a bit more as MS pushes outside of it's Windows world.
It seems to me their general plan has changed to Embrace and Host
Blazor might pull me back into software development. About five years ago after close to three decades of doing software development, I got tired of seeing so much software being bent and shoved into JavaScript. I absolutely loathe JavaScript so it seemed like a good time to move on to something else, which in my case was IT security. Occasionally I write a tool or two for use by my team but most developer jobs these days require coding in JavaScript so I hadn't given much thought to going back to full time development work. Blazor however has been a joy to work with. My understanding is JavaScript will still be required for a while on most webassembly apps but for my uses I've been able to avoid doing any directly. Maybe in another couple of years the market will change and those who don't want to use JavaScript everywhere and are horrified that even embedded systems are flirting with js, will again have a place in the world.
I have found similar joys in using Blazor. Once you get past the boilerplate stage, the productivity gains go exponential very quickly. Component reuse + strong typing + no API controllers or JSON contracts = how web development should have always been. I've got elegant LINQ statements right in my component markup. Creating extremely complex tables and views is so trivial with this combination of technologies. I can even subscribe my razor components to CLR events and everything works exactly the way you'd hope it would. The SignalR link between client and server abstracts away a huge bucket of questionable practices, with some potential trade-offs. Perhaps there is some downside I haven't found yet, but at this point I feel I could live with whatever strangeness might begin to emerge from the path I have taken.
In my experience, it is not possible to completely eliminate JS from the equation with Blazor. I've had to write a single .js file which I currently use for 3 things: Reading a cookie, writing a cookie and focusing an arbitrary DOM element. The focus concern I could probably alternatively handle with an autofocus attr which is dynamically inserted into the razor component, but somehow this seemed easier. Cookie or local storage interop requires JS. This is a very simple bit of code to write, and I would strongly recommend implementing it yourself to become familiar with Blazor component lifecycle events (i.e. how you make sure this JS shim is loaded into DOM before invoking its methods).
I've been wanting to create a public GitHub repo with a more practical Blazor boilerplate app that might help others get started with this kind of concern a lot faster. Perhaps something like an LDAP-authenticated business operations dashboard. Seeing an actual cookie session token read/written and how all of the code flows for session management purposes can save days of frustration. I already see some options out there for Nugets that claim to handle Blazor session management for you, but in my experience these almost always get in the way and force techniques upon you that you really didn't want to work with. If you find yourself reading the documentation for a CookiePolicyOptions or ClaimsPrincipal type, you probably went too far down the rabbit hole.
> no API controllers ... I've got elegant LINQ statements right in my component markup.
You do need to be careful with requirements before choosing this tight binding. If you want single source, that's a great idea. If you need single source for mobile web + mobile app, you will be duplicating code. There are other reasons for API and business logic remaining server side.
> . If you find yourself reading the documentation for a CookiePolicyOptions or ClaimsPrincipal type, you probably went too far down the rabbit hole.
How do you suggest performing method authorization without claims?
There is nothing stopping you from developing razor components which are capable of dynamically adjusting depending on the specific device you are targeting. You can add some JS interop to handle these queries, and then pass the device type information as a cascading parameter to all components from the top.
I am not sure what sort of authorization schemes you are concerned with. All I use the cookies for is looking up an active user session via whatever SHA256 token is stored there (if any).
I really like the approach of Blazor wrt WASM, but really dislike having to dump whole code blocks into CSHTML files like I'm writing old ASP.NET Forms again. Something just feels off.
Is there any way to isolate those code blocks and import them?
EDIT: To answer my own question, this appears to be the solution:
The latest release (.Net 3.1) finished the partial classes implementation so now you can create a `Comp.razor` template file and a separate `Comp.razor.cs` code-behind file that only contains the code. These are automatically compiled together on build.
This is something that hosed me up too at first when using Blazor. There is a specific item type in the VS "Add New Item" dialog that is called "Razor Component" with a fancy purple icon next to it.
If your files in the solution explorer end in .razor, you are using the correct item type. If your files end in .cshtml, you are going to have a bad time and everything will seem very wrong. At first, I was using the "Add->Razor Page" context menu option assuming this was what I wanted, but it will give you the wrong type of item.
Sure, but on posts where the comments head downhill lubricated by this trope, often the commentators were still in kindergarten during this time. There's a cargo-cult mentality when it comes to accusing M$ of Embrace, Extend and Extinguish. Sure it happened but the folks leaving these comments weren't around at the time working as pro-software developers. I was, it was annoying, but the world didn't implode, and the law kicked in and did mostly its job.
So big deal and yawn. MS has a new management, it was "infiltrated" by the right folks in the early to mid 2000's who educated MS from inside and began to set MS on the right track. It takes time, like steering an oil tanker.
But MS are a capitalist corporation, just like all the others, they will all do some evil at some point in time on behalf of their bottom line and shareholder dividends, if they think they can get away with it.
Since you seem to have a positive sentiment towards Blazor, can you point me to a good introduction that demonstrates the power and the benefits of the framework, e.g. increased expressiveness, reduced friction, etc? I've looked through a couple of intros but they never seemed to really sell the benefits of it. As someone who loves the C# language and .NET ecosystem I really want to like it but nothing has clicked so far.
Attended a Blazor session at MS Build in May. My impression was, Blazor seems like a super cool tool that I will never be able to justify in production. For one, the performance is poor right now. Your options are either to use Signal to send every action over the network, or to deliver the entire .NET libraries along with the page. The size of that download is both impressively small (given the volume of code you're transferring), and also still way too large for me to feel comfortable foisting that on users.
Additionally, it requires that your front-end team feels comfortable working in .NET technologies. Ours certainly doesn't, and it would be very hard to sell my director on anything that doesn't maintain the traditional backend/frontend split.
The shared advantages are strong typing and compilation, C# code and constructs, Nuget ecosystem, and shared classes and logic between frontend/backend.
Client-side currently suffers from large download size and startup time (since the wasm .net runtime still interprets all the DLL files) on every run. It's still in preview so expect this to get better eventually. Client-side also still requires HTTP calls to the backend (since that's the only thing available in the browser) but you can use the `HttpClient` with all the shared classes and included JSON facilities instead of maintaining a separate version in JS.
Server-side means all the components run on the server, with updates and interactions run over SignalR websocket connection. This is best suited for internal apps, enterprise SaaS or other highly-interactive apps that would need a real-time connection anyway. The fact that all the UI logic runs on the server means you save a tremendous amount of effort by skipping all the view models, serialization, http calls, and everything else that's necessary. You can have database calls right in your component. This makes complex interactions incredibly easy. If you fit this scenario, Blazor is an fantastic tool compared to what we had before.
Also it's important to note that you don't need the whole app to be in Blazor. You can easily use MVC or Razor pages and just include an interactive component somewhere on the page. We use this for a normal server-rendered site that has some pages that require complex logic and just have that part powered by Blazor server-side as well. It's seamless and even supports server-prerendering so the first-load of the page is fully composed before the real-time connection starts up and takes over the state.
The idea is to unify the development process and tooling on the front-end and the back-end, without suffering from poor performance and constant unnecessary roundtrips over the network. Not to mention, a significant number of people strongly prefer C# to Javascript (and even Typescript).
If those two things never bothered you, then you might not understand the benefit, and you can continue to use what you like.
In practice, sending the .NET libraries over the network is the major burden of the approach Blazor takes, since the first load will be slow and bandwidth-intensive, even though everything will likely be cached for subsequent visits.
However, as the WASM tooling and standards improve, the library sizes will shrink, and less libraries in general will be necessary to accomplish stuff that has been solved at the level of web standards.
There is also server-side Blazor which doesn't use WASM components but instead uses SignalR to do client/server communication. Both are compatible with the same code base (and components). Server-side Blazor still has overhead but it's different from having to send the .NET libraries over the network.
Yes, sure. In my opinion, these are the main features:
1. You can have all the benefits of a static-strongly typed language such as C#. Which implies: better tooling, less prompt to type errors, and more suitable for enterprise software.
2. You get the full power of .NET in the browser
And, if you are already using ASP.NET for your backend:
3. You can reuse a lot of code. This means almost no class duplication (like when you work with TypeScript).
Extra:
4. Blazor is pretty similar to Angular +2, so the learning curve is smooth if you either have experience with Angular or C#.
I think the main benefit of Blazor (server side) is that it's very easy to write SPAs with it. This is great for incompany apps that don't have a lot of traffic (Blazor can be difficult to scale).
You bind your backend to your frontend and SignalR communicates all changes.
But there are some things you should be aware of. Because the frondend and backend are integrated it's very easy to 'leak' your data layer to the frontend. Always use viewmodels.
.net core in general has grown, building cross platform scalable apps is a breeze. Also they have really built some great performance libs, (Channels, Pipelines, Span, Memory).
The tooling is a little wonky at times when it comes to blazor. Hopefully they will turn this into a flagship product.
Blazor will only work on an Electron-ish setup. You'll never see adoption on the interwebs.
It reminds me of the ole UpdatePanel/AjaxControlToolkit/ViewState world where big/complicated/bloated frameworks with big runtimes were trying to solve super simple problems.
I thought that too after my initial look at Blazor. Then I realized a big target for Blazor is enterprise and corporate intranets where network speed is many times not the issue
I didn’t see any reference to existing work in this area in the article, I’m curious to know how this differs from projects like WasmerSharp by Miguel de Icaza released a few months ago.
I'm not advocating anybody do that, but it's a fun experiment to think about. I've been intrigued about WebAssembly more than ever when I read a comment here on HN that the specs very generic allowing it to be used even outside the web.
Which makes it a good demonstration of both technologies.
Kind of like using Google translate to go from English -> Something -> English. In theory a perfect translation would give you back your original input exactly.
Of course this should be more feasible with programming languages than with human languages.
Actually, Blazor is a compilation of the C# runtime (CLR) to webassembly, and a mechanism for downloading standard C# dll assemblies to the browser to execute there. The C# code is compiled normally; it doesn't know/care that the CLR is running in a browser rather than on a Windows desktop.
You should leave your prejudices aside and give it a try if you haven't yet.