Brendan Eich always delivers on a great keynote, and to conclude the opening day of the show, he had some announcements up his sleeve.

Mozilla has three monkey’s up their sleeve:

Iron Monkey

Mozilla is taking IronPython and IronRuby produced from Microsoft and mapping it to to Tamarin. This will by in the guise of bytecode translation a la IKVM as they want to avoid forking C# source using Mono C# compiler. The project is led by Seo Sanxiym of FePy and PyPy fame. Brendan made a subtle jab at how “open” the source is for the Iron projects. Although the license is liberal, what does it mean if you don’t accept patches from the community?

This is big news as it means that Python and Ruby can really be in the browser, for both IE and Firefox (and …)

Screaming Monkey

In response to Ted Leung, and the communities voice saying “Tamarin. Great. But, what does it matter if IE is still slow as a dog?”, Mozilla is launching a really ambitious project to have Tamarin run inside other browsers other than Firefox.

This means that Tamarin will be usable in IE, which is the first target via the ActiveScript engine. This project is lead by Mark Hammond of Windows Pytohn fame.

This is big news as it means that there is a path around Microsoft stalling in the browser. If they use Silverlight to bring a nice CLR JIT for JavaScript – great! If they don’t, we have Tamarin. What about deployment? Well, in theory Adobe could use their Flash install base to get this distributed to 90% of the web in short order.

Brendan expects fruits of this labour to be available in 6 months. He also showed a port of a Silverlight application running on Open Web technologies, showing that we have a lot of good stuff available.

So that IronRuby thing means that we can use Ruby as we use Javascript in the browser today?

Comment by Pedro — July 26, 2007

Ibod,

I do too.

Comment by Mansfield — July 26, 2007

@Pedro
That IronPython/IronRuby stuff sounds pretty sweet. I hope they support C# too if they’re supporting the .NET DLR though (something Microsoft should have done along time ago, C# and the .NET CLR/DLR is the best dev tech out there, why can’t they just hire the Mono guys and make it officially multi-platform?).

Yes, my head is big — family photographs from my mom’s side show large foreheads. My son inherited this (my wife won’t let me forget :-P). But some things can’t be helped.

What can be helped (the purpose of these announcements) are open source projects such as Action/Iron/ScreamingMonkey. Here is a way for those of you who have C++, Python, Ruby, and even C# chops as well as Ajax/JS skills to make a difference.

My head alas won’t shrink, but with some effort, Tamarin can evolve into the most widely distributed, multi-lingual, and available (in all browsers) high-performance VM in the world.

â€¦supposedly, from what I have read, the JIT-compiled Tamarin will be like 10x performance increase over current browsers. This news that Mozilla, Eich, et al figured out a way to get Tamarin into IE ..and mention partnering with Adobe (who donated the ActionScript JIT compiler to Tamarin) to deploy it via Flashâ€¦ is hugely inspiring. It continues to show the state of the mindset of this open source community and some key industry â€˜partnersâ€™ (Adobe, Google) â€“ i.e. innovation and performance comes first. (what a welcomed change from the days of MSFT conquer-and-block web strategy — where we saw them even disband the IE team once they gained market share dominance.) Hats off to the leadership we are seeing demonstrated today.

Katy: don’t worry about other languages, you don’t have to use them. It will be a while, probably a long while, before designers and developers could even count on a language other than JS in the browsers that they want their site to support.

But programming languages have their different benefits and costs, and they certainly have loyal fans and somewhat disjoint communities. At the scale of the Web, in the long run, I think we’ll see several programming languages supported on the popular browsers.

I could be wrong, and as JS creator I’m supposed to root for “my” language, but based on desktop and server programming language competition (not to mention Silverlight :-), I think multi-lingual VMs are coming to the browser, and that they’ll be a good thing.

But JS will be the default scripting language of the web forever (as far as I can see), and if it simplifies your life to use JS only, then please don’t worry about other scripting languages.

I’m really not sure I get the point. CLR, Parrot, Java scripting API’s. It all seems like so much bloat to me. I’m glad that browsers after years don’t eat 50% of my cpu and RAM anymore. I’d really prefer they stay that way. Did we really get rid of Netscape Composer to replace it with Ruby, and dump Mail to replace it with Python? Is the idea cool? Yes, but just because something is cool doesn’t mean it should be done. I was happy to hear about Tamarin and Actionscript as Actionscript is what Javascript should actually be but this just seems silly.

Vance: don’t mix up jamming N different language implementations, written in C or C++, each with its own memory management and standard library, into a browser (that would be bloat, as well as cycle-based leak, hell), with extending the one virtual machine to support download-able, memory-safe language implementations (which is what IronMonkey is all about).

We’re not going to bloat Firefox with megabytes of Python and Ruby code. That’s something I’ve already blogged about, regarding Mark Hammond’s integration of the CPython runtime for Python XUL scripting. If you need C-Python, you can get it and add it onto Firefox or XULRunner. But you’re right that it’s too big, and the memory issues raised beyond code size too difficult, to impose it on Firefox or any browser.

…any word this week at TAE on the inclusion/progress in Mozilla’s roadmap towards secure XSS?? For instance, implementing something along the lines of Doug Crockford’s JSONRequest? Dying to hear some news about where this is going, timeframe to impelementation, etc. Thanks for any light anyone can shed on that.

“Brendan made a subtle jab at how “open” the source is for the Iron projects. Although the license is liberal, what does it mean if you don’t accept patches from the community?”
Actually that’s just plain wrong. IronRuby will be hosted on RubyForge shortly and will allow community contributions…Don’t know what the plan is for IronPython, but it would be shocking if MS didn’t allow contributions to IronPython when they do in IronRuby.

Kevin: if my facts are out of date, good for Microsoft for changing their policy — please give a link to an authoritative source if you have one. But as far as I know, IronPython cannot accept patches from people not employed by MS. Your projecting that they’ll change this policy to match IronRuby is nice and possibly even likely to come true, but it doesn’t change the situation for the last many moons.

Our plan is to push whatever patches are agreeable as far upstream as they’ll go, as I said in my talk. It’s not as if we are creating a fork. Because of MS’s refusal to take non-employee patches, Seo created fepy.sourceforge.net. That actually happened, it’s not a matter of conjecture.

@Brendan
Tamarin in IE is a great goal. Funny enough, it sounds like taking IE out of Microsoft’s control :)

However, before adding some Iron to picture could you pay more attention to JS itself? Do you think that JS with its upcoming changes will be great language?

I’m currently working with ActionScript 3.0. This language can be positioned as JS1.6

Comment by Valery Silaev — July 27, 2007

[re-posted]
@Brendan
Tamarin in IE is a great goal. Funny enough, it sounds like taking IE out of Microsoft’s control :)

However, before adding some Iron to picture could you pay more attention to JS itself? Do you think that JS with its upcoming changes will be great language?

I’m currently working with ActionScript 3.0. This language can be positioned as JS1.6

More static type checking is good, but whyvar abc = new SomeObject;

makes “abc” a dynamically typed variable rather then variable of statically infered type SomeObject??? I know, the reason is backward-compatibility, but there is a real-world example of how such goal leads language to grave: Java 5. Scala language has future (yep, it has no legacy to support); the death of Java 5 is just postponed. Do you think that JS will be used in mixed-mode (pre-JS2 / JS2)? Hardly believe anyone will ever try…

Second, I’m not great fan of Ruby, but some syntax ideas in Ruby are extremely useful and natural. Compared to Ruby (or Scala) expressiveness and brevity the line below (AS3/JS2) just make me sick:override public function get someProperty():String

Hey, I must say 4 (useless) words to simply override a property? I’d rather program Ajax in SAP ABAP…

VS

Comment by Valery Silaev — July 27, 2007

Valery: I hear you on the keywordy-ness of AS3 and indeed the old “JS2” proposals from Netscape on which it was based. We will see what can be done to reduce this cost, but note that it’s only in the nominal type system (classes and interfaces). Object initialisers can have {get p()…, set p()…} and be done.

You should join the es4-discuss at mozilla.org list (usual mailman -request subscribe message protocol). A lot of what we are doing in JS2/ES4 is in fact thinking about how untyped and typed code can interface, because we expect untyped objects to be common forever. I talk about this briefly in my TAE slides. But please join the es4-discuss list, we can hash things out better there.

This is really interesting news for me. Indeed news and indeed interesting :) Definitely, have to check this mailing list archives to keep myself up to date.

VS

Comment by Valery Sialev — July 27, 2007

The more languages developers have, the better. Comments on memory footprint are correct but in order to get such expressive and powerful language as Ruby (or Python) for client-side web developement is well worth doing.

Some of you may be wondering why we are only accepting contributions into the libraries and not the entire compiler. It’s because IronRuby is built on top of the Dynamic Language Runtime (DLR), and the public interfaces to the DLR are not complete at this time. Since the DLR will ship as part of the CLR in the future, we cannot accept contributions into the IronRuby compiler, at least initially. However, once the DLR matures and reaches 1.0 status with fully supported public interfaces, we will fully open up all parts of the IronRuby project for external contributions.

This is not surprising, and it may even be well-motivated on technical grounds — but in my experience, it’s a mistake to hold back anything when opening up source.

Ed: I hear David Nick Main of JavaSWF fame is working on JVM -> ABC translation targeting Tamarin, no SWF envelope.

As Brendan seems to be following this thread, here I go: maybe I’m being a little dense but I’m not sure I understand what this is about. I thought IE had been open to alternative scripting languages forever (through the Active Script interfaces and in contrast to about any other browser out there). It supports only JavaScript and VBScript out of the box but Python and Perl were among the first to be supported thanks to ActiveState’s efforts. Is it the deployment of a new language that is made easier here or am I missing something?

Bertrand: yes, ActiveState made Perl and Python engine handlers long ago. But those are not used in the web. Why not? Think about possible answers to that question, about how the problem of distribution often dwarfs any software engineering challenge. Then re-read Dion’s paragraph:

This is big news as it means that there is a path around Microsoft stalling in the browser. If they use Silverlight to bring a nice CLR JIT for JavaScript – great! If they don’t, we have Tamarin. What about deployment? Well, in theory Adobe could use their Flash install base to get this distributed to 90% of the web in short order.

We need proper Browser Javascript engine support and decent Javascript writers first, more languages will only cause use, debugging and memory chaos, for Browser users, Browser developers and website developers, and just lead to even worse f**k ups than current websites!

BTW AJAX is the wrong solution, the browser should not be used to run server code, it clogs up the browser and provides too many opportunities for security issues! If you need rich applications, provide web launched rich desktop clients or proper application support in the browser!

Comment by infernoz — November 18, 2007

I have tried many browsers since their launch like IE, Firefox, Google Chrom, etc but i have always like the FIREFOX..so have relaly loved it.