> With this newest Blazor release we’re pleased to announce that Blazor is now in official preview! Blazor is no longer experimental and we are committing to ship it as a supported web UI framework including support for running client-side in the browser on WebAssembly.
Blazor has been split into two versions, there is a server side and a client side version, both that share the same component model. The server side version went GA a last week with .Net core 3.0, the client side is looking like it will GA in April 2020. The reason given is that their not happy with the size of the payloads required for now, the aim to have everything compiled to webAssembly by then, not just the mono runtime that's running as an IL interpreter at the moment.
The server side version is interesting, it ships DOM updates to the client from the server over a websocket (musch like OOUI https://github.com/praeclarum/Ooui). Not something that I'd use for production, but for quick internal projects which have the feel of a client side SPA, but while not requiring you to build the API layer it's quite neat.
Except it is much more intuitive. A repeater- like construct (a foreach) just works. Collections just work. No thinking about data binding at the correct time in the life cycle of the page. You can even call front-end javascript in a sync-like (using async) matter. You can just call a javascript confirm if you like. It is awesome.
> The reason given is that their not happy with the size of the payloads required for now
Question: how will they go about shrinking them? Will this happen in the near future?
I've tried out Blazor before and the page doesn't load until you've downloaded everything. Will it always be that way, or will it be like JS eventually -- you see the page, and the JS loads in the background?
Not to diminish the achievement here, which is considerable, but I feel like a lot of these WebAssembly-based projects miss the forest for the trees.
JavaScript isn't really that big of a problem or a performance killer. The DOM is. I don't know what the answer is (rendering to a canvas tag is awful for accessibility) but I'm hoping that in time we see the improvement that is to the DOM as WebAssembly is to JS.
Sure. Blazor scratches a developer itch. But end users aren't likely to feel a difference one way or the other. The same bottlenecks are still the same bottlenecks.
My experience of tools/languages that sit on top of the actual native implementations (e.g. React Native or Xamarin on mobile) is that they often lead to much slower development, since when you're Googling around trying to find answers to an issue you're looking in a much smaller community for answers. Eventually the answer usually ends up being "just do it the native way".
Hopefully Blazor will avoid such issues. In any case I'm probably speaking out of turn... it clearly isn't designed for wide-scale deployments - in house/intranet tools are a different beast anyway.
I use Xamarin Android and while you are right about the ton of googling needed, it was always to search for Android API and almost never because of Xamarin itself. Once found, it’s straightforward to convert from Java code to C# except a few cases (layout parameters for instance). The other issue is coming from a nicely design framework (WPF, Silverlight or WP7/8) the Android APIs feel ugly at times (gesture handlers for example).
Assuming you are doing Xamarin.Native and not Xamarin.Forms, you can just tab-complete your way through it if you know the native side. The apis are almost 1-to-1, only making things more dotnet-y when it makes sense.
But the "easier development" part is very debatable. What do I see in the browser developer console when debugging a Blazor app? Can I insert breakpoints, trace what is running and how? etc. etc.
I get disliking JavaScript, but there is a strong argument to be made for using the tried and tested technologies that developers have been using for a very long time, rather than shoehorning whole new tech in just because it's in a language you prefer.
The answer to your break point question is yes. You can debug your C# code on the front end with breakpoints. The biggest benefit is applications with a lot of domain business logic tend to have that logic copied to the front end and copied to the backend. If a object can no longer be updated if it has an expired date then you would have logic on your server to prevent that. You would also have logic on your front end to display to the user that this can not happen before even going to the server. The server would act as a backup and ensure it never happens.
With Blazor, this logic only exists in one place which helps follow DRY.Logic that is duplicated tends to get missed in testing often. This provides business value.
The process of developing better tools for more effective software design is not just about making developers feel better.
It's about prodding development teams towards the pit of success, to use a common cliche, instead of the pit of despair. Less mental overhead, less need for expertise in specific flavor-of-the-month frameworks, less churn, easier hiring (you just need to know C#), more reliance on compiler tools to prevent dumb mistakes.
Stuff like that easily make the difference between success and total failure. The business stakes are actually quite high.
Performance is only part of it. Using a single language for the whole stack is very valuable to a lot of people. I think that's why Node gained popularity because many developers were using JS for the frontend so why not use the same language for the backend as well?
Yes, exactly. Xamarin is already a good cross-platform solution for "apps" and so Blazor is hopefully the missing piece for the web. The JS-based cross-platform mobile solutions are just not in the same league as Xamarin, IMO.
I don't have any, no. Benchmarks are going to be relative to what you want to compare though so you will likely have to take them yourself, especially if you are comparing something subjective like UX.
I know Paul Betts lurks around here sometimes (well maybe he used to, it looks like xpaulbettsx no longer exists), I would take his opinion on the two frameworks over anything I come up with.
> JavaScript isn't really that big of a problem or a performance killer. The DOM is.
I'm using QML, which is JS without DOM. JS is absolutely a performance killer. Migrating stuff from JS to C++ in a dumb way (no architectural change) makes things 20x - 200x faster.
I don't doubt C++ is faster than JS, but JS in modern browsers is more than "fast enough" no matter how much faster C++ may be. If you're doing the kind of things most web pages do (render some UI, information and inputs, adjust UI, take responses from those inputs, validate and send) then JS is very, very rarely a bottleneck in performance.
What JS engine does QML use? Because if it's a relatively modern one (V8, JavaScriptCore etc) and you're experiencing huge slowdowns just creating and modifying UI components then I'd seriously question the JS code you're running.
I’ve got to be honest I thought this was the right take but I doubt it now. At least with React. Ive been doing performance on a large app now for months and JS is very often the problem. If you’re re-rendering anything that’s more than a few components wide and a few deep, say 20-40 in total, you’re already over your frame (16ms) budget. To me that’s insane. You can’t render more than 20 components at a time? And this is using a really fast computer. I almost can’t believe it. But often just the logic for a single component that’s a few levels deep takes 4ms. I really do feel that should be about 10x faster but for some reason it isn’t.
No, just using plain QML. Basically, it's a C++ application with application logic written in JS (using a rather bad JIT), and where we went wrong was writing a lot of application logic in JS rather than just writing the UI specific application logic in JS and the remaining part of the application logic in C++. OTOH, we already had huge parts of the system in C++ and the JS access was mainly small data transformations, but even this turned out to be too slow.
It used to be this way back with thick clients(Winforms) and then for a short time Silverlight.
It was a very productive time, not sure if I have have ever been as productive as I was with C# and Winforms. Run code on the client, run it on the server, whatever.
I use Elm and by having a language that puts constraints on what ultimately is executed in JavaScript and manipulations to the DOM, you can manage to write complex programs and have them be relatively efficient in size and operation.
Of course Elm isn't without its problems, too, but I think it may be on the right path for web applications.
The solution is a new CRUD-friendly markup language & standard. Why does JavaScript have to reinvent common and expected GUI idioms that have been around since the late 1980's? That to me seems irrational. Slap the industry and wake them up! We are downloading an entire (buggy & leaky) GUI engine for every app. That kicks D.R.Y. in every organ.
HTML was originally intended for static documents. We have been shoe-horning it to act like a real GUI and faking state, and it's been grunting and groaning under the strain for 2+ decades. Give up already. Make CRUD Normal Again! #MCNA!
it's not about the performance or replacing javascript. It's about being able to program the DOM in the same language you use on the backend, whatever that might be.
Blazor is a game changer in my opinion. C# is a sold language and this project solidifies that.
I really hope this takes off and is practical. Every time I have to touch the mess that is front-end JS development, I want to torch the building and go live in a cave far away from any computers.
Dynamic by default languages are a mistake. Languages where anyone can monkeypatch anything are a mistake. Languages that are so flakey and squishy that the best tooling in the world can't tell you reliably whether a symbol is or is not defined somewhere in scope, and jumping to definition relies on grep, are a mistake.
I don't know if Blazor is the right answer - in particular the server-side version of it, using SignalR to send events and diffs back and forth gives me some chills and flashbacks to ASP.NET WebForms UpdatePanels... - but something better for WebAssembly will come soon, and we can finally be free of the sub-mediocre monopoly that JS has enjoyed.
You can write messy anything. C, C++, C#, I’ve seen tire fires in all three.
Messy code is due to the programmer not the language. The idea that you can magically be a better programmer without spending time on learning and improving because you chose “a superior language” is silly.
Also we should be having this discussion in Latin. English is messy, you can write messy messages in English.
> You can write messy anything. C, C++, C#, I’ve seen tire fires in all three.
Come on, please. Of course you can write a steaming pile of trash in any programming language, but some languages allow you to do that more easily than others.
Comparing languages based on their absolute worst examples isn’t really a comparison at all.
Hm, they all look kind of slow and Telerik's demos were broken on Firefox (the comboboxes wouldn't work). Only matblazor's demos looked responsive enough.
Though they all seem to provide basic controls like checkboxes, sliders, date pickers, etc. Shouldn't those be part of the core Blazor toolkit?
I tried it out for a side project and I loved it. I've written more C# than javascript, but I think that web development is a mess. I've used Angular, Vue, and React, and, to me, they all have the same problems. They're not bad, but they all depend on npm, tons of packages, and stuff like webpack, which I wish I didn't have to understand, but it sometimes breaks my project. I am also opposed to coding a backend in JS.
I tried making a game using blazor. Think something like the Jackbox TV games. A room gets created, then people join, and then play together real time (not a 3d game, something that could be done with html/css). It was surprisingly easy. Lots of things I did that I didn't expect to work did. There was pretty much no boilerplate code. I wasn't creating models on the backend and on the frontend, and then writing an api so that they could communicate. I didn't have to use JSON anywhere.
I haven't finished the game because I started working on something else though, using flutter.
I don't expect people use JS on the backend to convert. Or people who have a ton of experience with something like React. But I think it is awesome. It removes everything I hate about web development. All of the other frameworks for web development that I have used have felt like putting makeup on a pig. Blazor felt like a step in the right direction.
It seems like the support from MS is there for now. You have to be aware of the limitations depending on whether you pick server or client side Blazor. I think the limitations are pretty insignificant for the most part though. I doubt Blazor takes over the web, but I hope that something similar will one day.
The lack of having to write another $.ajax method is what draws me. We write internal use applications and actively avoid any SPA frameworks but like to enhance our applications to provide modal windows, etc. The fact I can do this with none to minimal js will be a game changer. Server side Blazor brings back the WebForms dev cycle without all the magic, postback and view state.
I wish browsers supported these languages natively. It seems like when the html standard was designed they thought about it. I know the script tag has a language attribute.
Well, with the headaches that differences in HTML and CSS interpretation in browser engines already can cause, I would not look forward to having the same kind of problems with compiled languages.
We could, of course, make the thing that compiles and executes the code a shared plugin, but then we would have reinvented ActiveX and Java applets.
> Blazor code executing on the server has the flexibility to do anything you would normally do on the server, such as connecting directly to a database.
Frustrating to see even the splash page off in lalala land.
Write once, deploy no where because surprise, the 3rd party package you were using requires a database connection, or some other server side feature.
This kind of messaging is why Blazor code is a mess; its not a seamless change to run on WASM when its ready, its server side lock-in, making db calls from your code behind file.
..and for anyone who thinks this isn’t webforms back from the dead:
> If you are a Web Forms developer and want to build a new application on .NET Core, we would recommend Blazor which provides the closest programming model. [1]
The sad thing is, the WASM c# end-to-end, using real full dlls in the browser is actually really cool.
So you don't use 3rd party packages? Because the moment you use one you don't fully understand it --that comes with time. You can't magically know every nuance about a package before you start using it. I haven't looked at the code at all for momentjs or the internals of Vue, there's still a lot I don't know about their api's but doesn't mean I still don't get value out of using them.
I went to a meetup focusing on Blazor recently and was really surprised when I found out that Blazor is not "run C# in a browser using WASM" like I thought, but was instead "use your browser as a thin client to C# on the backend". The whole time I was thinking "but why??".
The WASM side of it is really interesting for me as a Xamarin proponent, because it has the potential of true single shared-codebase between mobile and web. I'm not sure why I would use Blazor right now though.
> I went to a meetup focusing on Blazor recently and was really surprised when I found out that Blazor is not "run C# in a browser using WASM" like I thought, but was instead "use your browser as a thin client to C# on the backend
That's not true. It can run client-side on a WebAssembly-based .NET runtime or server-side in ASP.NET core.
I find MS has generally been taking a Manhattan-project style approach these days, trying everything at once and keeping what sticks.
I'm not saying it can't, but the primary focus (and current release) is the server-side version. I didn't realize (before that meetup) that server-side Blazor was even a thing, everything I heard about it before this was that the client-side version _was_ Blazor.
I don't know if thats a disconnect in marketing, or me not paying attention, but like I said I was really confused.
Yeah, a confusing spate of offerings and terminology is just part of working with the Microsoft stack. It took me like 3 years of professional C# development to finally sort it all out.
But the reason they're pushing server-side Blazor is because loading client-side Blazor just takes too long in production deployments. Right now, you have to wait several seconds before the page loads, which is unacceptable for most users. I feel like server-side has to be the future, though, and they'll address the speed issue soon enough.
Re: and for anyone who thinks this isn’t webforms back from the dead
For getting smaller and internal projects done quickly and without stack drama, Web Forms does the job just fine. It's not going to win an art contest, but it's usually quicker, cheaper, and simpler than the alternatives. You wanna pay more for art and fashion? Go ahead!
The team has documented and discussed this several times. They have always recommend using service interfaces or HTTP calls inside your components if you intend on switching to client-side in the future.
Otherwise, for many apps, server-side Blazor works just fine. The component model is like any other frontend framework, not like Webforms at all, and by running server-side gives you a shorter path to the data and backend code you would normally put behind an API interface. This is an incredibly productivity boost.
If you don't need or want it, then don't use it, but it's a major leap forward.
I haven't looked over the samples (but I definitely will!!!). The biggest samples I think _any_ frontend framework need to demonstrate is form validation (showing errors) and file uploading. everything else is pretty simple.
That's only client side blazor. Server side just streams DOM changes (efficiently). Even for client side, the actual amount downloaded is usually pretty small.
74 comments
[ 3.2 ms ] story [ 151 ms ] threadLast significant bit of news from it was the "official preview" phase, back in April.
If I understand it well, it WILL be released soon given that .NET Core 3 has just been released too.
> With this newest Blazor release we’re pleased to announce that Blazor is now in official preview! Blazor is no longer experimental and we are committing to ship it as a supported web UI framework including support for running client-side in the browser on WebAssembly.
The server side version is interesting, it ships DOM updates to the client from the server over a websocket (musch like OOUI https://github.com/praeclarum/Ooui). Not something that I'd use for production, but for quick internal projects which have the feel of a client side SPA, but while not requiring you to build the API layer it's quite neat.
WebForms 2020! Amazing.
Question: how will they go about shrinking them? Will this happen in the near future?
I've tried out Blazor before and the page doesn't load until you've downloaded everything. Will it always be that way, or will it be like JS eventually -- you see the page, and the JS loads in the background?
JavaScript isn't really that big of a problem or a performance killer. The DOM is. I don't know what the answer is (rendering to a canvas tag is awful for accessibility) but I'm hoping that in time we see the improvement that is to the DOM as WebAssembly is to JS.
Hopefully Blazor will avoid such issues. In any case I'm probably speaking out of turn... it clearly isn't designed for wide-scale deployments - in house/intranet tools are a different beast anyway.
I get disliking JavaScript, but there is a strong argument to be made for using the tried and tested technologies that developers have been using for a very long time, rather than shoehorning whole new tech in just because it's in a language you prefer.
With Blazor, this logic only exists in one place which helps follow DRY.Logic that is duplicated tends to get missed in testing often. This provides business value.
It's about prodding development teams towards the pit of success, to use a common cliche, instead of the pit of despair. Less mental overhead, less need for expertise in specific flavor-of-the-month frameworks, less churn, easier hiring (you just need to know C#), more reliance on compiler tools to prevent dumb mistakes.
Stuff like that easily make the difference between success and total failure. The business stakes are actually quite high.
I know Paul Betts lurks around here sometimes (well maybe he used to, it looks like xpaulbettsx no longer exists), I would take his opinion on the two frameworks over anything I come up with.
I'm using QML, which is JS without DOM. JS is absolutely a performance killer. Migrating stuff from JS to C++ in a dumb way (no architectural change) makes things 20x - 200x faster.
What JS engine does QML use? Because if it's a relatively modern one (V8, JavaScriptCore etc) and you're experiencing huge slowdowns just creating and modifying UI components then I'd seriously question the JS code you're running.
I've written more React than most people, and am very intimately familiar with the internals, optimization and more.
With enough effort you can usually mitigate most of it, but I'm going as far as doing static compilation optimizations just to get it to feel good.
https://doc.qt.io/qt-5/qtwebchannel-index.html#
Is it possible to get any benchmarks or comparisons.
If you could use C# on both the front and back end, that would be a game-changer for enterprise shops, and very useful for everyone else too.
It was a very productive time, not sure if I have have ever been as productive as I was with C# and Winforms. Run code on the client, run it on the server, whatever.
Of course Elm isn't without its problems, too, but I think it may be on the right path for web applications.
HTML was originally intended for static documents. We have been shoe-horning it to act like a real GUI and faking state, and it's been grunting and groaning under the strain for 2+ decades. Give up already. Make CRUD Normal Again! #MCNA!
Blazor is a game changer in my opinion. C# is a sold language and this project solidifies that.
Dynamic by default languages are a mistake. Languages where anyone can monkeypatch anything are a mistake. Languages that are so flakey and squishy that the best tooling in the world can't tell you reliably whether a symbol is or is not defined somewhere in scope, and jumping to definition relies on grep, are a mistake.
I don't know if Blazor is the right answer - in particular the server-side version of it, using SignalR to send events and diffs back and forth gives me some chills and flashbacks to ASP.NET WebForms UpdatePanels... - but something better for WebAssembly will come soon, and we can finally be free of the sub-mediocre monopoly that JS has enjoyed.
Have you met TypeScript? http://www.typescriptlang.org/
Messy code is due to the programmer not the language. The idea that you can magically be a better programmer without spending time on learning and improving because you chose “a superior language” is silly.
Also we should be having this discussion in Latin. English is messy, you can write messy messages in English.
Come on, please. Of course you can write a steaming pile of trash in any programming language, but some languages allow you to do that more easily than others.
Comparing languages based on their absolute worst examples isn’t really a comparison at all.
There's some good demos on their sites. The 'official' one could do with an update!
Though they all seem to provide basic controls like checkboxes, sliders, date pickers, etc. Shouldn't those be part of the core Blazor toolkit?
I tried making a game using blazor. Think something like the Jackbox TV games. A room gets created, then people join, and then play together real time (not a 3d game, something that could be done with html/css). It was surprisingly easy. Lots of things I did that I didn't expect to work did. There was pretty much no boilerplate code. I wasn't creating models on the backend and on the frontend, and then writing an api so that they could communicate. I didn't have to use JSON anywhere. I haven't finished the game because I started working on something else though, using flutter.
I don't expect people use JS on the backend to convert. Or people who have a ton of experience with something like React. But I think it is awesome. It removes everything I hate about web development. All of the other frameworks for web development that I have used have felt like putting makeup on a pig. Blazor felt like a step in the right direction.
It seems like the support from MS is there for now. You have to be aware of the limitations depending on whether you pick server or client side Blazor. I think the limitations are pretty insignificant for the most part though. I doubt Blazor takes over the web, but I hope that something similar will one day.
Cheers
We could, of course, make the thing that compiles and executes the code a shared plugin, but then we would have reinvented ActiveX and Java applets.
Frustrating to see even the splash page off in lalala land.
Write once, deploy no where because surprise, the 3rd party package you were using requires a database connection, or some other server side feature.
This kind of messaging is why Blazor code is a mess; its not a seamless change to run on WASM when its ready, its server side lock-in, making db calls from your code behind file.
..and for anyone who thinks this isn’t webforms back from the dead:
> If you are a Web Forms developer and want to build a new application on .NET Core, we would recommend Blazor which provides the closest programming model. [1]
The sad thing is, the WASM c# end-to-end, using real full dlls in the browser is actually really cool.
...but somehow that got lost along the way.
[1] https://devblogs.microsoft.com/dotnet/net-core-is-the-future...
There’s certainly a place for telerik—only UIs I suppose.
/shrug
I suppose I could spend much of my day carefully vetting dependencies... but what about dependencies of dependencies?
The WASM side of it is really interesting for me as a Xamarin proponent, because it has the potential of true single shared-codebase between mobile and web. I'm not sure why I would use Blazor right now though.
That's not true. It can run client-side on a WebAssembly-based .NET runtime or server-side in ASP.NET core.
I find MS has generally been taking a Manhattan-project style approach these days, trying everything at once and keeping what sticks.
https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...
I don't know if thats a disconnect in marketing, or me not paying attention, but like I said I was really confused.
But the reason they're pushing server-side Blazor is because loading client-side Blazor just takes too long in production deployments. Right now, you have to wait several seconds before the page loads, which is unacceptable for most users. I feel like server-side has to be the future, though, and they'll address the speed issue soon enough.
For getting smaller and internal projects done quickly and without stack drama, Web Forms does the job just fine. It's not going to win an art contest, but it's usually quicker, cheaper, and simpler than the alternatives. You wanna pay more for art and fashion? Go ahead!
Otherwise, for many apps, server-side Blazor works just fine. The component model is like any other frontend framework, not like Webforms at all, and by running server-side gives you a shorter path to the data and backend code you would normally put behind an API interface. This is an incredibly productivity boost.
If you don't need or want it, then don't use it, but it's a major leap forward.
https://github.com/dodyg/practical-aspnetcore