Experimental UI framework running .NET in the browser via WebAssembly | Hacker News Reader

Experimental UI framework running .NET in the browser via WebAssembly

github.com

121 pointsmandeepj53 comments

> Blazor runs .NET code in the browser via a small, portable .NET runtime called DotNetAnywhere (DNA) compiled to WebAssembly

Very ambitious for a side project. DotNetAnywhere is a 5 y/o interpreter project which needed a lot of love to build to WebAssembly. On top of that add the multiple layers needed for a competitive UI framework..

[edit] Link to an isolated DNA project fork: https://github.com/ncave/DotNetAnywhere/commit/982238dd3c334...

Hello applet my old friend

the right idea, the wrong execution ;)

  Fools, said I, do you not know
  Plugins like a cancer grow?

;-)

Really cool idea, and from the author of knockout.js no less!

You can just see how this could become a mainstream approach

Steve has always been years ahead of the game

Hehehe, and they said eval was evil!

Relevant talk with author - http://www.dotnetrocks.com/?show=1455

Is there a live demo anywhere? I couldn't find it in the page or talk link.

I have been hunting the web for that. No luck so far

And, I got it. Here is the video - https://www.youtube.com/watch?v=MiLAE6HMr10

How about a single live example? surely one could be uploaded on github pages...

DotNetRocks mentions a talk in which Steve demoed the concept but it is absent from the NDC site and Youtube.

Steve and a few others have done a little work recently on DotNetAnywhere (DNA) under this branch: https://github.com/ncave/DotNetAnywhere/commits/latest

But aside from these recent tweaks, the code hadn't been touched for about 5 years.

It's just a toy and POC for now, but interesting nonetheless.

JavaScript won't be unseated as the go-to language for web development and web frameworks by WASM, C#, Java, Python, Go, or anything else... at least not in the next decade.

But certainly high-performance pieces will be dropped-in via WASM to interop with JS for things like image manipulation, etc.

Couldn't get it to work under VS 2017. Tried both the 0.2.0 release from the GH repo and also cloning and opening the master branch... I really want to see this working, anyone managed to try it out? Can share how?

same here

install log: 05/07/2017 14:16:10 - System.IO.FileNotFoundException: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\ at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName) at VSIXInstaller.SupportedVSSKU.get_VersionWithBuildRevisionInfo() at VSIXInstaller.App.IsValidSKUForExtension(SupportedVSSKU supportedSKU, IExtension extension, List`1 validSKUs) at VSIXInstaller.App.ShouldAddSkuToValidSkuList(SupportedVSSKU sku, IInstallableExtension extension, List`1 validSKUs) at VSIXInstaller.App.GetInstallableData(String vsixPath, Boolean isRepairSupported, IEnumerable`1& skuData) at VSIXInstaller.App.Initialize(Boolean isRepairSupported) at VSIXInstaller.App.Initialize() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute()

For me, creating and running a project with the released VSIX (0.2.0) works fine. I was not able to build the project itself locally. And I wanted to understand the technology a little better, so I created a simpler version, no Razor involved, just plain C#: https://github.com/valentiniliescu/CSharpWeb

Some more related links to .net micro fw -

http://mattwarren.org/2017/03/30/The-.NET-IL-Interpreter/

https://github.com/NETMF/llilum

http://www.netmf.com

This project says it uses DotNetAnywhere (MIT licensed, written in C), which doesn't seem to be related to NETMF (Apache licensed, written in C++).

I completely agree. I shared these links hoping we can borrow some concepts from here to evolve the .net webasm project.

How does this framework handle Garbage Collection? (WebAssembly has GC support planned for the future but doesn't have it in place yet[0])

[0] https://github.com/WebAssembly/design/blob/master/GC.md

I'm guessing it will download a runtime that will include the garbage collector. Soon you can look forward to every page including a runtime, or maybe several depending on which advertising engines they're using.

The problem is there's been a ton of work on chained garbage collectors, and the frustrating and seemingly non-intuitive result that everyone eventually hits is that you have to collapse down to a single garbage collector to get garbage collection to work reliable. There are just too many edge cases when you have, say, a native browser garbage collector and a separate application garbage collector, with references held between them. That's why mainstream support for C# -> WebAssembly is on hold until WebAssembly exposes native garbage collection support.

Really interesting. I can see this kind of approach be coming very commonplace.

The thought of it becoming commonplace is somewhat frightening...

Really cool though

Why frightening? This is long overdue - allowing us to use whatever tooling to generate interactive webpages, instead of dealing with JS.

I think it’s more frightening the thought of compiling an entire language runtime to run in the browser

Frightening if you're the one who has to debug it.

Do you mean debugging third party closed source code? If not just debug normally like we have done decades (and even in web world few years using these "source maps"). If it cannot be done today it will be then when it's main stream.

Probably not, once tooling is in place. Running an implementation of the .NET platform would make it possible to attach standard .NET tools to the application running in the browser. (Once it was implemented in the .NET interpreter, of course.) That would give you a much nicer debugging environment than you'd normally get in a JavaScript application.

Because it makes it even harder for users to take apart websites and understand them.

If it ends up executing IL, then tools like Reflector will probably make it easier to read and explore the code than minified JS

I’m sorry, but have you actually written tools to take apart obfuscated and minified JS vs. webasm?

I’ve actually done that to research and break some systems, and webasm is an order of magnitude worse than JS.

My understanding was that, at least for this example, is that the DNA runtime is loading raw IL, not webasm, and the interesting site specific stuff will be in IL. I do not doubt what you're saying about webasm.

That’s until someone, like Microsoft, makes a serious version of this, and integrates automated obfuscation.

What's bad about that? The owners have every right to not disclose their source code.

But why do we, as society, grant them that right?

I mean, this is the reason why patents were invented originally: You publish the way your technology works, in return, after a short term, everyone can use it, which improves innovation.

Yet, nowadays, a lot more is done via trade secrets.

It would be awesome if we could get that innovation back that we’ve lost.

Because "we as a society" have no business telling other people what to do with their things as long as they don't hurt others.

For some people the alternative to closed source isn't open source, it's either "not publicly published" or "not developed at all", which actually slows development down.

desktop application: the software is on your PC, the files are on your PC, you can use it forever, move it around and at least here in the EU your right to reverse-engineer it for compatibility is guaranteed

web application: cloud-service, eternally rented, may go out of service at any time (this has already been an an issue, remember zune drm?), does not interoperate with the native environment at all. you can't even read/write to files! p2p networks are impossible in browsers, everything is centralized.

People think that the "run applications in the browser" will bring us cross-platform goodness, but I think it will mostly make is more dependent on the ecosystem of cloud providers and lead to more vendor lockin since it is more difficult to get your stuff out of those silos.

And the indirect effect of marginalizing desktop applications ultimately means less control for the user. This is easily visible in the mobile sector but is slowly encroaching on the desktop too.

I'd argue the contrary. You have more control on a webapp than on a native app on iOS. You can create your own web application without having to pay a toll to Apple.

> This is easily visible in the mobile sector

> desktop application: the software is on your PC, the files are on your PC, you can use it forever

Not really, creative DRM is common in desktop applications.

> does not interoperate with the native environment at all. you can't even read/write to files

Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem.

> cloud-service, eternally rented, may go out of service at any time

Lots of web apps are being built for offline usage with new offline-oriented web APIs. Web apps can also be packaged as offline Chrome Apps or "native" apps with Electron.

> p2p networks are impossible in browsers, everything is centralized

Not true, WebRTC was designed to address this and is already supported in all major browsers.

> Not true, WebRTC was designed to address this and is already supported in all major browsers.

False, you cannot build decentralized p2p networks on webrtc because you always need a signalling server. the session establishment protocol needs one-time tokens which need to be exchange some way, which means you can't build a self-sustaining network.

For example Kademlia DHTs require the ability to quickly send requests to peers you have not contacted before (that's why it's UDP-based). If that requires a session setup and teardown every time that negates the advantages of iterative lookups, even if you could decentralize that part.

> Not really, creative DRM is common in desktop applications.

None of the ones I'm using on a daily basis have DRM.

> Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem.

My understanding is that the FileSystem API is an emulation of a filesystem that stores things in a database in the browser profile. That's not interoperability with native. IPC, file access and sockets are some cuicial features for interoperability.

> Lots of web apps are being built for offline usage with new offline-oriented web APIs. Web apps can also be packaged as offline Chrome Apps or "native" apps with Electron.

aiui chrome apps are dead except on chromebooks. those offline-apis (service workers) don't give you portability, depend on the browser cache and so on. that gives them volatility. And Electron... well, that just makes it another desktop framework which does provide interoperability with native, I guess I'm kinda ok with that case. But you don't really need wasm then, you can just link to existing libraries. A bit of a pity though that mozilla canceled its positron implementation, would have been nice having two implementations.

But that's besides the point. As I said previously, it's not about the best possible outcome you can achieve with the technology, it's how it will be applied to the masses. And that's where I think it will be used as a tool to move more users into walled gardens.

Remember back when some sites used to do their entire UI in flash, completely ignoring standard UI conventions of the web, breaking the back button and deep linking, hijacking the scrollbar and making printing an entire page impossible? Let's not go back to that please.

What's that got to do with replacing JS? These platforms will not render their own graphics via canvas, for the most part, but just interface with the browser APIs. They're just to ditch the JS language, not browser tech/UI.

Nothing will stop Adobe from bringing Flash back from the grave via Web Assembly.

And this will actually be a good thing to preserve old flash content, but more securely.

That'd be fine as long as people only use it for _old_ flash content. The minute people start using it to render their website UI though, then we've got a problem.

It's going to happen.

Many (most?) designers will avoid code like the plague and stick to visual tools like Flash.

Due to the iPhone restrictions, Adobe worked on adding AOT compilation to native code, so nowadays many casual games are actually still done in Flash.

http://www.adobe.com/products/flash-builder/features.html

Flash, Java applets, ActiveX - here we go again

But this time it'll work, really!

It will be "secure"

Reply on news.ycombinator.com