[viraptor]

Your comment confuses me. CLI-compatible languages compile into CIL, which is a well defined language and is almost equivalent to the bytecode produced from it. So the whole idea could be implemented as a .NET bytecode runner. You could implement the Java runtime using it. The number of actual classes needed to make it usable is minimal. (you need basic types really - a new profile could be created for that and web objects mapping - .net-web)

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.

[mmastrac]

CLI might be well-defined, but you're going to have to implement this VM from scratch in every browser on top of the existing JS VMs. Alternatively you could ship the same VM code with every browser (unlikely - hasn't happened for JS yet) and now you've got two VMs running in every browser with twice the surface area for bugs and security exploits.

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.

[viraptor]

I think that [a well designed bytecode + VM modification (current JS VMs aren't really designed to run from bytecode) + implementing global cache] is more work than [creating a mapping / compiler from JS to CIL + creating a stripped down profile]. The second option does not require big redesigns, room for incompatibilities, etc. JScript.NET might have some compatibility problems, because it started before the proper DLR - a new, clean mapping would be better. Also a new mapping independent from MS would be preferable.

I don't see the problem with legacy baggage though - you don't have to ship all classes. Stripped profiles such as Compact Framework for handhelds have been already created - there's nothing stopping people from creating a new one for the web. The DLL point is a bit moot - it's just a wrapper, it works. If it's too much overhead, you can start sharing the CIL itself instead (the content is standardised afair).

You win a common execution environment. You proposed a common bytecode, but there are only so many ways in which you can implement the runtime environment in that case - each opcode has to be precisely defined. Even if each browser implemented their own, it would most likely be a complete engine redesign with very limited current code reuse. They'd have to either create everything from scratch, or reuse (for example) the DLR and CLI and implement the JS -> DLR compiler on top of them. So that's exactly what you win - not doing everything from scratch.

[mmastrac]

Many VMs are designed to run from bytecode. This is true for Squirrelfish (Safari) and TraceMonkey (Mozilla), though V8 compiles directly to machine code. The bytecode isn't compatible, but it's not a stretch to imagine a JS bytecode language would be similar to these current IRs:

http://webkit.org/specs/squirrelfish-bytecode.html

https://developer.mozilla.org/en/spidermonkey/internals/trac...

Anyways, I still believe that shipping an existing VM, be it .NET's CLR, Java's JVM or Python's bytecode isn't the right way to go. There's a lot of innovation left on the current web platform - both in terms of the performance work that browser vendors are pushing out and the new desktop APIs that the admittedly slow web standards committees are publishing. In the case of a platform as wide as the web, it makes sense that browser vendors sit back and built something from scratch.

[mojuba]

Then LLVM is as viable an option as JVM and CLI. Even better, it's open-source and not committee or corporation-driven. And from the political point of view, once LLVM finds its way into Safari (very good chance) then Firefox and/or Chrome, consider the problem solved. I think this idea is brewing somewhere right now, it's too obvious.

[viraptor]

LLVM is not an alternative to JVM/CLI in any interesting way. It's too low-level. It doesn't provide memory management, introspection, loading, etc. It's just a compilation target really. LLVM has no dynamic features either.

[olsonjeffery]

Yeah.. no. Another commenter already pointed out the issues with llvm being too low-level.. regarding the cli and "open source"... mono is open source in every sense of the word (lib and runtime are mit.. c# compiler is lgpl).. the runtime spec is committee driven, true.. but so is the javascript language.

As for apples investment in llvm: and? Your speculation that it could be used in safari, presumably for squirrelfish, is about as unfounded as the assertion that ecma is plotting a coup by switching from is to ecma.. if you have links to the contrary, ill be happy to eat my hat, not to mention learn how llvm is useful in this space.

also, to understand just how much fun llvm can be, take a look at unladen swallow.. there are major RAM and binary size bloat issues without the corresponding speed increases, currently. Maybe it'll get better, I don't know.

Anyhow.. if the cli were a browser standard then MS could use .net in ie and everyone else could use mono .. wouldn't be perfect ill allow.. but its better than a bunch of incompatible, dialling javascript VMs. Perhaps.

Will never happen of course, but one can always dream.

[mojuba]

LLVM may be a bit immature at this stage, true. Then let's look at CLI/C#.

We don't know what patents are there kept in Microsoft's backyards. For one thing, Microsoft is not interested in supporting any technology or product other than theirs, and we know they will do everything to promote IE and kill competition at any cost. Just imagine for a moment Microsoft caring about how smoothly C# runs in Firefox on Linux. As French say, "impossible".

I don't trust them. And Mono is a Trojan Horse, thankfully not as popular and robust as it could (should?) be in principle.

Note that I don't mind the technology itself. C# is neat ("not my style" though), CLI is pretty fast, and they both play nicely with Windows. C# applications in general are smoother and faster than Java-based ones. Love the results. It's just that any port to other OSes will look worse than on Windows, with or without Microsoft's participation.

[viraptor]

You're either a troll, or you don't understand what we're talking about. But just to keep things correct:

LLVM is not immature - it simply has a completely different goal than JRE, or .NET.

Noone suggests C# in this comment thread - just the runtime environment for the IL bytecode. MS wouldn't have to support it, because IL is an open standard, which anyone can implement. I wouldn't expect MS to get involved in that project at all. GNU project has a gcc-cil implementation - if CIL is clean enough for people at FSF, I'm not sure what problems do you see...

"not as robust as it could be in principle" has no actual information in it. Try listing specific features and reality and not general terms which can be always true and false depending on your point of view.

In "will look worse than on Windows" I assume you're talking about the GUI. In-browser virtual machine for running javascript does not require any interaction with GUI apart from that exposed by the browser. It cannot look different than any other implementation, because there is no display code there.