Google’s newly-announced browser, which bakes in a JavaScript-specific virtual machine, reminds me of an earlier era in which the Netscape browser baked in support for the Java VM. It makes perfect sense for Google under the circumstances, but also serves as a reminder that language-specific runtimes aren’t the only game in town. From that perspective, it’s worth recalling that Silverlight is based on the .NET Common Language Runtime, a multilingual engine that can accommodate languages ranging from C# to Ruby while leveraging a common set of libraries and a common security architecture.
It’s true of course that JavaScript is the web’s original and predominant mechanism for injecting active behavior into otherwise static web pages. But the web’s evolution — from a collection of hyperlinked documents into what is now also becoming a collection of applications and services — is ongoing. The capabilities of both the HTML+JavaScript layer and of the plug-in layer — where Flash and Silverlight reside — are evolving too. And the boundary between those layers is being redrawn.
Google’s new browser runtime aims to improve the HTML+JavaScript layer in a way that further enshrines JavaScript as the web’s programming lingua franca. Meanwhile, Silverlight 2.0 and the Dynamic Language Runtime aim to improve the plug-in layer so that other languages — including dynamic languages like IronPython and IronRuby — can be used to activate the web. As both efforts go forward, it’ll be fascinating to see just how that boundary between the layers does get redrawn.
September 2, 2008 at 1:32 pm
Ugh, you’ve totally swallowed the MicroSoft pill — your assimilation is complete.
1. MicroSoft is not the only multi-language VM in town — take a look at all the languages that are being dropped on top of the Java VM, which is commonly regarded as the best VM around (full disclosure: I don’t even use Java).
2. MicroSoft has abused the developer and user communities at large too badly to regain their trust. Sure, their are A LOT of MS developers out there but there are a ton more that are not MS (or exclusively MS) developers. Last I checked, the web was still dominated by the LAMP stack. Sure, Silverlight is cross platform… however, MS has demonstrated that they can’t even make PowerPoint or Outlook/Entourage work consistently on Windows and MacOS.
3. MicroSoft has a clear bias (and probably should) on the success of their Windows platform and, likewise, the downfall of other platforms. What possible motive is there for providing a solution that works equally well on all platforms? For example, if MS were to have two tasks to consider working on — (1) fix some display problems for Linux and (2) improve the performance for Windows — which would get priority? The *real* answer isn’t even important — the outside world “knows” that MS will work on #2. They just don’t play well with others.
Your views and commentaries used to be much more balanced. I miss that.
September 2, 2008 at 3:51 pm
Gee, thanks Google. I feel about this the same as I felt about AJAX.
The longer we are stuck with HTML, Javascript, CSS, and other hacked technologies the more I want to quit programming and drive a forklift for a living.
September 2, 2008 at 3:53 pm
I am very suspicious of Google’s intentions. I bet there is no capability to block ads. Are they just trying to create an alternative to Silverlight and Flash?
I also wonder if the new javascript JIT is secure, kind of scary executing machine code from a browser using a totally new tool.
Besides, any new concepts will be picked up right away by Firefox, and in a few years by Microsoft.
September 2, 2008 at 4:20 pm
> the Java VM, which is commonly regarded
> as the best VM around
Since long before joining Microsoft, I have been noting that the multilingual capabilities of the JVM are bolted on, not built in.
> Last I checked, the web was still
> dominated by the LAMP stack.
And that’s part of my point. There’s a ton of server-side Python and Ruby. Bringing those languages client side is an interesting way to leverage those skills and reflexes.
Opening up such choices is another aspect of the continuum of access styles (http://blog.jonudell.net/2008/08/27/the-continuum-of-access-styles-in-the-emerging-microsoft-cloud/) I mentioned the other day.
September 3, 2008 at 2:57 am
The DLR is just as “bolted on” as anything comparable on the JVM. Where DLR has an advantage is that it’s funded by Microsoft, who has multiple different language folks working on it, and that it provides a unified version of what many JVM languages develop and cultivate independently. It is not built into CLR in any way, and even if it were shipped with .NET it still would be simply part of the runtime libraries.
The JVM (in the form of HotSpot), on the other hand, is already essentially a dynamic language runtime under the covers. Any code loaded at runtime is enlisted in dynamic optimizations, which means that e.g. JRuby just needs to present Java bytecode and it will be optimized like any other piece of Java code without any of the tricks that are essential in the DLR. Where it’s more difficult than it should be is in the fact that there’s this nasty static-typed layer wrapped around the JVM (i.e. Java), but optimized dynamic invocation work (hopefully to be in Java 7) will eliminate that issue as well.
September 3, 2008 at 9:38 am
You said it better, Charles, thanks. I guess we could say that multilingual capability, for static and more recently for dynamic languages, has been a higher priority for the CLR than for the JVM, though I know the priority is changing for the JVM.
How these capabilities can and should be used in general, and specifically both in the cloud and on peers — these questions interest me a lot.
September 3, 2008 at 3:54 pm
My understanding is that the v8 runtime can support multiple languages, not just javascript. I don’t know of any google plans for that, but it is open source with some decent documentation. There are also some nice isolation capabilities that seem a little more simple than those planned or in the jvm or clr.
Jon wrote:
“How these capabilities can and should be used in general, and specifically both in the cloud and on peers — these questions interest me a lot.”
I think this is the key issue, yes. So far there is one reasonable RESTful client application: the browser, generally. (Well, and email clients, arguably.)
Good RESTful clients should be more secure than the browser, more “rich” than the browser, and more easily programmed than the browser (i.e. easier and more expressive than ajax). Good RESTful applications should not require “one-off” programming on the client side. Nor should they expect all the client components to be developed in any single language, or run in a single runtime container.
September 3, 2008 at 5:20 pm
One interesting way to bring multiple language to multiple back-ends would be PyPy.
It is a language agnostic toolchain where you ‘describe’ an interpreter in RPython and it can generated them for a multitude of backends (.NET, C, JVM).
There is already talk of a Tamarin backend and V8 one would probably be possible.
On the front-end there are already Python and Smalltalk interpreters. Ruby and others would also be well possible.
September 3, 2008 at 8:06 pm
Supplying a VM in the browser does enable all sorts of client-side, desktop-like behavior… but has anyone else begun to notice that page load times are increasing as all of the script language gets loaded with the page?
Next up: browser code which virus-scans dynamic languages on the fly (or do those already exist)?
September 4, 2008 at 4:10 am
@Tim
Well, the whole point of sandboxing is that you don’t need virus scanning…
September 4, 2008 at 10:13 pm
[...] Udell -Activating the web: One programming language or many? on the V8 javscript VM from [...]