
Experimental UI framework running .NET in the browser via WebAssembly - mandeepj
https://github.com/SteveSanderson/Blazor
======
dragonshed
> 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...](https://github.com/ncave/DotNetAnywhere/commit/982238dd3c334c80a88ec9623d16b763fe278e73)

------
emersonrsantos
Hello applet my old friend

~~~
btschaegg

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

;-)

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

You can just see how this could become a mainstream approach

~~~
simooooo
Steve has always been years ahead of the game

------
d--b
Hehehe, and they said eval was evil!

------
mandeepj
Relevant talk with author -
[http://www.dotnetrocks.com/?show=1455](http://www.dotnetrocks.com/?show=1455)

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

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

~~~
mandeepj
And, I got it. Here is the video -
[https://www.youtube.com/watch?v=MiLAE6HMr10](https://www.youtube.com/watch?v=MiLAE6HMr10)

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

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

------
slathrop
Steve and a few others have done a little work recently on DotNetAnywhere
(DNA) under this branch:
[https://github.com/ncave/DotNetAnywhere/commits/latest](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.

------
soapdog
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?

~~~
viliescu
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](https://github.com/valentiniliescu/CSharpWeb)

------
mandeepj
Some more related links to .net micro fw -

[http://mattwarren.org/2017/03/30/The-.NET-IL-
Interpreter/](http://mattwarren.org/2017/03/30/The-.NET-IL-Interpreter/)

[https://github.com/NETMF/llilum](https://github.com/NETMF/llilum)

[http://www.netmf.com](http://www.netmf.com)

~~~
carussell
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++).

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

------
yodon
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](https://github.com/WebAssembly/design/blob/master/GC.md)

~~~
flukus
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.

~~~
yodon
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.

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

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

Really cool though

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

~~~
the8472
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.

~~~
themacguffinman
> 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.

~~~
the8472
> 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.

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

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

~~~
Ajedi32
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.

~~~
pier25
It's going to happen.

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

------
macsloppy
Flash, Java applets, ActiveX - here we go again

~~~
simon83
But this time it'll work, really!

~~~
macsloppy
It will be "secure"

