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.
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.
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.
What I actually think is that if you add a standard bytecode to JS and a global JS cache, you get the same effect as with a stripped CLI profile. Why not reuse something existing since we've got both the VMs and the standard ready?
I don't think anyone wants to throw "a whole runtime (Mono+CLI)" at the problem - the core of it is enough. I'm not sure what is the legacy baggage you're referring to either.
Now that you've got the CLR running in the browser, you've got to figure out a way to map it to the existing JS semantics. Microsoft's existing JScript.NET mapping isn't cleanly compatible with the prototype-based inheritance of the Javascript you're writing.
Re: legacy baggage, see:
- the parts of the basic .NET framework that shipped with 1.x and were effectively deprecated during the switch to 2.0, ie: System.Collections vs. System.Collections.Generic.
- the DLL specification, in which .NET assemblies are wrapped.
If you're not shipping a framework, what do you win by shoehorning an existing bytecode specification into the browser, except not having to write that bytecode specification again?
The web has different requirements than a desktop/server application and needs a runtime built for the web.
So: no. What we do have, however, is a number of shots, scattered throughout Mozilla's history, at getting other languages into the browser that crashed and burned. Maybe Miguel has the pull to get uptake for something like this, but I'm skeptical.
JS is still your only option
Pertinent example: Flash improved its performance enormously from AS2 (ActionScript) to AS3, and one thing they did was add type info. Pertinent because AS is JS.
http://ajaxian.com/archives/ecmascript-edition-4-brendan-spe...
http://weblogs.mozillazine.org/roadmap/archives/2007/10/open...
I they added a few extra bytecodes for stuff like TCO or goto or integers, it'd be pretty fantastic.
I hear that a lot, but I think Java applets didn't gain widespread traction more because of the arrival of Flash as an easier format for simple animations and interactions than anything else.
Java applets remain a useful tool for browser-based UIs today; one of my current projects involves writing one. The biggest technical hurdle is that not everyone installs a modern JRE with their browser any more, which is a downer for casual use because it means there's stuff to install locally. For tools you're going to use every day it's no big hurdle, though.
The primary alternatives are Flash (which is well-established but looking more awkward and proprietary with all the current politics, and somewhat limited in its applicability) and JavaScript (which has potential, but isn't even close to being a good language for developing serious UIs of moderate or large size today, and no amount of HTML5 canvas/multimedia hype is going to change that).
IE can embed javascript bytecode
<script language = JScript.Encode>#@~^EQAAAA==C^+.D`Et+^VK~CgBbgQUAAA==^#~@</script>
it's not standard, though.
http://www.virtualconspiracy.com/content/articles/breaking-s...
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.
I think the idea has merit, but the current landscape of software development highly favours the statically compiled C++ browser engines, especially on mobile devices.
Overall, the goal is to make implementing a browser a much simpler and direct process, and to defer as much complexity as possible to libraries which can be easily downloaded and updated. This would not only result in more a heterogeneous ecosystem for web developers, but fewer browser bugs and incompatibilities.
It's a vendor job, not a committee spec. They can take the arrows in the back, keep what works, toss what doesn't. I personally think that modern JS+JIT implementations are nearly fast enough: it's become the DOM and its legacy behavior that's becoming the problem now.
(Edit: I see that you already mentioned this further down the thread.)
<script runat="lawyers">
alert('Microsoft can pull the plug on your project at any time');
</script>http://en.wikipedia.org/wiki/Common_Language_Infrastructure#...
Anyway — what’s the difference between this and plugins/Java applets (anything that compiles to Java bytecode)/ActiveX?
I suppose the biggest is that this proposes that 1) they have access to the DOM and 2) the browser implements the CLI environment.
I had to explain a good couple times the difference between an application service provider and ASP the IIS thingie.
I really wish they gave up software and kept doing their excellent keyboard and mice.
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?
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.
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.
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.
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.
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.
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.
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.