
Blazor, a framework for browser-based .NET apps using WebAssembly [video] - quickthrower2
https://www.youtube.com/watch?v=JU-6pAxqAa4
======
quickthrower2
This framework is still fledgling, however it is very exciting for a .NET
developer, not because it's a shiny new thing to learn, but because it's the
opposite ... it's allowing you to reuse existing skills to code for the web,
while seemingly allowing you to create a React-like architecture of components
/ state. All using a decent language C#. This is simplifying things if you are
already doing a full stack and working half the time with JS/TS and the other
half with C#.

I hope MS really get behind this and see it through to a production ready
version.

~~~
xab9
Whenever Microsoft tried to do web frontend it was "not really good" (it was
borderline catastrophic). Asp spaghetti, aspx components, viewstate handling,
razor templates etc.

When I worked with .net guys (which happened quite often) 9 out of 10 had been
like wow, I don't have to touch frontend, because MS will solve that for me
"somehow", plus the frontend is messy and crap and javascript is a terrible
language and C# rocks (but F# even rocks more) and I'm not going to learn all
this sillyness (because I want to reuse my skills).

At least with new-angular they feel a bit better and they can praise
typescript, because typescript is "just like C#". Let's just hope noone pulls
an angular-one-to-two style rewrite/clusterfuck...

~~~
pjmlp
I have been jumping between native and web development, alongside backend
since the late 90's.

I will take any server side rendering framework, with some sprinkle of
JavaScript, over any SPA framework.

A node_modules directory with several thousand packages just for a basic CRUD
app, really?

~~~
dustingetz
which yields better outcomes: organic growth (open source) or central planning
(microsoft)?

~~~
pjmlp
Central planning for sure, given the lack of UI/UX focus we usually see on
open source stacks.

Coding is fun, but providing a productive experience also requires doing lots
of stuff that FOSS coders don't invest any resources into it.

------
caleblloyd
Also
[https://www.youtube.com/watch?v=61qmX5eAPwI](https://www.youtube.com/watch?v=61qmX5eAPwI)
which is a newer video and highlights some of the most recent Blazor 0.6
features.

I am very excited about the possibilities this brings. Current
frontend/backend solutions all seem to involve duplicating contracts in
JavaScript. WebAssembly frameworks like Blazor will let us get back to
programming in one language but keep the SPA-style experience for the UI.

------
dang
Some recentish posts:

[https://news.ycombinator.com/item?id=16651709](https://news.ycombinator.com/item?id=16651709)

[https://news.ycombinator.com/item?id=16318076](https://news.ycombinator.com/item?id=16318076)

[https://news.ycombinator.com/item?id=14697520](https://news.ycombinator.com/item?id=14697520)

------
paxys
I am desperately waiting for Blazor to graduate from the "experimental" label
so I can justify investing more time into it, but whatever little I have seen
so far seems amazing. For someone who used to live and breathe C#, ASP.NET and
Razor, this feels like a godsend.

------
aogaili
GWT all over again..they tried to kill JS with Java and failed..good luck with
C#...

~~~
Kyro38
WebAssembly has different objectives than Java and is backed by the 4 major
Browsers.

~~~
aogaili
I'm not criticizing WebAssembly but the selling points behind the framework
which is a use case for WebAssembly.

GWT users cared less about how it was compiling, and at the end of the day,
they were building webapps using Java and Eclipse IDE along with the rest of
the ecosystem. Which is exactly the selling points being presented here.

For me this is history repeating itself.

~~~
k__
Yes, lets see how big the runtime is and how "much" server is needed for
interaction in the end...

------
wokwokwok
There's a problem with Blazor, and that is that its not ready.

Which is why they're shipping _server side_ Blazor [0], which is all the
stupid parts of Blazor with none of the benefits.

Don't get me wrong, the idea of running .Net in WASM is very appealing to
me... but server side Blazor is a daft idea, and it's a mistake.

Here's the model:

\- Your component view state is rendered on the server.

\- A delta is sent to the front-end.

\- The frontend updates the DOM in the browser.

\- Any DOM event is sent to the server.

\- repeat.

Seems ok?

However, the problems here to understand are:

1) Every UI interaction, from mouse focus, to mouse drag, to click to button
down, is sent down the wire to the server to be processed. For high latency
situations, this will feel terrible.

2) Every client shares the same server cluster. As such, it scales badly; your
application may perform well with 10 users, but for 100 users, you have 10x as
much server work happening. Not business logic... UI logic. Will it scale? No
one knows, but the money is on 'no'. The server scale-out demands will scale
with people viewing the website; effectively this means the UI will lag out
under load when the server is busy, the exact opposite of modern SPA
applications and apps that remain superficially responsive under server load,
and compounding issues generated from (1).

3) As many of the examples show, server side Blazor shows how you can execute
arbitrary code on the server as part of your components (eg. fetch DB
records). However, no vague consideration has been given to the authentication
model for this. In fact, the stated high level goal is that razor components
will 'with one click' work seamlessly on both WASM-mono and razor-components;
ie. They are are naive of user roles and permission groups on the server, and
expect to interact with an arbitrary backend 'service' with its own permission
roles. (But that _isnt_ what the examples show).

These are not trivial problems, they are, unfortunately, _insurmountable_
architectural issues with server-side Blazor.

...and the work around is a compromise. ie. You use javascript.

Which... kind of makes it rather pointless.

This is being shipped early for business reasons, not technical reasons.

They should just wait for the WASM target to be ready; this will be a
disaster, in my opinion.

[0] -
[https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...](https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-6-0-experimental-
release-now-available/)

~~~
martijn_himself
This is quite enlightening in that I'm very excited by the prospect of using
C# in the browser without the downsides that came with Silverlight, but
especially 1) seems to be a big negative! (I'm not sure I completely
understand 2) and 3), does 2) only apply to server-side Blazor? Is 3) not
inherent to all web development in that authentication on the client is
'disconnected' from users/ permissions on the server anyway?).

As someone who is trying to wrap his head around all this, did they go with
server side Blazor because browsers do not support all required WASM features
yet? What is even the point of server side rendering?

~~~
judah
Yes, 2 only applies to server-side Blazor.

"Server-side Blazor" itself will be renamed[0] to Razor Components so as to
disambiguate it with WASM-in-the-browser, which will still be called Blazor.

Razor Components seems to be a blend of different kinds of web programming
models, as described by the parent poster:

\- Traditional: POST + Redirect + GET

\- Single Page App: Thick client in JS

\- Razor Components: Traditional, but instead of POST+Redirect, it uses Web
Sockets to asynchronously update state.

Razor Components are being shipped because it's building off well-known,
mature technologies. OTOH, Blazor (WASM in browser) is still baking. For
example, there is no tree-shaking to minimize the minimize the size of
components needed to run your Blazor app. (IIRC, the average size of a basic
nav app is ~2MB.)

[0]:
[https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...](https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-6-0-experimental-
release-now-available/)

------
sebringj
This is a theme in that all major compiled languages will have an ability to
publish to wasm as WebAssembly is a standard that allows this and we'll see
more frameworks like this coming up for various ones. It will be nice for all
the specific language camps and allow interoperability as well between them.
Big win in general whatever you think of .NET but that's not the big picture.

------
jarcane
I look forward to me getting very excited to try this with F#, only to find it
requires a pile of hand-spun hacks only comprehensible to the most dyed-in-
the-wool Visual Studio user, half-documented scraps of git repos that will
only to get working, and will inevitably break completely upon the slightest
update or change to your .NET installation.

~~~
s369610
I suggest you check out fable if you haven't already, v2 just dropped the
experience was pretty smooth ([http://fable.io/](http://fable.io/))

------
saary
Would like to see a wrapper generator around C# libraries so they could be
easily be loaded into node.js

That would make all sort of integrations between legacy systems with existing
C# support libraries and newer lighter node.js projects work without jumping
through crazy marshaling hoops.

Seems like a very interesting direction, embedding managed languages into JS.

~~~
jbigelow76
Do you mean something like edge.js?

[https://github.com/tjanczuk/edge](https://github.com/tjanczuk/edge)

------
kodablah
Didn't watch the video, but since the project doesn't make it clear, this is
the Mono .Net interpreter compiled to WASM that is interpreting IL at runtime.
The AOT .Net-to-WASM compiler is not a thing yet but is actively being worked
on.

------
euroclydon
I'm not a big Blazor fan, but mono-wasm is cool, and if the Blazor folks would
isolate their DOM/JS interop, that would be a good, lightweight starting point
for folks to play around with .NET in the browser.

------
myl
Very, very exciting! Expecially after the download size is reduced (as
planned).

------
plasma
I worry this is close to Web Forms again.

~~~
m_fayer
This is inspired by Vue/Angular. If you're familiar with those and dig into
the docs you'll see that it's conceptually very similar. Nothing like Web
Forms.

~~~
aikah
.

~~~
cm2187
No a server is not mandatory to run blazor. You can run blazor server side,
where the client is routing all events to a server. But that's not the way it
is designed to work by default. By default everything runs client side, you
could run it from a static website.

------
maccio92
This is really great! Excited to give it a try

------
jimmy1
I really don't see how C# is decent anymore, can someone change my mind? I was
all about it in the 2010-2013 days, but over time it just became more bloated
and bloated. It's the new C++, where it tries to be everything for everyone.

Every time a new version comes out theres a 500 page tome of all the new
features added. Did we really need all those features? I would love it if I
saw a new version of a language come out and it _removes_ language features,
wouldn't that be a change!

It still has all the annoyances of java (the first thing you see in any C#
file is a laundry list of imports), I am not convinced the profiling tooling
is better. I will preface this with I am still bitter about the initial .NET
core rollout which was a crapshoot and had no parity whatsoever with .NET
Framework.

~~~
alelefant
You are obviously free to dislike C#, but it seems silly to say they should
stop adding features or should remove features.

> Did we really need all those features?

If you don't need them, don't use them. I've found the new features to be
great. nameof, string interpolation, property initializers, exception filters,
static imports, null propagator. And if you haven't used the language in
awhile going back to 5.0 the async await features are fantastic. 7.1
introduced async Main which we've started using in console apps. I use all of
these features every day.

> I would love it if I saw a new version of a language come out and it removes
> language features

Why, exactly?

~~~
bryanrasmussen
1\. Some people dislike languages with a large instruction set

2\. I will propose that programming languages are like anything else created
by humans - some parts great, some parts not that great. Furthermore some
parts of a language are used more than other parts, it should be hoped that
the parts least used in any particular language are parts of that language
that are not that great. Given these things it might be reasonable that some
time you saw a new version of a language in which they said Feature X really
sort of didn't make sense and anyway hardly anyone ever used it so we are
removing Feature X. Adjust code accordingly. (probably there should be
deprecation stage of a year or so with warnings)

~~~
pjmlp
Even human languages aren't not fully used.

There are multiple levels of understanding, regionalisms and specialized
technical terms that few get to use.

~~~
jimmy1
And that works in language -- its terrible when you are trying to make
computers do very specific things in specific scenarios. It leads to hiring
nightmares as well. "Oh I write language X in _this_ style, not familiar with
_your_ style"

------
userbinator
Yay, now all the bloat of .NET can spread into the browser too! </s>

Seriously, I'm saddened to see all this overwhelming hype and "excitement"
\--- I am a developer myself, and just don't get it: I have used .NET apps
before, and I could immediately tell it was such just from the speed (or lack
thereof) and memory consumption --- the difference is obvious. It's the same
with Java, which is not at all surprising. The absurd amount of object-
oriented obfuscation I encountered in the few times I had to debug someone
else's code in C# probably contributes to that too.

Taking over a second just to load an extremely simple app from _localhost_ in
the demo says all I need to know about this --- "no thanks". Please consider
your users' experience...

~~~
m_fayer
I was going to reflexively downvote this but it doesn't quite rise to the
level of bad faith that I look for before I downvote.

But, I'd ask you to recheck your impressions every couple of years, especially
if a technology seems to be gaining popularity as opposed to dying. Stubborn
and irrational corporate loyalty and manufactured hype are not the only
reasons a technology stays alive, quality does play a role sometimes.

.NET these days, especially with core, has a focus on power, performance,
portability, and a sleek user experience. C# is a widely loved language that
has a plethora of good stable tooling around it, and an intelligently evolving
featureset that enables terse, expressive, functional-if-you-want-it coding. I
think, like Kotlin, it's very well suited to writing "functional core,
imperative shell" apps. You can also use it to write bloated J2EE-style
lasagna-code, but no one's forcing you to do that.

As for Blazor itself, it's similar to React/Vue/etc., but in C#. Writing
complex frontend apps is hard even with TS and the big frameworks, and I can't
think of why a new entrant with a statically typed language (with types at
runtime!) that's still web-native would be a bad thing. As for startup time,
hopefully they'll improve that, but you wouldn't use Blazor for a simple app
anyway.

~~~
userbinator
_But, I 'd ask you to recheck your impressions every couple of years_

My most recent experience with a .NET application was within a day, and my
impression has not changed since the beginning. (Although hardware has gotten
faster...) Essentially every time I've had to use an annoyingly sluggish app
that looks like a native one, I later discovered it was written in .NET .
Despite all the claims of performance I have not once encountered an app that
reflected those. It's never been "wow, .NET is so fast now?" but always "why
is this so slow? ...oh, it's .NET."

 _You can also use it to write bloated J2EE-style lasagna-code, but no one 's
forcing you to do that._

That's the same non-argument the Java folks give. In theory it's possible to
do better, but the language and culture naturally tends toward overengineering
monstrosities because it is so much easier to do so when the language makes
complexity easy to create.

...which brings me to the point I'm trying to make: your users don't care what
fancy language or framework or whatever else you used. They care about the
speed and (implicitly, since it affects speed) resource usage of your
application, and that's what they'll notice.

