Using WebAssembly from .NET with Wasmtime

https://hacks.mozilla.org/2019/12/using-webassembly-from-dotnet-with-wasmtime/

by skellertor • 7 years ago

246 62 7 years ago

hacks.mozilla.org

cryptozeus2• 7 years ago

MS also have their own take on WebAssembly

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

resoluteteeth• 7 years ago

That's something different. Blazor compiles c# to webassembly to run in the browser.

This software (Wasmtime) allows you to run webassembly code from within .net.

giancarlostoro3• 7 years ago

So in theory you could run Blazor on Wasmtime?

recursive• 7 years ago

Blazor compiles c# to webassembly to run in the browser.

Last time I looked, blazor compiles c# to MSIL just like normal, but also provides a wasm runtime for MSIL.

DougWebb• 7 years ago

Actually, Blazor is a compilation of the C# runtime (CLR) to webassembly, and a mechanism for downloading standard C# dll assemblies to the browser to execute there. The C# code is compiled normally; it doesn't know/care that the CLR is running in a browser rather than on a Windows desktop.

cryptozeus2• 7 years ago

Yeh I meant Blazor is also another option if going with .net platform

jcmontx2• 7 years ago

I know MSFT technologies get a lot of hate here, but ASP.NET Core is pretty awesome. Blazor (the wasm based framework) is innovative and a positive step forward frontend web development.

You should leave your prejudices aside and give it a try if you haven't yet.

sergiotapia• 7 years ago

dotnet core is an insanely good sell for any company. seriously take a look at what you can do and forget what you knew about .net of the 2010s.

kirse• 7 years ago

I really like the approach of Blazor wrt WASM, but really dislike having to dump whole code blocks into CSHTML files like I'm writing old ASP.NET Forms again. Something just feels off.

Is there any way to isolate those code blocks and import them?

EDIT: To answer my own question, this appears to be the solution:

https://www.telerik.com/blogs/using-a-code-behind-approach-t...

pjmlp3• 7 years ago

Well there is Blazor components, unless you mean something else.

SigmundA• 7 years ago

Blazor supports components: https://docs.microsoft.com/en-us/aspnet/core/blazor/componen...

angrysaki• 7 years ago

ASP.NET Core 3.1 added support for partial classes for Razor Components, so I don't think you need to use the inheritance style code behind anymore.

https://gunnarpeipman.com/blazor-partial-page-class/

bob10294• 7 years ago

This is something that hosed me up too at first when using Blazor. There is a specific item type in the VS "Add New Item" dialog that is called "Razor Component" with a fancy purple icon next to it.

If your files in the solution explorer end in .razor, you are using the correct item type. If your files end in .cshtml, you are going to have a bad time and everything will seem very wrong. At first, I was using the "Add->Razor Page" context menu option assuming this was what I wanted, but it will give you the wrong type of item.

manigandham2• 7 years ago

The latest release (.Net 3.1) finished the partial classes implementation so now you can create a `Comp.razor` template file and a separate `Comp.razor.cs` code-behind file that only contains the code. These are automatically compiled together on build.

loudmax• 7 years ago

I know MSFT technologies get a lot of hate here

Are you reading the same HN as I do? In the last couple of years, I see a lot more positive than negative comments whenever Microsoft comes up. From what I see, Google is the company that gets the most hate on HN.

Of course, Microsoft isn't universally loved. There are a lot of people that don't trust them based on their past behavior, and the fact that Windows and Microsoft Office are still an entrenched monopoly. That might not apply to ASP.NET Core, but not everyone is going to let MSFT off the hook.

saagarjha2• 7 years ago

Interestingly, I ran some very rough sentiment analysis of the comments here and it turns out that Apple gets people the most worked up, followed closely by Facebook. Of Apple, Google, Microsoft, Amazon, and Facebook, posts about Microsoft did seem to have the most positive comments.

keithnz• 7 years ago

I've noticed for the new things MS introduce, especially open source stuff, there is a lot more love thrown around.

However, if MS does something that could remotely look like Embrace, Extend, Extinguish then a lot more hate is thrown around. This is occurring a bit more as MS pushes outside of it's Windows world.

It seems to me their general plan has changed to Embrace and Host

hackinthebochs• 7 years ago

Since you seem to have a positive sentiment towards Blazor, can you point me to a good introduction that demonstrates the power and the benefits of the framework, e.g. increased expressiveness, reduced friction, etc? I've looked through a couple of intros but they never seemed to really sell the benefits of it. As someone who loves the C# language and .NET ecosystem I really want to like it but nothing has clicked so far.

nwah1• 7 years ago

The idea is to unify the development process and tooling on the front-end and the back-end, without suffering from poor performance and constant unnecessary roundtrips over the network. Not to mention, a significant number of people strongly prefer C# to Javascript (and even Typescript).

If those two things never bothered you, then you might not understand the benefit, and you can continue to use what you like.

In practice, sending the .NET libraries over the network is the major burden of the approach Blazor takes, since the first load will be slow and bandwidth-intensive, even though everything will likely be cached for subsequent visits.

However, as the WASM tooling and standards improve, the library sizes will shrink, and less libraries in general will be necessary to accomplish stuff that has been solved at the level of web standards.

Gene_Parmesan• 7 years ago

Attended a Blazor session at MS Build in May. My impression was, Blazor seems like a super cool tool that I will never be able to justify in production. For one, the performance is poor right now. Your options are either to use Signal to send every action over the network, or to deliver the entire .NET libraries along with the page. The size of that download is both impressively small (given the volume of code you're transferring), and also still way too large for me to feel comfortable foisting that on users.

Additionally, it requires that your front-end team feels comfortable working in .NET technologies. Ours certainly doesn't, and it would be very hard to sell my director on anything that doesn't maintain the traditional backend/frontend split.

thdrdt• 7 years ago

I think the main benefit of Blazor (server side) is that it's very easy to write SPAs with it. This is great for incompany apps that don't have a lot of traffic (Blazor can be difficult to scale).

You bind your backend to your frontend and SignalR communicates all changes.

But there are some things you should be aware of. Because the frondend and backend are integrated it's very easy to 'leak' your data layer to the frontend. Always use viewmodels.

jcmontx2• 7 years ago

Yes, sure. In my opinion, these are the main features:

1. You can have all the benefits of a static-strongly typed language such as C#. Which implies: better tooling, less prompt to type errors, and more suitable for enterprise software.

2. You get the full power of .NET in the browser

And, if you are already using ASP.NET for your backend:

3. You can reuse a lot of code. This means almost no class duplication (like when you work with TypeScript).

Extra:

4. Blazor is pretty similar to Angular +2, so the learning curve is smooth if you either have experience with Angular or C#.

manigandham2• 7 years ago

The shared advantages are strong typing and compilation, C# code and constructs, Nuget ecosystem, and shared classes and logic between frontend/backend.

Client-side currently suffers from large download size and startup time (since the wasm .net runtime still interprets all the DLL files) on every run. It's still in preview so expect this to get better eventually. Client-side also still requires HTTP calls to the backend (since that's the only thing available in the browser) but you can use the `HttpClient` with all the shared classes and included JSON facilities instead of maintaining a separate version in JS.

Server-side means all the components run on the server, with updates and interactions run over SignalR websocket connection. This is best suited for internal apps, enterprise SaaS or other highly-interactive apps that would need a real-time connection anyway. The fact that all the UI logic runs on the server means you save a tremendous amount of effort by skipping all the view models, serialization, http calls, and everything else that's necessary. You can have database calls right in your component. This makes complex interactions incredibly easy. If you fit this scenario, Blazor is an fantastic tool compared to what we had before.

Also it's important to note that you don't need the whole app to be in Blazor. You can easily use MVC or Razor pages and just include an interactive component somewhere on the page. We use this for a normal server-rendered site that has some pages that require complex logic and just have that part powered by Blazor server-side as well. It's seamless and even supports server-prerendering so the first-load of the page is fully composed before the real-time connection starts up and takes over the state.

tren• 7 years ago

You can complete this tutorial in a few hours: https://github.com/dotnet-presentations/blazor-workshop, it really sold me.

ailideex• 7 years ago

I know MSFT technologies get a lot of hate here, but ASP.NET Core is pretty awesome.

Given how bad an actor they were I guess some people have a hard time forgetting the past.

teh_klev• 7 years ago

Sure, but on posts where the comments head downhill lubricated by this trope, often the commentators were still in kindergarten during this time. There's a cargo-cult mentality when it comes to accusing M$ of Embrace, Extend and Extinguish. Sure it happened but the folks leaving these comments weren't around at the time working as pro-software developers. I was, it was annoying, but the world didn't implode, and the law kicked in and did mostly its job.

So big deal and yawn. MS has a new management, it was "infiltrated" by the right folks in the early to mid 2000's who educated MS from inside and began to set MS on the right track. It takes time, like steering an oil tanker.

But MS are a capitalist corporation, just like all the others, they will all do some evil at some point in time on behalf of their bottom line and shareholder dividends, if they think they can get away with it.

hudo• 7 years ago

Its actually Win10 that people hate, dev tools are just fine

Mountain_Skies2• 7 years ago

Blazor might pull me back into software development. About five years ago after close to three decades of doing software development, I got tired of seeing so much software being bent and shoved into JavaScript. I absolutely loathe JavaScript so it seemed like a good time to move on to something else, which in my case was IT security. Occasionally I write a tool or two for use by my team but most developer jobs these days require coding in JavaScript so I hadn't given much thought to going back to full time development work. Blazor however has been a joy to work with. My understanding is JavaScript will still be required for a while on most webassembly apps but for my uses I've been able to avoid doing any directly. Maybe in another couple of years the market will change and those who don't want to use JavaScript everywhere and are horrified that even embedded systems are flirting with js, will again have a place in the world.

bob10294• 7 years ago

I have found similar joys in using Blazor. Once you get past the boilerplate stage, the productivity gains go exponential very quickly. Component reuse + strong typing + no API controllers or JSON contracts = how web development should have always been. I've got elegant LINQ statements right in my component markup. Creating extremely complex tables and views is so trivial with this combination of technologies. I can even subscribe my razor components to CLR events and everything works exactly the way you'd hope it would. The SignalR link between client and server abstracts away a huge bucket of questionable practices, with some potential trade-offs. Perhaps there is some downside I haven't found yet, but at this point I feel I could live with whatever strangeness might begin to emerge from the path I have taken.

In my experience, it is not possible to completely eliminate JS from the equation with Blazor. I've had to write a single .js file which I currently use for 3 things: Reading a cookie, writing a cookie and focusing an arbitrary DOM element. The focus concern I could probably alternatively handle with an autofocus attr which is dynamically inserted into the razor component, but somehow this seemed easier. Cookie or local storage interop requires JS. This is a very simple bit of code to write, and I would strongly recommend implementing it yourself to become familiar with Blazor component lifecycle events (i.e. how you make sure this JS shim is loaded into DOM before invoking its methods).

I've been wanting to create a public GitHub repo with a more practical Blazor boilerplate app that might help others get started with this kind of concern a lot faster. Perhaps something like an LDAP-authenticated business operations dashboard. Seeing an actual cookie session token read/written and how all of the code flows for session management purposes can save days of frustration. I already see some options out there for Nugets that claim to handle Blazor session management for you, but in my experience these almost always get in the way and force techniques upon you that you really didn't want to work with. If you find yourself reading the documentation for a CookiePolicyOptions or ClaimsPrincipal type, you probably went too far down the rabbit hole.

pknopf• 7 years ago

Blazor will only work on an Electron-ish setup. You'll never see adoption on the interwebs.

It reminds me of the ole UpdatePanel/AjaxControlToolkit/ViewState world where big/complicated/bloated frameworks with big runtimes were trying to solve super simple problems.

okareaman2• 7 years ago

I thought that too after my initial look at Blazor. Then I realized a big target for Blazor is enterprise and corporate intranets where network speed is many times not the issue

ryanthedev• 7 years ago

.net core in general has grown, building cross platform scalable apps is a breeze. Also they have really built some great performance libs, (Channels, Pipelines, Span, Memory).

The tooling is a little wonky at times when it comes to blazor. Hopefully they will turn this into a flagship product.

syrusakbary• 7 years ago

Great work on the article and extension Peter!

I didn’t see any reference to existing work in this area in the article, I’m curious to know how this differs from projects like WasmerSharp by Miguel de Icaza released a few months ago.

https://github.com/migueldeicaza/WasmerSharp

sanxiyn• 7 years ago

One obvious difference is that WasmerSharp wraps Wasmer. Wasmer and Wasmtime are different.

Nelkins• 7 years ago

For anyone curious, the actual .NET Wasmtime package source is here: https://github.com/bytecodealliance/wasmtime/tree/master/cra...

jonny3832• 7 years ago

Please don't pollute the web with .NET on the client side too. Do we _really_ need this?

userbinator• 7 years ago

MS has had ".NET on the client side" for quite a while now. It's called Silverlight.

jonny3832• 7 years ago

Silverlight was deprecated.

Mountain_Skies2• 7 years ago

JavaScript has been polluting the server side for quite some time now. Blowback was inevitable.

Using WebAssembly from .NET with Wasmtime

Related Stories