interpolating the platform

Mark blogged about the new Firefox -app switch, which I think is a pretty interesting thing. Of course, it’s not a substitute for XULRunner, which gives the application developer complete control over important things like the update cycle and process, and it’s definitely not something that we’re recommending people use without a lot of careful study.

This is something that we’ve been asked to provide for quite some time, and even with the tight coupling to Firefox in versioning and launch syntax I think it’s going to be a valuable addition to the repertoire. Here’s how I now see the platform spectrum for our technology:

  • Web applications. If you can do it here, you should. We’re working with other browser developers to develop and standardize new web-platform capabilities all the time, because being able to put your app in this bucket brings a ridiculously large number of benefits for users and developers both. With webrunner you’ll have a way to give users an optional desktop-launch experience that they may be more comfortable with, even.

  • Firefox extensions. There are thousands of them that have been able to build great experiences (and, in some cases, great businesses) with products that are tied to the Firefox maintenance-update rhythm, and we’re seeing more great stuff all the time.

  • Firefox “-app” apps. This is a nice little hybrid where you are still coupled to the Firefox update cycle and so forth, but get more isolation from the browser process and end-to-end control over the UI. As Mr. Finkle said, this is a sharp tool with its handle loosely attached, so please use care when using it. If extensions aren’t suitable for your project because of the update cycle model, then this very much won’t be either. For prototyping, or some extension-like uses, it’ll be killer, though. (I like that the apps are started with “firefox -app”, because it’s another hint that the thing you’re doing is dependent on Firefox, and that changes to Firefox could hurt it. I think it would be more confusing to have it be called “apprunner”, f.e.)

  • XULRunner apps. I need say little more on this topic; Joost and Songbird and Komodo and Miro and…yeah.

By no means do we expect, recommend or condone XULRunner-grade apps being moved to this model without extreme care, but a lot of people building such apps, especially smaller ones, have been asking for a way to piggyback off Firefox’s awesome update story while still having their own top-level chrome.

lighting a candle

There’s going to be a lot of reaction today to Mitchell’s post about Mozilla Foundation investment in XULRunner (Daniel and Alex have already posted theirs, keen folk that they are), and I’m going to be spending the next 7 hours travelling, so I’m going to rush this note out and find out later if it helps or hinders. Exciting!

Hearteningly, I think that people are misunderstanding what exactly is being not done here. Mitchell’s post defines a “standalone XULRunner” as:

[...]an instance of XULRunner that various applications would expect to find on a machine and would share once found. This would allow distribution of a thin “application layer” only, which would then take advantage of a stand-alone XULRunner already on the target machine.
When Mitchell says that the Mozilla Foundation (and, by extension, the Corporation) are not going to invest in a standalone XULRunner, that “XULRunner runtime”, à la the JRE or .NET, is what she’s primarily contrasting, IMO. Daniel’s post seems to be more interested in something much more modest, such as a zip file or DMG that you can take, drop your application.ini and custom code into, repackage with some magic dust, and be done with. I do not read Mitchell’s post, nor do I understand our intent, as “waving off” code that would make that process smoother, nor of presenting any barrier to having the resulting code hosted in the Mozilla CVS repository. Her explicit mention that
clearly understood bug fixes should be a good candidate for immediate check-in whether or not the bug affects Firefox or any other Mozilla Foundation application
should be noted well here. Daniel’s example of improved installation support for “generic” extensions is an example of work that fits this pattern exactly, in my considered opinion, and I would not expect this announcement or direction of Mozilla employee cycles to add any new impediment to that.

(I think in hindsight that the use of the term “packaged XULRunner” or “standalone XULRunner” in this way is probably not as clear as something like “system XULRunner”, though I have become comfortable with the term myself over the last little while. The expectations for a “system XULRunner” are quite high, and it’s that significant and not-well-understood deliverable that the Mozilla Group of Companies is not investing directly in right now.)

It’s also important to appreciate that projects can be very successful in the Mozilla community without being Mozilla Foundation products. SeaMonkey is a great example of a group within the Mozilla community that has shown leadership and motivation in developing, supporting and marketing a piece of software that doesn’t have any Mozilla Foundation employees tasked directly to help it — though some Employees do indeed work primarily in the context of that product as a personal choice, and that’s a fine thing. A XULRunner community can and must exist independent of, though overlapping with, the Mozilla Foundation’s own direct technical investment.

My cab is here, so I must run, but I don’t think that things are as bleak or hostile as some others do. I think that the next few weeks and months will bear out my understanding and expectations, and I’m committed both professionally and personally to helping that they do.

the high cost of some free tools

(This is going to be a little long, for which I guess I could apologize, but it’s my blog, so whatever.)

So let’s try this one on for size, because everyone is offering the web developer a set of tools to lure them off the web. You’ve got your silly season participants, and you’ve got your — no, honestly, grown-ups came up with this name — JavaFX Script stuff, and they all want you to give up this archaic web thing for something so much shinier, and faster, and man have you seen the cooking-show demos?

You can point and you can click, and you will get an application, and it will run on the web (says Silverlight, because Microsoft has always been about the web: they were just getting up a good head of steam when they left IE6 dangling for years; they were always planning to come back) and on the desktop (says Apollo, because Adobe is best known for its “web” stuff in this space, but when Silverlight comes to the web, I mean, what would you do?). And it will be glorious. You will have graphics and drag-and-drop widgets and you can bet there will be pretty colours and probably a billion language choices, and if it doesn’t generate the cutest little installer then you can have your money back.

Adobe and Microsoft have always had better tools, in part because they’ve staffed and organized hard against them, but also in large part because their platforms require tools — that’s a big part of their business model. I don’t think you should need to buy, or even use-for-free, any given tool to build the web, and by using and helping to drive open web technologies Mozilla lets people choose the tools they want to use. We don’t force you to use the ones that we make money or marketshare on: you can use Eclipse or Firebug, Rails or J2EE, Komodo or Notepad, YUI or Dojo. If you ask the people who are building the exciting and significant apps on the web today, be they gmail or eBay or twitter or facebook or flickr or even Windows Live Search, I bet you that vanishingly few of them use IDEs. They use the tool that works best for them, for a given problem, sometimes using a bunch at once. I would be very surprised to discover that all of a given team even uses the same text editor, to be frank.

(We also don’t make you sign licensing agreements to get the format specifications, or prevent you from competing with us. We don’t tell you where you can and can’t install the software. We don’t tell you what you can and can’t tell people about your experiences, or that you can’t give it to other people with whom you might want to collaborate.)

If you choose a platform that needs tools, if you give up the viral soft collaboration of View Source and copy-and-paste mashups and being able to jam jQuery in the hole that used to have Prototype in it, you lose what gave the web its distributed evolution and incrementalism. You lose what made the web great, and what made the web win. If someone tells you that their platform is the web, only better, there is a very easy test that you can use:

Is this the web?

When the tool spits out some bundle of shining Deployment-Ready Code Artifact, do you get something that can be mashed up, styled, scripted, indexed by search engines, read aloud by screen readers, read by humans, customized with greasemonkey, reformatted for mobile devices, machine-translated, excerpted, transcluded, edited live with tools like Firebug? Or do you get a chunk of dead code with some scripted frills about the edges, frozen in time and space, until you need to update it later and have to figure out how to get the same tool setup you had before, and hope that the platform is still getting security and feature updates? (I’m talking to you, pre-VB.NET Visual Basic developers.)

Mozilla has always valued and supported web developers, and in turn those who support developers with tools and other assets, and we’ll invest more in this area over the coming year. But we’ll do it in a way that makes sense for the whole web, and brings to bear the human-manipulable power of web technology: a great set of primitives that people combine in very different ways, giving developers a great opportunity to choose tools and toolkits and patterns and technology that suit how they want to work and what they want to build.

The web can eat toolchain bait like this for breakfast. And, if Mozilla has anything to say about it, it will do just that. You won’t have to give up the web to work offline any more, or programmable 2D graphics, etc. Soon you’ll have the power of 3D and great desktop/application integration as well, via projects like canvas3d and registration of content handlers, and you’ll have it in a way that’s built on open specifications and a tool ecosystem that isn’t a monoculture. Why wouldn’t you choose the web, given its record and power and openness?