Blazor – A .NET web framework that runs in the browser with WebAssembly | Hacker News Reader

Blazor – A .NET web framework that runs in the browser with WebAssembly

github.com

96 pointstegeek50 comments

https://news.ycombinator.com/item?id=18135949

I've never used .NET, and don't really intend to, but I think this is interesting nonetheless.

This is on track to become a "built-in feature of ASP.NET Core 3.0" – recall that ".NET Core" runs on Linux, etc.

Much C# development is still for internal business applications. For these applications, the overhead of shipping the .NET runtime to the browser in WASM - which https://blazor.net/ sadly does not seem to mention - may not be a big deal, especially if they can be cached with service workers.

Keeping engineers fungible and cheap to hire & train is a priority for enterprise software divisions. Software ecosystems that rely on the patience and curiosity of developers to explore an uncoordinated constellation of packages and design their own architecture (eg; Java, React ecosystems) can be suboptimal.

.NET's historical "all batteries included, all applications the same" promise has been key here. But for rich frontends, Angular (their current choice) has, ah, high training costs.

If Blazor works well, .NET Core may become the first truly full-stack, integrated, get-it-all-here, framework for modern web app development.

As an uninvested bystander to enterprise software development, I'm curious to see how this goes.

Why is .NET valid only for enterprise applications?

Sorry, I didn't mean to imply that it is. .NET, and C#/F# generally, can be useful in a tremendous variety of applications, and especially outside of the SF bubble, are used for... everything, startups included.

.NET's most common use case, based on my research, is enterprise applications, but certainly not its only.

Thanks for calling this out.

Exploring a bit, and sharing for those with similar curiosity...

This seems to have a React-ish architecture with familiar C# templating (Razor):

Razor syntax is the JSX-equivalent, which has been used for C# templating for years: https://docs.microsoft.com/en-us/aspnet/core/mvc/views/razor...

Blazor Components: https://blazor.net/docs/components/index.html

Their docs are pretty scattered, especially for someone coming from React, but it seems to have similar features and lifecycle methods, albeit a bit more ersatz.

    onClick => onclick (etc)
    componentDidMount => OnInit / OnInitAsync
    componentWillReceiveProps => OnParametersSet[Async]
    componentDidUpdate => OnAfterRender[Async] 
    shouldComponentUpdate => ShouldRender
    componentWillUnmount => Dispose

There is also a convenient `bind` which is shorthand for `value="@Foo" onChange="@(e => Foo = e.target.value)"` and a magical `<FooComponent bind-Foo="@ParentFoo">` for passing state down...

You don't seem to be able to define multiple components in a single file (which in my experience leads to bloated components).

Routing seems to be defined within the .cshtml file rather than centrally, which can get messy in my experience.

I don't see anything to support state that is shared across far-flung leafs of a deep UI tree (eg; Redux, Context), but maybe there are standard .NET constructs for that which I'm not aware of.

I don't think this is going to win anyone from the React world – some design choices seem not to grok some key insights of React – but I can imagine it taking off amongst folks who were happy with server-side Razor templating and have been unhappy with Angular.

> Angular (their current choice) has, ah, high training costs

Does it? You need to know typescript (which you arguably should be using regardless of frontend framework) and what dependency injection, observables and components are. Plus some syntax for the templating language, which is fairly intuitive. That’s enough to get you going, I don’t see it as being much more of an investment than learning a react stack.

It also has the benefit of being all in one, like .NET, so there aren’t multiple different packages for every function that could be used, depending on who your team is. That all in one factor is probably why it’s a natural complement to .NET.

I think you answered your own question when you mentioned Angular being an "all in one".

Angular needs a bit more training because you are heavily encouraged to do things the "Angular" way which requires a lot of abstraction and componentization.

I was more referring to the essentially mandatory third party packages that you need with react, react router, redux/whatever you please, something for your styles, something for forms etc. With angular you just use what comes out of the box, but either way you have to learn whatever the thing is so the effort seems to be the same. Not sure what you mean about abstraction and componentisation vs other frameworks.

Angular likes when you structure your application a certain way.

You try and tweak how you want to break up a component and the house of cards starts to fall over.

I feel house of cards is a very good metaphor for the whole angular ecosystem.

Unsubstantive. Care to share your thoughts?

I agree, the versioning has been a mess and they're constantly breaking changes to the API. Just trying to update a project is like trying to change playing cards in a house of cards...

Does it? You need to know typescript (which you arguably should be using regardless of frontend framework)

That's highly debatable. We moved back to ES after using Typescript for years and couldn't be happier. We're much more productive than we were with Typescript, and that's with people that know the language. We get much of the benefits of Typescript by just using a jsconfig.json file in our project and using VSCode. The Typescript language service will typecheck JS code if you want it to.

And there is a big upfront cost for onboarding developers with Typescript and Angular.

This is interesting, I'm mostly hearing the opposite experience. What made you decide to make the switch back?

It’s not faster, but it does improve code quality. I also don’t think it’s that hard to learn, but I’m coming from a strongly typed, object orientated background. Like the sibling commenter I’d also be interested in hearing your team’s experiences with it.

> That all in one factor is probably why it’s a natural complement to .NET.

Very much agreed. And I also agree that, at least in a corporate context, training for a React stack would also be expensive, potentially more so.

And there are plenty of people out there who have no problem picking up Angular.

Looking at job market data alone, though, Angular commands a premium to .NET-only. Anecdotally, folks who feel comfortable with .NET, but who find eg; React+Redux bewildering, also feel constantly confused by Angular and can get themselves into trouble without close guidance.

> Anecdotally, folks who feel comfortable with .NET, but who find eg; React+Redux bewildering, also feel constantly confused by Angular and can get themselves into trouble without close guidance.

Makes sense, the modern frontend frameworks are pretty similar anyway, despite the amount of noise about their differences. If you find react hard you’ll probably find angular hard and vice versa.

Ah, an update re; bundle size:

> Early Blazor prototypes used a compact .NET runtime (including assembly execution, garbage collection, threading) that compiled to a mere 60KB of WebAssembly. Blazor now runs on Mono, which is currently significantly larger. However, opportunities for size optimization abound, including merging and trimming the runtime and application binaries. Other potential download size mitigations include caching and using a CDN.

web2py was “the first truly full-stack, integrated, get-it-all-here, framework for modern web app development” years ago and still thrives.

I'll throw in my two cents on top of this:

* SPAs: Microsoft has a vested interested in porting a lot of code to SPA applications. Teams being the latest example.

* Windows is dead, long live Windows: A desire for a lighter version of Windows in the near future running on ARM and you suddenly have existing dev tools and code moving to a Chrome OS like environment with little fuss.

* Edge: Is jumping over to chromium and wishes to support existing chrome extensions. What blazor may also allow are some pretty sophisticated download-once applications also coming through that 'store(?' with first class support.

* Linux Love: If linux is the rural America of 2016 then MS is Trump. OSX and Google seem to be locking people in and MS is trying to give more choices.

* Windows is Dead, part 2: Can't stress this one enough. Giving enterprise developers and teams a way out of the legacy sandbox seems to be key.

tl;dr - Re-cut the Star Wars scene of 'Luke I am your father' to Nadella and myself. Change the response to 'Yesssssssss! <hug>'

I feel like I've been licking toads recently. So much crazy going on.

> Keeping engineers fungible and cheap to hire & train is a priority for enterprise software divisions. Software ecosystems that rely on the patience and curiosity of developers to explore an uncoordinated constellation of packages and design their own architecture (eg; Java, React ecosystems) can be suboptimal.

I can't help but feel this is a cleverly worded put down of Enterprise software developers. Having worked on both sides of fence, there are significantly differences but it mostly comes down to the type of end product rather than whether developers are "fungible and cheap".

For example, at the company I work for now we develop at least 12 different fully deployed products year. When I worked for a startup, we developed a single product over 5-10 years. Most modern frameworks are definitely geared more to the latter than the former.

Blazer is definitely not geared for the single highly optimized application. But I could definitely see using it to get much better results for our internal applications with much less effort. We could probably absorb the run-time cost.

Shipping the runtime as a compressed file is only a few hundred kilobytes right now, which is smaller than many JS payloads. That's before any optimizations which are far easier to do in statically compiled languages and binary files like WASM. I expect the overall payload size to be far lower than an equivalent app in React.

The current JS frontend frameworks are great but they all require a tremendous amount of work to get going for any complex application. The tooling, build chains, libraries, boilerplate code and general verbosity of JS really needs a cleanup and Blazor is incredibly attractive in that regard.

In Blazor, what is sent to the browser is a .NET runtime, then the .net assemblies (which are .NET CIL, not wasm) which the runtime executes. They seem to have this working well, but it's less efficient than, for example, Rust which has no runtime and compiles directly to wasm. C# is very much my goto language, but my eye is currently on Rust in this space because the scenarios where I feel the need for something other than Javascript in the browser are all performance related - i.e. I find React / JSX great for working with the DOM.

I'm wondering that if WebAssembly could "cache" these runtimes, so you only have to download once?

I can see Blazor being really useful for back office systems where people are in them for hours, not so much customer facing stuff which people are dropping in and out of.

I think anything that can challenge JS (which tbh is looking increasingly more like C# with every new release) on the front end side can only be a good thing though.

I am a huge fan of C# and it’s bern my go to language for over a decade, but at this point in my career, I am not tying my horse to anything MS. MS just doesn’t seem to be gaining the mindshare with green field initiatives or smaller companies that are focused on all things JavaScript. On the other end, large enterprises are still more tied to Java than C#. Yes that makes me sad.

The only thing that Microsoft is doing that’s getting any real traction is Azure. Don’t get me wrong, I’m not abandoning C# and there is no way that I am going Java, but I am focusing more on Jsvascript and Node.

.Net Developer here and I've never been unable to find good paying jobs or expand my career in interesting directions.

JavaScript is a good goal... but not because there's a lack of C# viability.

I am too and I have also being able to find good paying jobs.

But back in 2008 there were also good paying jobs for good C and C++ developers. But when I looked at the direction that the local industry was going, I could see that the age of the bit twiddler was dying locally and there were more jobs for “enterprise developers”.

I had a choice between making $20K more as a senior C++ developer or $7K more as a mid level C# developer. I took the latter even though I had 12 years (staying at one company way too long) of development experience.

So that’s what I concentrated on for the next 9 years - the Microsoft stack.

Late last year, I was the dev lead for a decent size company with a small IT department. I was looking to change jobs and once again I saw the writing on the wall. There were a few jobs willing to pay what I wanted writing C# but lots of companies wanted Node/React/React Native.

This time, once again I was offered $15K more as an architect leading a team of 10+ developers writing apps in C# on Windows servers, running Sql server and I had another job offer as a “senior developer” at a smaller company making only $5K more but would get a chance to not only fill in some technical gaps on my end - front end coding with React and back end with Node. I would also get to lead initiatives to make the company more “cloud native” and to restructure the architecture for high availability, scalability, etc. and help build a dev ops culture. But with no official reports (that’s a good thing).

Looking ahead three years, I knew what the better choice would be for my career. Sure there is money now for C# developers but that’s not where the market is going.

But honestly, the salaries for developers and even architects who want to stay mostly hands on and don’t want to go into management outside of Silicon Valley/NYC is stagnating. I realized from my last job that the real money is working for consulting companies with titles like “Implementation architects” and “Digital transformation consultants” who help companies move to the “fourth level of the cloud maturity model”. Yes typing that left a bad taste in my mouth.

So that’s really the game plan - but to speak to all levels of the organization, I need a “more modern tech stack” as one of the recruiters told me.

> Looking ahead three years, I knew what the better choice would be for my career. Sure there is money now for C# developers but that’s not where the market is going.

My decision is real simple... Microsoft has one thing most of those stacks don't: Longevity.

You can knock C# as being "old" and not as "shiny" as Node/React/React Native/Angular/etc... but C# has been stable for a long time and it isn't going anywhere.

I can't say the same for JavaScript.

> Yes typing that left a bad taste

I don't know if that would change with C#, C++ or JavaScript - you are bound to hit a ceiling as a "developer" unless you move into engineering/architecture/management/bullshit (but I repeat myself)

> need a more modern tech stack

I'm learning JavaScript alongside C# (but I'm definitely a .Net Developer) for that reason.

I personally have less faith that those techs will be as predominant in 20 years though... I think it's a crapshoot all around - things are different from 5 years ago and C# and JavaScript will be COBOL in 20 years - alive but not really...

We'll be working in mines for our robot overlords who can program themselves at that point.

But seriously... I have more faith that Microsoft will be consistent and supportive of technology than Google or Apple - Google has dropped more technology than anyone and Apple is still a 1 trick pony. Facebook is pissing people off and companies like Amazon are like Blackberry and Palm - even the giants die eventually.

Not sure if that makes sense... but rambling aside, you can pick a channel - C#, Java, JavaScript, etc - and have a successful career as long as you are able to learn the bigger picture and move if/when the writing is on the wall.

My decision is real simple... Microsoft has one thing most of those stacks don't: Longevity. You can knock C# as being "old" and not as "shiny" as Node/React/ReactNative/Angular/etc... but C# has been stable for a long time and it isn't going anywhere.

JavaScript has been around longer than C#.

But if you want to compare how long framework of the week has been around, Microsoft frameworks have been anything but stable - Linq2Sql, Webforms, WCF, Windows Forms have all but been abandoned and the .Net Core versions of WebApi, MVC, and EF are mostly different from their older versions.

But seriously... I have more faith that Microsoft will be consistent and supportive of technology than Google or Apple

There is this story of VB6 and Classic ASP...

And all of the abandoned mobile efforts. MS abandoned Windows CE/Windows Mobile in 2008 when there were still millions of devices running specialized vertical market apps using it.

I don't know if that would change with C#, C++ or JavaScript - you are bound to hit a ceiling as a "developer" unless you move into engineering/architecture/management/bullshit (but I repeat myself)

Well, 10 years later, I can’t find any C/C+* jobs in my local market making $60K+ more what I was making back then. Honestly there aren’t too many C# jobs that are making 60K+ what I was making back then in my local market. I was able to negotiate a slightly higher than median salary because of my architect/Devops/AWS skills. There were plenty of jobs for the JS/Node/React/Docker skillset making what I make now - but I wasn’t qualified for them.

The ceiling for .Net developers is lower than that of the Javascript $cool_kids_stack.

But yes, it’s all about knowing where to jump on and off the hype cycle.

The larger companies where C# is more popular aren’t as willing to throw money at developers and honestly they don’t have to. C# developers are a dime a dozen.

The idea of caching WebAssembly is touched upon in this article: https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu... (see "Streaming compilation" and "Implicit HTTP caching")

Caching is also a helpful idea beyond the size of the initial download. Future compilers (cranelift), will have time to make multiple optimization passes on the instructions and save them for later.

I think it wouldn’t even need to be a wasm task to cache these things. If the runtime is downloaded as a separate module, the browsers http cache should already do the job.

What wasm might be able to do in addition is having a carved version of loaded runtime available in order to reduce startup times.

The .NET and web development community both seem to have an obsession with adding abstractions, so it is not surprising to see such layering. In general it seems the vast majority of the web apps I've been forced to use are either slow, huge, or both, and I'm not convinced that should be the way it is.

Edit: wow, downvotes. Not that I really care, but it shows the "stick the head in the sand and don't care about bloat, ignore everyone complaining" mentality that pervades the community...

I didn’t downvote you, but I believe the response is that this isn’t so much the framework’s fault as the developer’s. There’s no reason that you must have a slow, huge web app regardless of what you use.

That said, I do see current frontend technology being replaced by something in a few years, probably wasm.

> downvotes. ... ignore everyone complaining" mentality

Echo chambers downvote anyone who points out the echo chamber behavior.

You're considering your personal experience to be a fact of the entire .NET and webdev community, so is it surprising that people disagree?

I've used and built many fast and lightweight webapps using .NET and other frameworks. Like most things, the tech has little to do with it.

They are working on making .NET compile to wasm. There is still the GC, but it’sess overhead. Presumably this could be used for Blazor or something like it.

https://github.com/dotnet/corert/blob/master/Documentation/h...

I think Blazor might have a bright future in the Electron space. Its seems to me the stars are all aligning from that point-of-view.

Microsoft have had great success with Visual Studio Code and are now the custodians of Electron since they brought Github this year. Also, now that Microsoft are going all in on Chromium for Windows (and dropping Edge in the process) I wonder if they will introduce Blazor into Electron for better cross platform applications.

I just get the feeling there is a play there (in some fashion)

Not so much electron than PWA, which will effectively standardise, cross platform, client apps. To me pwa+wasm is the solution to enable cross platform client apps AND a variety of languages and frameworks. And to free users (or rather developpers) from the various gated stores.

What's the current state of this? Being able to develop with C# in the browser would be a dream, but the last I checked it wasn't really ready for any kind of serious use.

It still carries huge "don't use for production" warnings, and only parts of it are slated for stabilizing in Dotnet Core 3.0. That said, it's fairly usable today, and I think there's enough interest in it that I'd be really surprised to see them abandon it at this point. I think it's worth considering for a personal project or something internal where you are going to do the back end in C# anyway.

It's still in alpha stage but Blazor is one of the most exciting new developments and has seen tremendous feedback from the community so it's developing rapidly.

The component model (Razor Components) for the UI is already committed to ship in .NET 3.0 so it can be used in server-side views, but the client-side WASM framework doesn't have a release date yet.

.NET on WebAssembly could be a really interesting escape hatch for companies that have heavily invested in .NET apps and want to move away from Windows. Right now downloading the whole framework is a prohibitively large task, but for internal apps it would probably be fine. Port something WinForms-ish over as well and those apps could be cross platform with not much work.

Wouldn't .net core just be that escape hatch?

Are you talking about cross-platform desktop apps? This has been an unsolved problem for a long time with many attempts, with Electron running web stacks getting the farthest at this point.

Blazor is interesting in that respect but you can already use Electron today with JS and .NET Core powering the backend.

Any decent examples of this doing something?

Here are some Blazor demos. https://blazor.net/community.html#samples-and-tutorials

I feel like https://blazor.net might be a better url for this post.

How big is this?

I think one can use WebAssembly by itself just fine. In fact, I know this to be true.

Reply on news.ycombinator.com