Blazor – Build client web apps with C# | Hacker News Reader

Blazor – Build client web apps with C#

dotnet.microsoft.com

75 pointspearjuice73 comments

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.

> Dynamic by default languages are a mistake

Have you met TypeScript? http://www.typescriptlang.org/

Unfortunately, TypeScript is still dynamic by default. You can still write messy JavaScript.

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.

> 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.

...but somehow that got lost along the way.

[1] https://devblogs.microsoft.com/dotnet/net-core-is-the-future...

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!

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.

https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-...

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.

what's the difference between server side and just serving everything on the server and jQuery? sounds very similar

Blazor server-side maintains a websocket to a running client and does some Magic to communicate DOM updates to the client.

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.

Alternatively, don't use third party packages you don't fully understand.

I'm not sure if I could do much of anything as a developer if I didn't use third-party packages I didn't fully understand.

I suppose I could spend much of my day carefully vetting dependencies... but what about dependencies of dependencies?

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 take it you don’t use any 3rd party vue/angular/react components?

There’s certainly a place for telerik—only UIs I suppose.

/shrug

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.

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?

That's what appealed to me. Cross-platform desktop client? Electron/TypeScript. Front-end of a website? TypeScript. Back-end service? Node/TypeScript.

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.

Can you show benchmarcks of an electron app vs xamarin for a same UX?

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 a very good programming language. Just because I can develop in it doesn't mean I want to.

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.

It isn't just about scratching an itch. It results in fewer bugs, faster development, more features etc. which are useful to end users.

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.

That's such nonsensical marketing spin.

I don't see how easier development does not result in better outcomes. Imagine how bad things would be if everyone had to code in Assembly.

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.

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!

The problem with JavaScript is it's a separate programming language.

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 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.

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.

> 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.

You probably need to learn how do either design a better app, or write better react if you’ve got that much of the DOM updating at once.

A computer shouldn't struggle updating 30 smaller components. It's not DOM I'm talking about it's React, so not sure you even understood me.

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.

Just curious are you referring to this?

https://doc.qt.io/qt-5/qtwebchannel-index.html#

Is it possible to get any benchmarks or comparisons.

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.

I scrolled back and forth and even checked the linked github site but... any live demos? There should be a "Live demo" button right at the top.

The official demo that uses wasm is here https://blazor-demo.github.io/

The component vendors are jumping on board as well https://demos.devexpress.com/blazor/ https://www.telerik.com/blazor-ui https://www.syncfusion.com/blazor-components https://www.matblazor.com/

There's some good demos on their sites. The 'official' one could do with an update!

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?

Has anybody used this in anger? It looks cool, but there is that obvious worry about investing the time to learn it, only to have it abandoned by MS.

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.

Lovely, will definitely check it out. I have a similar background to yourself, decent amount of frontend web dev experience but definitely more C#.

Cheers

I wrote over 300 samples for ASP.NET Core, including 80 samples for ASP.NET Core 3 techs.

https://github.com/dodyg/practical-aspnetcore

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.

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.

There was a time that VBScript was the other option there. Oooof.

I like blazor, I can't, however, get over the idea of having to download several megabytes of DLL's to get it to run.

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.

Blazor is definitely not a shiny new technology. It's been around for years but still hasn't seen it's official release.

Last 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.

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.

> The server side version is interesting, it ships DOM updates to the client from the server over a websocket

WebForms 2020! Amazing.

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.

I'd say more like Elm's Pheonix LiveView, to be honest.

Yep, that's pretty much the aim :)

> 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?

April announcement here https://devblogs.microsoft.com/aspnet/blazor-now-in-official....

> 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.

Reminds me of SilverLight.

Silverlight was proprietary tech . Web Assembly is based on Open Standards. This is just a framework to develop for Web Assembly

Silverlight was a client side plugin, like Flash, which needed to be installed separately from the browser.

Reply on news.ycombinator.com