Lets leave Javascript behind

Disclaimer: I am sure Javascript will continue to be supported, and continue even to progress in features and support, regardless of any Managed Web. Some people simply love it, with all the flaws and pitfalls, like a sweet elderly married couple holding onto life for each other.

It’s great what the web industry is doing with ECMAScript, from version 6 we will finally see something resembling classes and modules. But isn’t that something the software industry have had for years? Why do we continue to handicap the web with an inferior language, when there have always been better options? Must we wait another 2-3 years before we get operator overloading in ECMAScript 7?

The .Net framework is a rich standardised framework with an Intermediate Language (IL). The compiler optimisations, toolset and importantly the security model, make it a vibrant and optimised ecosystem which could be leveraged. It could have been leveraged years ago with a bare minimum Mono CLR.

Google Chrome supports native code, however it runs in a separate process and calls to the DOM must be marshalled through inter-process communication methods. This is not ideal. If the native code support was in the same process it would be a good foundation for Mono.

I believe it is possible, perhaps even trivial, to achieve this nirvana of a Managed Web. We just need to take small considered steps to get there, so here’s my plan.

  1. Simple native code in the same process – Javascript is currently executed on the main thread, presumably through the window message pump executing delegates. These delegates can simply forward to managed function delegates. But first we should be able to trigger an alert window through native code which is compiled inside the Google Chrome code base.
  2. Simple mono support – Fire up Mono, provide enough support in a Base Class Library (BCL) for triggering an alert. This time there will be an IL DLL with a class which implements an Interface for start-up.
  3. Fuller API – With the simple milestones above completed, a complete BCL API can be designed and implemented.
  4. Optimisations – For example, enumerating the DOM may be slowed by crossing the Managed/Unmanaged boundary? jQuery-like functions could be implemented in native code and exposed through the BCL.

Along the way, other stacks and browsers could also leverage our work, establishing support for at least Java as well.

Example API:


  • void Start(IWindow window) – Called when the applet is first loaded, just like when Javascript is first loaded (For javascript there isn’t an event, it simply starts executing the script from the first line)

see http://www.w3schools.com/jsref/obj_window.asp

see http://www.w3schools.com/jsref/dom_obj_document.asp

Warm up – Possible disadvantage

Javascript can be interpreted straight away, and there are several levels of optimisation applied only where needed, favouring fast execution time. IL would need to be JIT’d which would be a relatively slow process, but there’s no reason why it cannot be AOT compiled by the web server. Still I see this as the biggest disadvantage that needs to be front of mind.

Other people around the web who want this



Enhanced by Zemanta

8 thoughts on “Lets leave Javascript behind”

    1. Why not Michael? Javascript would still be there and supported. The title is provocative, not the objective. The objective is to open up the web to other languages.

    1. Yeah, there will be Mono envy from other browsers and browser envy from other frameworks (like Java).

      I was just thinking last night, with an efficient and modular language (like C#) and access to the Canvas, one could even think about bypassing in their web applications (even adding the canvas node to the DOM). Let’s start with Mono first though.

  1. The warm up disadvantage need not be there; there’s nothing stopping you from interpreting IL (I’m pretty sure Mono still has an IL interpreter, because it’s super-useful for platform bringup).

    That said, there’s probably a fair whack of work involved in turning the existing interpreter into a hotspot-like JITtter.

    1. That sounds promising. Perhaps the IL interpreter can get to work while JITing occurs on another thread low-priority.

      From my understanding V8 doesn’t completely compile JS to native image because there are many structures and features which cannot. JS objects are not static, more fields can be added. With ManagedWeb we don’t allow that, so lets get our for 100% JITing, no need for hot spotting, we’ll can use the standard JIT in a background thread.

  2. Well I gave it a roaring go. With the Google Chrome browser (nee WebKit), there was simply no abstraction of Javascript from browser. It’s too intermingled for my budget. This is why even Native support in Chrome uses IPC to Javascript to work on the DOM. But never fear, a workable alternative is in the works.

    See http://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly/

    I have been watching asm.js recently, and had planned to start targeting that for cutting edge performance. But even better is a bytecode which is transmitted and interpreted quicker!

    I would still love to rip out Javascript and put Mono (or Java) there instead, but with webassembly on the way I would need a bigger pot of money to be bothered.

Leave a Reply

Your email address will not be published. Required fields are marked *