http://tirania.org/blog/archive/2010/May-03.html
ECMA CLI would have given the web both strongly typed and loosely
typed programming languages. It would have given developers a choice
between performance and scriptability. A programming language choice
(use the right tool for the right job) and would have in general made
web pages faster just by moving performance sensitive code to strongly
typed languages.
A wide variety of languages would have become first-class citizens on
the web client. Today those languages can run, but they can run in
plugin islands. They can run inside Flash or they can run inside
Silverlight, but they are second class citizens: they run on separate
VMs, and they are constrained on how they talk to the browser with
very limited APIs (only some 20 or so entry points exist to integrate
the browser with a plugin, and most advance interoperability scenarios
require extensive hacks and knowing about a browser internal).
Perhaps the time has come to experiment embedding the ECMA CLI inside
the browser. Not as a separate plugin, and not as a plugin island, but
as a first-class VM inside the browser. Running side-by-side to the
Javascript engine.
Such an effort would have two goals:
* Access to new languages inside the browser, optionally
statically typed for major performance boosts.
* A new platform for innovating on the browser by providing a safe
mechanism to extend the browser APIs.
We could do this by linking Mono directly into the browser. This would
allow developers to write code like this:
<script language="csharp">
from email in documents.ElementsByTag ("email")
email.Style.Font = "bold";
</script>
Or pulling the source from the server:
<script language="csharp" source="ImageGallery.cs"></script>
We could replace `csharp' with any of the existing open sourced
compilers (C#, IronPython, IronRuby and others).
Or alternatively, if users did not want to distribute their source and
instead ship a compact binary to the end users, they could embed the
binary CIL directly:
