Miguel De Icaza: CLI on the Web.
tirania.org
tirania.org
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.
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.
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.
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.
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.
But it's a virtual machine too, among other things.
> Noone suggests C# in this comment thread
It is suggested in the post as one of the possibilities: We could replace `csharp' with any of the existing open sourced compilers (C#, IronPython, IronRuby and others). Obviously, if we are looking at the possibility of integrating CLI into browsers, C# would be one of the main languages just like with JVM it would be Java, for many reasons.
Re: "will look worse than on Windows" -- I meant in all respects, not just the looks but also performance.
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.
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 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...
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
To call from JavaScript to Java, you can just use the public members of the applet object.
To call from Java to JavaScript, you can use JSObject.
Aside from working around a few minor gremlins in particular browsers, most of the basic things you'd want in this context "just work". In practice, when I'm transferring big chunks of highly structured data from the Java model to views using JavaScript, I use an intermediate layer in the applet that looks up all the relevant data Java-side and builds a JSON representation that is trivial to work with in JS, which avoids any trickiness with things like marshalling arrays and means rendering specialist types in Java world into suitable strings or objects in JS is all done in one place according to consistent rules. This all runs fine on IE, Firefox, Chrome, etc.
The biggest practical problem I've found is that because relatively few people are doing this for major projects, there is also relatively little documentation around on the web (including the official Java pages and the developer pages for the various browsers). That means if you do run into one of the awkward cases, it's not always a five-second search to find the answer. Still, so far I've been doing this for over a year, using the same techniques in a couple of different contexts, and most of the problems with "incompatibility" have quickly been resolved by updating to the latest versions of things.
I they added a few extra bytecodes for stuff like TCO or goto or integers, it'd be pretty fantastic.
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.
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.
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.
You rather proved my point, unfortunately. Web apps are not about "DOM manipulation". They are about delivering no-install applications over the internet. They have historically been about DOM manipulation because that was all they could afford to do performantly (and that only barely at times). As that changes, so does the web. We're getting a ways along this path anyhow (http://code.google.com/p/quake2-gwt-port/ ), just with increasingly fast JS and other tech, but it's only going to grow more.
Replacing the scripting language of a browser does not magically make the applications you describe possible, any more than it's possible to draw high quality vector graphics on a 5250 green screen. You're presuming all sorts of hardware-accelerated graphics, network connectivity, font manipulation and many other fundamental sorts of hardware manipulation that just isn't possible within the confines of (most of today's) web browser.
What you describe is indeed possible, e.g. Silverlight and Air, but putting a new scripting VM in today's browsers is not going to get you there. You're not talking about web applications, you're talking about a new class of web browser.
Are you keeping up with what web browsers are doing lately? They've turned a corner and are burning rubber now that we're increasingly less tied to Microsoft every day, and Microsoft's efforts to hold things back are no longer working. I'm hardly even hypothesizing, you can get demos of many of those things right 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#...
"Microsoft has shot the .NET ecosystem in the foot because of the constant threat of patent infringement that they have cast on the ecosystem."
http://webcache.googleusercontent.com/search?q=cache:O6bmbLp...
Using the ECMA CLI does not include implementation of unprotected (by RAND terms and Community Promise) Microsoft API's. This constant threat doesn't really apply. No, Microsoft could not pull the plug on this.
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.
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.
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.
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?