A vision – HTML5 can be “just another platform” for .NET


When pondering recently on what cool app I could make for my fantastic new Samsung Gear 2, my mind wandered back to ideas from the Xamarin Evolve 2013 Conference.   “I should do a C64 emulator!”.   The screen is 320×320.  Commodore 64 was 320×200. Letterbox it.   CPU is dual core 1GHz.  Should have enough juice.   Job done!

Well not quite, because despite Tizen supporting both native (C++) and web (HTML5) APIs, Samsung have chosen only to expose the HTML5 API for the Gear 2 device.   Fair enough, I suppose.   It’s “only a watch”.   Sucks for me, though.

And it actually sucks for other wearable developers too, because it means they’re going to be writing apps in JavaScript, even though the device specs are better than many of the smartphones currently on the market.    We’re not really being fair to this little supercomputer by constraining it to applications authored in JavaScript.

So what’s the answer?  C# of course.   Or more generally .NET, because F# or any of the other CLR languages could work here too.   Unlike with the AGENT smartwatch, which is built on top of the .NET Micro Framework, we’re going to need to dance a little to get this going.    The Gear 2, however, has a chance at serious market share in the smartwatch category due to the weight of Samsung,  unlike the AGENT.

Seeing what Frank Krueger has done with Netjs got me thinking.   This C64 project could be run through Netjs, with a simple WebGL canvas for the rendering and then we’re nearly done.   We would need simple gesture input, which would have to be full screen swipes and a tap for “press button”.   A limited number of C64 games will be workable with that kind of simple gesture UI, but with that approach we have essentially got a working application where we’ve gone from C# to HTML5.

That thought process turned into the WearableC64 project.

More importantly, though, the possibility of targeting HTML5 from C# (and even of writing the WebGL bindings in C# to go through the same JS to C# pipeline) got me thinking much bigger.

I want to target HTML5 as an actual fully fledged platform, but to write the applications in C#.    We would have all of the HTML5 web APIs exposed as .NET bindings, and then write an HTML5 web application in pure C#.   That’s exactly the same pattern as all the other platforms in Xamarin world, except that this “platform” can run anywhere you have an HTML5 capable browser.   It isn’t tied to a particular OS or device from a particular manufacturer.

So you would have both .NET libraries and HTML5 web APIs available – a very well defined and understood API.    You could even have this as a formally defined standard – owned by ECMA or W3C or whoever.    It would be the simplest standard you could ever imagine – HTML5.NET standard = HTML5 standard + .NET standard.    The choice of what kind of .NET profile to use might be a little more of a discussion.

JSIL or netjs could be your starting point for the tooling, but HTML5 could become a formal target platform for Roslyn and other .NET compilers over time.   It’s just another back-end, right? How do you debug HTML5.NET?   In this kind of codegen scenario for C++ you would sprinkle #line derivatives all over the place.    Perhaps the glorious MSBuild debugger hack gives us some direction here?    Or perhaps Pilchie and Miguel already have good ideas about how this HTML5.NET debugging could work?

Whatever the case, I think there is the seed for something great here.

HTML5.NET could be a real target platform.   Multi-selectable for PCLs.   You would use the MVVM pattern to share code across multiple native platforms (iOS, Android, WinStore, etc) and HTML5.

Your HTML5.NET UI would be written entirely in C# (or F#, etc), but using the HTML5 standard APIs, wrapped into .NET APIs.

HTML5.NET shouldn’t be a commercial-only product.  It needs to be free, because it is potentially a platform for a world of innovation at the junction of native app and web development.

So maybe HTML5.NET is built under the .NET Foundation banner?    We could build a MonoHTML5 product (for MonoDevelop support of this platform) and a HTML5.NET for Visual Studio product (for Visual Studio support of this platform), but we shouldn’t charge anything for them.    They should be free of licensing costs, like MonoMac and Node.js Tools for Visual Studio.

Are other people already working towards this exact goal?   If so, cool 🙂   Are there details or caveats which would hinder creation of this platform?   What about performance?

Unreal Engine and Unity3D’s recent asm.js/WebGL demos in Firefox (Unity3D demo, UnrealEngine demo) have, I think, proven the viability of this kind of full applications running in the browser.    Another Gear 2 app I considered was a Unity3D game, exported to HTML5 and running on my watch.   I honestly think you could have Quake or similar running in a browser on your watch now (or soon!)

Anyway.  Enough.  What do you reckon, world?

Want to help me build the HTML5.NET standard and MonoHTML5 implementation?

Bob Summerwill, Vancouver, BC, 23rd May 2014.

7 thoughts on “A vision – HTML5 can be “just another platform” for .NET

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s