Common Language Infrastructure (CLI) for the Web

Attention, the translation of one interesting post from Miguel's blog!

The last days of Joe Hewitt on Twitter were very worried about the state of client web technologies. TechCrunch reported on the status of progress in their review of The State Of The Web Development In 25 Tweets By One Man (Web Development Status In 25 One- Person Tweets).

Today Joe offered a brilliant idea:
')
If you embed ECMA CLI in browsers instead of ECMAScript, the web would be much more flexible.

ECMA CLI would give the web and strongly typed and dynamic programming languages. It would give developers a choice between performance and scripting. Choosing a programming language (using optimal tools for a specific task) would make a web page much faster simply by translating vital code into strongly typed languages.

A variety of programming languages ​​would become first-class residents of the client web. Many languages ​​are available now, but they work with plugins. They can run on Flash or Silverlight, but this path is not yet so smooth: they work on individual virtual machines, they are limited to how the browser interacts through the poor API (there are about 20 methods for integrating the plug-in with the browser, and the most advanced interaction scenarios require serious hacks and deep knowledge of the internal structure of a particular browser).

Perhaps it is time to experiment with ECMA CLI integration into the browser. Not as a separate plugin , not as a plugin platform, but as a first-class virtual machine inside the browser itself, running in parallel with the Javascript engine.

These studies would set two goals:

1. Access to new languages ​​within the browser, optionally statically typed languages ​​for significant performance gains.
2. A new browser innovation platform that provides a secure browser API extension mechanism.

We could do this by directly linking Mono to 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 by downloading the source from the server:

 <script language = "csharp" source = "ImageGallery.cs" />

We could replace 'csharp' with any existing open-source compiler (C #, IronPython, IronRuby, etc.).

Or, in another way, if developers do not want to distribute their source code, instead publish a compact binary for end users, they could embed a binary CIL directly:

 <script language = "cil" source = "MailApp.dll" />

Immediately I foresee a question about “unprotected sources”: yes, you can use .NET Reflector to view the source code of the compiled binary. But if the code is obfuscated, it will give you about the same pleasure as reading Javascript in the modern web.

Introducing CIL into browsers would create an isolated executable environment for each page (AppDomain in terms of ECMA) and a sandbox for the executing system.

The security model offered by Silverlight provides just as much as is needed to safely go beyond the runtime CLI. This security model distinguishes between untrusted code that needs to be checked against the stringent requirements of what this code is allowed to do and what it doesn’t, as well as between so-called. "Platform" code, which we fully trust (trusted).

Trusted code is given special powers that untrusted code does not have. Rantaim ensures that an unreliable code can not cause a critical (from a security point of view) and protected code.

This would allow browser manufacturers to provide a new API that would give full access to the underlying operating system (for example, direct access to such specialized hardware as a microphone and a webcam), at the same time ensuring that user code accesses it only in safe ways.

It is very important to give developers a chance to try a new trusted “platform” API: new UI models, rendering systems and APIs, all built on the same core.

I am absolutely fascinated by this idea and only regret that it was not my first that it occurred to me. We were too focused on our Moonlight plugin to go back a step and look at the problem more broadly: how can we use the ECMA CLI kernel for * all * applications without a browser plugin at all.

Joe, like many of the rest of us, is in conflict with the terrible power of web penetration and the delicacy and speed that GUI toolkits have.

Although Silverlight provides an excellent UI system inside the plugin, Joe's idea is that we need a platform on which we could even more quickly invent and run through new UI ideas, and perhaps even radically new UIs. And with the ECMA sandbox model, we could start testing new ideas without waiting for the browser manufacturers to add new features we need. We could integrate our plugins into the browser more than is possible now.

The existing plugin model does not provide the necessary capabilities to develop web innovations. We need a new model, and I'm ready to start with the prototype of the Joe idea.

The only question is which browser to start with - Firefox or Chrome.

Gestalt

Gestalt allows developers to use the CLI inside a browser, and also demonstrates how other languages ​​can be used in browsers. It requires the Silverlight plugin, but the interaction between the code and the browser is limited by the level of integration available to the browser plugin.

So, only half of the problem has been solved - the multilingual nature of the PL, and even then, this is done in a rather limited way.

[Translator's Notes]
CLI - Common Language Infrastructure, the .NET / Mono subsystem
CIL - Common Intermediate Language, bytecode .NET / Mono language