Miguel De Icaza: CLI on the Web.

We have this already: &#60;applet&#62;. As we all know, it didn't work out so well. Having a compact format for classfiles is great. Loading java.util.* for every applet is not so great. Putting .NET into the browser would repeat this horrible experiment.<p>Miguel and Joe and solving the wrong problem. The problem is lack of a standard, compact bytecode format for Javascript, not lack of a complex built-in set of framework classes.<p>Throwing a whole runtime (Mono+CLI) with all of its legacy baggage at the problem won't solve this problem. Once you provide a bytecode format for the browser, web-native tools like GWT can generate more efficient, web-native application.<p>Couple the JS bytecode format with a global, cryptographically-secure long-term JS cache and you've built something just as powerful as Java or .NET but without the platform impedance mismatches.

Thought this was talking about "Command Line Interface" for a while. It in fact refers to Microsoft's "Common Language Infrastructure" (I thought this was CLR, or Common Language Runtime, but I’ve been out of the MSFT camp for a while).<p>Anyway — what’s the difference between this and plugins/Java applets (anything that compiles to Java bytecode)/ActiveX?<p>I suppose the biggest is that this proposes that 1) they have access to the DOM and 2) the browser implements the CLI environment.

How much of the web's inflexibility comes from Javascript and cross-platform JS issues, and how much of it comes from things like "Canvas is only reliable in 40% of browsers" and "HTML5 video only works reliably in Chrome and Safari"?<p>Because, CLI could address the former (it seems sensible to standardize a bytecode runtime rather than an entire language and its associated libraries), but probably not the latter.

This isn't just about replacing JavaScript with a CLI VM. It is about replacing the entire web stack, from HTML, CSS, and SVG all the way down to JavaScript.<p>The primary benefit of this would be that high-level languages like HTML would be implemented on top of the VM, and would no longer be hard-coded into the browser. This would allow you to, for instance, link to the latest version of the HTML runtime the same way you would link to the latest jQuery. This would mean that we would no longer have to wait for the browser vendors and standards bodies to bring us cutting edge technologies. This would also mean that alternative UI toolkits and languages would play on the same level field as HTML and JavaScript.

The pain of developing web applications is largely dealing with cross-browser DOM and CSS issues. Swapping in a different scripting language may give you faster code execution, classic class-based inheritance and a packaging system, but as far as I can see it does nothing to help with layout issues, widget creation and other UI issues.

<p><pre><code> &#60;script runat="lawyers"&#62; alert('Microsoft can pull the plug on your project at any time'); &#60;/script&#62;</code></pre>

Javascript/html/css etc were designed to be very small, use very little bandwidth. Flash also thrived and won with this aim. Going this route sounds nice but the battles and bloat would be immense. The web is a thin client, it can do fat client stuff but it is ultimately designed to be thin. That is what made it ubiquitous, not being a fat client...<p>What this is, is making an application for the desktop. They can take a branch of Webkit or Firefox and add CLI but they could also just make their own downloadable app to do this.<p>I like the idea I just think this might wreck the one standard thing we got going in javascript as the glue of the web. A scripting language can bend to the changes as it has done with minimal versions. It could be faster and bytecode itself sure but still it has worked well to tie things together. Silverlight and Flash can partially do this but you still have sandbox issues, which it would also have to have. You'd still have limitations yet it would be a jungle. Right now the jungle is the plugin. Lots of innovation but also lots of differentiation, legacy, etc.<p>I do think that the browser cache needs more space, Javascript engines could be faster, Canvas support and hardware acceleration are needed quickly. Maybe the CLI would be the way but everything we do with the web is design by committee, most of the stuff that made it in that works so well was made when they were still small and non-existent as a market. Everything from here on out will be slowwww to change.<p>HTML/Javascript/css is all just text. If this new system could have app descriptions as small and as readable/runnable by future generations then I think it could work.

what was Microsoft thinking when they coined a name whose acronym was already used and very well known in the field? I think it shows either a little contempt or ignorance, or just bad taste, to do that without first exhausting any reasonable alternative. The title and article confused the hell out of me due to their hijacking of CLI.

Microsoft had a similar project called Volta: <a href="http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta" rel="nofollow">http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta</a><p>It worked at the bytecode level - it wasn't just compiling C# into JS or something like that. I seem to remember that it had a full runtime in Javascript. It was terribly slow.<p>But, this kind of approach might not be so bad going forward, now that JS engines are faster. If the browser doesn't have a .NET runtime built-in, fallback to JS emulation.

Can somebody explain what technical reason prevent me from using any scripting language to write my web-app's client-side code?<p>The way I see it, web-apps today are downloading javascript code that calls back to the server from time to time and outputs a DOM tree. Any scripting language can do that, right? Why can't I write my client-side code in Ruby, Python or PHP?