Forum: Weblog comments

Robert,

let's be straight. Mozilla.com's mission is gain market share for Firefox. Nothing else. Even if they wanted to focus on more projects like Thunderbird, Sunbird, Songbird Whateverbird, they don't have the resources to do that.

There is no diversity. And with seamonkey you can be happy that it's mentioned at all on mozilla's project pages. As I said yesterday in another comment, I think it's a big mistake to neglect the power of the Gecko platform. But we are where we are. Maybe another CEO will lead Mozilla to more diversity.

Pete

OK, I've been tossing this idea around for a while, and this seems a good place to exposit.

What if 'gecko' was its own standalone bit of software? Obviously, running 'gecko' on its own wouldn't do anything, but let's say you ran something like:

$ gecko firefox.com/version6.html

And up pops Firefox 6.

Pete:
Believe me as someone who's seen a real lot of the Mozilla project and been with it for more than 10 years. Firefox market share is an instrument for the mission, but market share is not the driving force behind what's happening, the mission is. And diversity is a huge part of that.

voracity:
Your idea would make things more complicated for users, which is a no-go. If we make things complicated for users, we'll die and our mission with us.

I miss when Mozilla was not an end-user product. Things were so much cooler (and geekier) back then.

I think you've misunderstood my intent. The user wouldn't run that command, of course. They would download an installer to get Firefox, or just use the internal update --- as always. Nothing at all would change from a user's perspective (if they're not interested in learning how to hack).

However, tinkerers and developers and alternative browser developers (such as yourself) could run that, and they could host almost the whole browser online. The gecko engine (acting like a low-level OS) would just need to be a) Turing complete :), b) fast, c) provide decent APIs for all of the computer's hardware and d) be a little bit of kitchen sink with respect to the HTML/CSS/Javascript/etc. features it provides.

Doing it this way would also force the browser developers to dogfood their own engine *as* an application engine --- a little like XUL, but with the kind of remote access that websites have to deal with on a daily basis (and that browsers still don't). Browser developers would be forced to create great application caching systems, lag-free and uncomplicated client/server architectures and well-defined security boundaries --- because that's what they have to do to make their own application!

Let's face it, every computer scientist's ultimate goal is to self-host their own software. That's what my suggestion is about. The user won't notice any difference (except for a faster rate of improvements) but the developers get access to the ultimate form of hackable and rapid development system.

voracity:
So, what you want it XULRunner, then.

Reality is that we're currently going in the way of making that somewhat obsolete, though, as it unfortunately has a speed penalty over linking things even more statically together - and right now the thought in Mozilla land is that speed is one of the primary things the "new browser wars" will be decided on.

Heh, actually, it's more like a HTMLRunner. The difference is important, because XUL is non-standard.

Your right, speed is crucial, and that's part of the point. If browser UI developers have to do the *exact* same things as web developers, then they will solve a whole heap of speed issues for their browser applications that will *also* solve the speed issues that have been plaguing web developers with their web applications for years. (Thankfully, that's already been happening for a couple of years.)

In addition, it will also make hackability a whole lot more accessible than the current XUL-based Mozilla browsers. In this regard, there are a lot of similarities to the whole Jetpack vs XUL-based extensions approach. Indeed, if the browser were built from HTML, there wouldn't even *be* a Jetpack vs XUL-based issue. Again, that's why a HTMLRunner is different to a XULRunner.

HTML is crap for UI design and its completely crazy syntax for things like <input> would drive me away from any UI work if that would be based on the crippled and document-oriented markup language HTML is.

XUL is the best thing since sliced bread, at least when it comes to UI design.

Right, so any sane browser developer forced to use HTML for their UI would port the necessary non-standard features from XUL into the HTML standard, meaning that millions of web developers can enjoy those delightful XUL features (like flex-box).

I will leave the discussion there, as I think we are coming at this from perspectives that are too different to be reconciled by a sequence of short comments.