
Blazor – Build client web apps with C# - pearjuice
https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
======
thrower123
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.

~~~
benbristow
> Dynamic by default languages are a mistake

Have you met TypeScript?
[http://www.typescriptlang.org/](http://www.typescriptlang.org/)

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

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

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

------
wokwokwok
> 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...](https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-
net/)

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

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

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

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

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

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

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

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

~~~
giulianob
The official demo that uses wasm is here [https://blazor-
demo.github.io/](https://blazor-demo.github.io/)

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

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

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

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

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

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

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

[https://github.com/dodyg/practical-
aspnetcore](https://github.com/dodyg/practical-aspnetcore)

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

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

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

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

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

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

~~~
perfectphase
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](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.

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

WebForms 2020! Amazing.

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

------
Lapsa
Reminds me of SilverLight.

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

