WebAssembly support?

[i4Contractor]

Wasm will be a drastic shift in the way the internet works.

What is Microsoft's stance on this? Are you guys going to make the move to support asp.net on it? All major browsers support wasm now, so there should be no hold up. I like the direction and energy you guys have spent on asp.net core. I couldn't be happier with the work. However, now that Wasm is real, I think that energy should be put there.

This is why: I think the current design patterns, for the entire internet is going to shift, with this feature. Asp.net core works good for the current patterns, but after you support wasm, those patterns may not be useful anymore. Which is why I would like wasm supported ASAP (I know it will take time to actually do this), but the decision to do it is what I am after. I know I am a nobody and have no power to ask this, but with the whole open source ideology it shouldn't hurt to ask.

[Eilon]

cc @danroth27 @SteveSandersonMS

Hi @i4Contractor , this is certainly something we're taking a look at. Bear in mind that Web Assembly is a client-side tech, whereas ASP.NET Core is focused on server-side, but we think there's a lot of opportunity for creating a healthy relationship between the two.

Can you share your thoughts on what kind of scenarios you think are interesting regarding ASP.NET Core and Web Assembly?

[danroth27]

@i4Contractor no plans to do anything with WebAssembly yet, but @SteveSandersonMS put together a cool prototype of Razor running in the browser on WebAssembly that we'd love to hear your thoughts on: https://github.com/stevesanderson/Blazor. Let us know if this along the lines of what you're hoping to see, or if your expecting something different.

[i4Contractor]

@danroth27 , @Eilon

Blazor is pretty cool, however it is still limited in it's idea, to being an SPA. It is still using the same old idea of being a website. Still a very very cool idea.

I know webassembly is only at the MVP level now, so some of the things will require shims to make work, for now, like in blazor. That shouldn't stop the you though. My ideal usage is different. In this "new world", the browser just becomes an application delivery method for the browser's virtual machine. I really mean delivery instead of website. 80-100% of the work will be done in the browser, depending on what you are doing. What I am thinking is that asp.net core server side stuff becomes mainly obsolete, because it is serving up normal HTML. Yes, we will always want simple little things to be hosted on the server, so it will still be needed. Once webassebmly becomes a .net compilation target (yes some api's won't be possible and just will not work), the whole world changes. I am thinking of things like compiling, a console application, winforms, WPF, or UWP application to webassembly. Technically, we aren't limited to html controls and can draw controls that just aren't available in html. Yes you can do that now, but there hasn't really been a good reason too. Now there is.

There are also browser caching things that will need to be thought out. The whole compile everything that is used into a monolithic file, striping away unused code. Or do a nuget for the web browser's virtual machine. So the packages are webassembly packages and can be imported on the browser easier. This would mean that the next site (or revisits) that uses the various packages won't have to download them too.

It is a brave new world, the old debate between the benefits of an application and a website are pretty much gone. The application won, but you get all of the benefits of the web. You won't have to install applications anymore, just hit my website, and always have the latest version of the desktop application.

A side note: The server side load on will dramatically decrease.

[i4Contractor]

Oh, I forgot to mention offline modes, hardware/OS agnostic. So write your UWP app, host it on a site. And it works on: Windows, Chromebook, and just as well on my Apple Tablet. The virtual machine in the browser is the lowest level hardware you need to handle, everything else is abstracted away. Again, no more installing desktop applications. A good example of this is Office 365's Word Online, implementation. It is no where as good as the desktop Word application. That doesn't have to be the case anymore, they can be the same exact thing.

[jonathanperis]

@Eilon

cc @i4Contractor @danroth27

What do you think about a Mobile projects (Cordova) running ASP.NET Core + Web Components (Not necessary, will work nice tho) and WASM like Blazor does?

Build Mobile apps like Ionic (in the future v4 that will be platfform agnostic) and C# with ASP.NET Core will be absolutely nice

[Eilon]

@SteveSandersonMS any thoughts on this? I'm not sure how Cordova could relate to this.

[SteveSandersonMS]

Is the question about whether a Blazor-type app (i.e., .NET on WebAssembly with some HTML rendering capability) could be deployed as a native mobile app via Cordova? If so, that depends on whether such a framework takes any server-side dependencies.

Our Blazor prototype does not strictly rely on any server-side dependencies - it can run as a purely standalone set of static HTML/CSS/JS/WASM files, and thus could trivially be packaged as a native mobile app using Cordova.

[jonathanperis]

@Eilon

cc @SteveSandersonMS

I mean, mobile apps made for the Cordova platform use a webview of Chrome Mobile, which in turn has WebAssembly support

Adding support for WebAssembly in ASP.NET Core from my point of view enables the development of hybrid mobile applications in C # for this reason

The Blazor prototype made by SteveSandersonMS uses C # as the language for the front end, so I say that this approach automatically enables the development of hybrid mobile applications using C #

What do you think of this idea?

[SteveSandersonMS]

Yes, you're correct - if we had a .NET-on-WebAssembly app platform, and it was able to run standalone without any server-side components, then it could be packaged via Cordova to make hybrid mobile apps.

Of course, there are already other ways to build mobile apps using C# (e.g., Xamarin) which will probably always be better suited to producing a really native user experience, since they are designed to integrate with native UI widgets etc.

As for what approach is best in any given project, it will depend on how much your team specialises in web technologies and how finely tuned you need your mobile app UX to be.

[jonathanperis]

I agree, Xamarin is an alternative, but I think this has to do with opening the range of possibility to the developers. Xamarin is a great platform, but not everyone wants to use Xamarin to achieve a multi-platform Mobile solution.

I think it would be a great way for .NET to enable application development in all possible situations

The company in which I work uses hybrid applications just for the sake of not having .NET developers able to work with Xamarin at this time. Existing an ASP.NET Core + WebAssembly solution would solve this. Not just for my scenario, but many are more familiar with web technologies rather than native applications

[jonathanperis]

I believe that having this feature in ASP.NET Core, indirectly any .NET web developer becomes a developer of hybrid mobile applications.

It seems like a great idea to get developers' attention to .NET Core / ASP.NET Core. :)

[frankabbruzzese]

Wasm is not an alternative to server side technologies like Asp.net core Mvc, but just a partial alternative to JavaScript. An interesting alternative since, unlike propietary (Flash or Silverlight..) it is an official standard. I said a "partial alternative" since there are a lot of existing JavaScript tools, so a complete substitution of JavaScript with Wasm or other languages that compiles to Wasm is very unlikely to occur.

The main scopes of Wasm are:

• Performance critique modules, such as the ones used in games

• Porting librairies written in other languages to the browser VM

Moreover, I don't think that client side techniques, and off-line Html applications will ever substitute server side techniques, since the market is moving always more toward shared processing and software as a service. Thus, server is not just a source of data and "user authorizations", but also of computing services.

For similar reasons it is likely that client side html rendering will integrate but not substitute server side rendering. The main advantages of client side rendering are not performance and bandwith reduction, since always more bandwidth will be available also for mobile devices, but the ability to build rich user interfaces without renouncing to modularity. However, not all html pages need a so sophisticated UI that justifiies the higher cost of splitting the logic between server and client.

[i4Contractor]

Wasm is not an alternative to server side technologies like Asp.net core Mvc, but just a partial alternative to JavaScript.

@frankabbruzzese - I completely disagree with you. What it is, still 100% up in the air. If Microsoft were to port .net core, and some of the Windows Forms or UWP class to wasm. Then native applications could be compiled to wasm and delivered and used using a url. Then it could be a complete replacement for native applications. If they only port a few things like the Blasor example, they are still moving a whole lot of server side processing locally, but stick with HTML. It is all 100% up to what gets ported over.