WebAssembly support? #6457
Comments
|
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? |
|
@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. |
|
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. |
|
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. |
|
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 |
|
@SteveSandersonMS any thoughts on this? I'm not sure how Cordova could relate to this. |
|
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. |
|
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? |
|
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. |
|
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 |
|
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. :) |
|
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:
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. |
@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. |
This has to do with using this alternative as a new option for .NET in the Mobile segment. Not in substituting ASP.NET MVC for WASM, but in using in part of that ASP.NET MVC framework applied in WASM to reach a new group of developers that does not yet have support on the .NET platform: Hybrid Mobile Applications. Not everyone will actually use this technology, but I believe it has room for growth yes. Today everything applied in hybrid mobile applications are always supported by JS, it would be interesting to see C # able to do something in this field
There is no need to replace, but rather add. There simply is not an alternative on any platform other than JS for hybrid applications yet. Even though it was impossible not long ago due to WASM being a very new technology, but with that being a reality now, I believe it is a way to be considered by the .NET platform Want to develop native multi-platform applications? Great, the Xamarin caters very well. Want to develop multi-platform hybrid applications? Who knows a combination of WASM + ASP.NET Core (And less JS than is needed today) might not be interesting |
We already had something similar....Silverlight! It was not a success. Each attempt to replace JavaScript failed, Node.js success depends mainly on its usgae of JavaScript also on the server side.... None wants to leave JavaScript for a language with a smaller market share! Not convenient! Too much echosystem, almost all deveopers have a good knowledge of JavaScript...and so on. Consider that JavaScript itself may be compiled to wasm for better performance However, SOME applications may benefit of "Browser C#", and ALL applications might benefit of C# libraries ported to Wasm. |
|
@jonathanperis , I basically agree with your considerations, they are quite similar to what I already said. |
|
@frankabbruzzese Silverlight didn't succeed because it was a plugin. WASM is supported already on all important browsers. Access to WASM does not require the end user to install anything or agree to anything. It also did not allow me to compile my existing applications with little to no changes, straight into a simple web accessible format. I am going to ignore the node.js stuff. This issue, is about how we could use WASM to completely change the way we write, web accessible applications. No more will we be limited to html and javascript, depending on how this is implement, it could mean no more: html, CSS, and javascript. My point is that WASM is such a large change, to the fundamental way that the internet can work, that websites as we no them are pretty much obsolete. Websites have mainly been an attempt to replicate the functionality of desktop applications. Over the years, they have gotten a lot closer, but are not there, mainly because of latency, WASM addresses that issue, by moving large amounts of processing to the clients. Just think of this, you write a C# application, then compile into WASM. There would be no need for html. Then anyone on any device can open it with just a url. While always having the most up to date version. I am talking about, on your phone, tablet, or desktop, with any os. As long as it has a browser that supports wasm. There will always be people that don't like change. If you want to stick with HTML, CSS, and javascript. You can. However, if you want to start a whole new way of using the internet, the line starts here. |
That is actually not true, the developers of WASM have clearly stated that there is no point in compiling javascript to wasm. |
|
I could not agree more with you. That's the point. |
|
@i4Contractor first of all WebForm tried to replicate the way windows form works. After that there was a shift toward more "Web specific" techniques. Moreover, there was WPF, and now Xamarin, and Windows universal applicacions that, on the contrary, moved the word of widows forms toward web specific concepts (Xaml mimics and improve Html). Don't forget also about the cloud, and its several software services, too! For sure if you decide to write your client code in C# your user will have no negative effects. However for a bigger company it is better to invest in JavaScript or better in TypeScript that may rely in bigger echosystem. It is easier to find JavaScript, it is also easy to find graphic designer with some JavaScript knowledge. Node.Js success is essentally due to the usage of JavaScript. It expanded immediately thanks to the pre-existing echosystem of JavaScript libraries. Now also As.net Core uses Niode.Js for client scripting (gul bower, webpack, JavaScript service, etc.). Don't forget also that wasm application have exactly the same limitations any Html application have, so if you want to gain full control of the client machine you would need Apache Cordova, in any case. So maybe in several cases Xamaring would be a better choice than writing C# that compiles to Wasm. |
|
@i4Contractor, about compiling Javascript to Wasm. True JavaScript is a dynamic language, meaning also in case you compile it there might be some pieces that need to be either interpreted or compiled at runtime. Thus, any "compiled code" needs a run-time containing JavaScript compiler itself oa a JavaScript interpreter....The same is true also for C# due to its reflection features, though. Anyway, Chrome and Node.js compile JavaScript code (with the limitations I specified), so JavaScript may be compiled to Wasm yielding a mix of JavaScript and Wasm. In other words only the not-dynamic part is compiled to wasm. |
|
With Razor right now, we can write server side code that renders out into html and javascript. I would like to have the ability to write C# in my Razor, and be able to run that on the client. I think the gap I really want to close is everything that happens between the Get and Post steps of a form for example. Any interactive DOM manipulation, client side validation, and anything else that would either normally require Javascript or another server call. I want to enhance MVC, not replace it. |
|
@frankabbruzzese I please spend a few hours on youtube watching WASM videos. The entire reason that asm.js turned into WASM, was the type system in javascript. It does not allow for a lot of compiled time optimizations to happen. Yes you could compile javascript into wasm, but it would be slower than the built in javascript engines. At this point we are just adding extra confusing information into this issue. Which is not supposed to be a history on WASM or npm (which you need to read about). So lets leave this issue for discussion on people's hopes for .net and wasm. If you can't let your not-relevant issues go, create another issue that is continuation of this conversation, and mention me in it. I will be happy to make that issue as bloated as needed. |
|
Apps and SPA/PWAs are really similar. They manage the full application in the client side. The host is different- native os in case of apps and browsers for PWA. But they consume APIs for various purposes, which is provided by server. How can that part actually be replaced? |
|
@i4Contractor , Just my last comment about the subject. I already said the point is that Js is a dynamic language. Always possible speed up any language with compilation. At least you can factor out at compile time the interpreter parsing stage. Moreover, often types of local variables may be inferred at compile time (for instance the index of a for), thus allowing the substitution with ad hoc not dynamic types. As I already said in my first post, performance critique modules may be implemented with different languages: either C# or C++(wich is about one order of magnitude faster than C#). A discussion about JavaScript compilation to Wasm is here: . It points out the need to implement Js VM in wasm (as i already mentioned) and the needed evolution of Wasm to support it (access to GC and so on). As Wasm wiil spread it may occur if developers will have the need of higher performance. Also possible this need will never occur! In any case it is interesting also to read about the need about the motivation about this request: people do want to continue using JavaScript. In 90% of the code of an application performance is not prioritary. Usually the need for higher performance is located in a few small modules. Higher priorities are: the availability of libraries, modularity, maintenance and production costs. I beleive more in the evolution of JavaScript (and Wasm) to meet the new applications requirements, than in its massive replacement. However, a partial replacement in a small market share is likely to occur. |
@gulshan The cool thing about WASM is that apps will be able to run in the browser VM instead of the host os. That has a ton of major implications.
Some applications don't actually need any to query/post external data. Some applications do. Each application has it's own needs. If for example your application were getting something like a user record. Would you rather directly query the database on the client, or hit a web server and have it process the request. The downsides of the later, is that it causes extra load and it adds extra latency. However that extra load/time may not matter to you. WASM will not get rid of the need for data sources. I say that, but I just saw a pretty cool thing where someone compiled a sqllite database into wasm. They were then query it using the sqllite wasm port. So depending on the application, you might be able to compile your entire database into wasm and then there would be no need to hit the server. Again, this really depends a lot on what your application is trying to do. |
|
I think Wasm on JavaScript is a transitional technology that will enable the next generation of application delivery. What you can do with the browser, JavaScript, and CSS is pretty amazing, considering that they are essentially "hacks" for a text delivery technology that snowballed. But the browser architecture itself is pretty scary under the hood (i.e., box model, flow, DOM and CSS trees) for graphics compared to a "traditional" graphics system. Wasm is a first step in standardizing on a common entry point for browsers. Right now that point is backed by JavaScript, but that could easily change. Wasm has the potential to combine what html, css, javascript, WebGL/CL, does into a single target language. Right now running that uses a subset of JavaScript in a browser on an OS, but in reality any target could be used. Anything with a Network Card, CPU, and Graphics card could run a version of Wasm. If Wasm is "assembly" then the cpu is [browser->asm.js->OS]. Couldn't this be replaced with a single chip that only needs to run Wasm X.0? Couldn't custom "dll's/exe's", microservices, or shaders be swapped in and out over the network in near real time? |
|
Is this functionality really planned for delivery in version 2.1.0? I'm really looking forward to it. |
|
@jonathanperis No, definitely not. I think it was only put in the 2.1.0 milestone as a note that we're thinking about it. We should probably take it out of the 2.1.0 milestone for clarity. cc @Eilon |
|
Yup, moved it out. |
|
You guys HAVE to jump all over this... WASM and ASP.NET Core has the potential to be MUCH more than a "healthy relationship"... It could become the new clean web standard if you guys do it right. I will jump on board the day you release it and I know many others will follow. Until then I'm forced to pick something else for client side ASP.NET Core stuff. :( |
|
Apparently, an initial implementation has already been done on CoreRT: dotnet/corert#4659 |
|
Here are the my main reasons I'd want this implemented by Microsoft, and the sooner the better. Xamarin (although with a different XAML flavor 😕), solves this issue partially by aiming towards mobile platforms, but for developers that need tools for quick distribution to any platform, Xamarin doesn't cover web. Xamarin also has a quite limited set of working controls (no Blazor as a partial C# code-based between server and client is a major step. I dislike JS and even typescript can be cumbersome in situations when having to share code with server, for instance data-models. Even with generated entities you have to do everything manually and the chances to screw up things are higher. First thing I'm hoping to be implemented in Blazor is templates to allow building a JS/TS-free SPA app. I'd even wanna see the code files easily stripped out from the cshtml to cs files allowing for a proper local library with namespaces etc. In the future, I'd love to see Blazor as a means to be able to interact with a Controller/Web API, and perhaps using MVVM would be awesome too enabling the UI back-end to be shared with other clients, such as WPF/UWP/Xamarin etc. Another thing I was trying to find in Blazor (pm @SteveSandersonMS), is ANY documentation on how to contribute, what are the potential contribution endpoints divided by areas (contributing to the API, the runtime, and sorted by language - C#/C etc.). And finally, talking about Blazor, it is indeed a real deal breaker. Hopefully towards the golden age of .NET development of the future decade! So thank you @SteveSandersonMS for the hard and awesome work! |
|
WASM as an ASP.NET MVVM application (a.k.a. Razor Pages) will be very awesome! |
|
Mono keeps working and improving running on wasm. @SteveSandersonMS please push the team to make Blazor (or something like that) a reality !! |
|
@SteveSandersonMS Please, make Blazor template based on ASP.NET Core Razor Pages! 😄 |
|
Hi folks, I'm happy to share that today we announced that Blazor is now an official "experimental" ASP.NET project. Blazor is an "experimental web UI framework based on C#, Razor, and HTML that runs in the browser via WebAssembly". There's nothing to download yet, but the code is available and being actively worked on by the ASP.NET team (hopefully we'll have something for you to play around with soon!). At this point we'd like to move further discussion on WebAssembly support to the Blazor repo. Feel free to file issues or join the discussion on Gitter. Thanks for helping to make Blazor happen! |
|
@danroth27 |
|
Has there been any progress with general class-library compilation to WASM? I have some computational stuff / things that could interact with other apis that I want on the client side (all in F# -- it would be great to compile to WASM and leverage the speed from my ember app) |
|
@NullVoxPopuli See http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/ for the latest status of static compilation to WebAssembly. |
|
I saw that, but I was having issues with mono with even building my project to begin with. (I can build with |
|
@NullVoxPopuli The best thing I've seen come out of this so far is the public preview of Blazor. I recommend checking that out and seeing if you can use it as an example to go off of if nothing else. |
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.
The text was updated successfully, but these errors were encountered: