4 posts tagged “firefox”

Opera just launched their alpha of Dragonfly, "the foundations of Opera's upcoming Developer Tools", which prompted Tom to note that

"Firebug seems to have defined the universe for this lot."

('This lot' includes Safari's Web Inspector, which is actually not that similar to Firebug - the JS debugger is a seperate app for a start - and IE8's developer tools, which I really should look at once I get a disposable Windows image.) It means that all four of the major browsers now ship with developer tools - an impressive change in the last year.

Tom's observation is mirrored by Michael Smith of the W3C: in his XTech presentation when he says that Firebug sets the standard by which all web development tools are to be judged.

The discussion reminded me of Steve Yegge's point in his long, but worthwhile, post about XEmacs in which he said

IDEs are draining users away, but it's not the classic fat-client IDEs that are ultimately going to kill Emacs. It's the browsers. They have all the power of a fat-client platform and all the flexibility of a dynamic system. I said earlier that Firefox wants to be Emacs. It should be obvious that Emacs also wants to be Firefox. Each has what the other lacks, and together they're pretty damn close to the ultimate software package

To be honest, I suspect what he really means here is Firefox + Firebug. At least, if he doesn't mean that, he should be. For me, doing serious web development now requires that combo, even though I dislike Firefox otherwise.

The really interesting point for me is that Firebug, unlike the three other browser development tools, is actually not under the Mozilla Foundation's control. Firefox ships with a DOM Inspector, but this is more of an internal developer tool. Firebug, a third party tool, builds on DOM Inspector's abilities, and it's built for Firefox because Mozilla have developed not just a browser, but a platform. Maybe when I criticised Gecko for their choice to build a platform as well as a browser I was missing something very important.

That extensibility means more than just Firebug, though. If there's a browser that you want to rewire from inside, using the same tools as you do to create web pages (more or less), it's the one from Mozilla. This is where Yegge is coming from, and I suspect that, hidden in a long post that's titled to attract only command-line editor users, it's a point that's likely to be missed.

Earlier this week, I published a post entitled Hackability: Gecko vs WebKit. Actually, it sort of snuck out in the middle of the night; as is my wont, I left it as a neighbourhood-only draft overnight, only to find that Simon had turned up and made some of the points I was going to go back and edit in as a comment. Since nobody ever reads comments on the internet, and also since Simon, Tom and myself had a bit of a discussion on the subject on IRC, I thought I'd follow up the post with some further thoughts.

Firstly, Simon made further mention of Gecko 2, the next-big-thing coming from Mozilla. It does sound like it's going to be a great deal of work, and that it's probably dumb for them to be gung-ho about fixing some of the Acid3 issues in the 1.9 branch when 2.0 is around the corner. On the other hand, the very fact a 2.0 is needed is a bit worrying, and I'd also argue that perhaps there should already be a code branch being worked on. In comparison, I strongly suspect that the WebKit team have been lucky enough to time any major reworkings of their codebase to be out of the public eye.

Secondly, Gecko and WebKit both turn out to be about the same age- nearly ten. Admittedly, KHTML was initially much more minimal¹. On the other hand, this turns out to be key to the point I really should have made in the first post.

One of WebKit's stated project goals is hackability. In contrast, Gecko's layout engine doesn't really have a project page; the closest thing there is to one admits that

much of the code for the cross-platform toolkit is mixed in with this code, it is described elsewhere

This is really, I suspect, where the two projects diverge. WebKit is designed as an embeddable renderer. It's pretty modular - one of the KHTML legacies is that the JavaScript implementation is separate, as you can see from the fact that Quartz Composer embeds JSCore but not WebKit. It does one thing, and does it pretty well. (The same is somewhat true of the most common browser using it, Safari.) Given this, it's no wonder that it's adding features and passing tests at a rate of knots.

In contrast, Gecko is part of Mozilla's platform. It's a fairly major part of XULRunner, a cross-platform application framework that hosts Firefox, Thunderbird and other apps. That makes it big and gnarly, and probably makes it harder to work with, but it also offers a great deal of flexibility. Firefox is so extensible because the UI is itself written in a markup language, and it can be modified and extended without learning (too much) new stuff. In contrast, there are no supported ways to extend Safari's interface².

So far, I think we all agreed. Different goals lead to different priorities, and as Simon put it:

Teams focus on different things. saying "Well it's Apple's policy not to do plugins" is like saying "It's Mozilla's policy not to spend resources on what could quite reasonably called a PR exercise" but, as we know from Perl, PR exercises and easy hackability keep a project alive.

Where we parted company was that Simon argued one of the keys to the success of Firefox was this extensibility. Since it comes at a cost, it would be good if one could argue that it had also had a benefit. Unfortunately, personally, I doubt that the success it's managed against IE (which, compared to the market share of its prehistoric ancestor, Netscape Nagivator, isn't actually that good - although numerically I'm sure Firefox has more installs than Navigator ever managed) has anything to do with extensibility. Do real people install extensions - even lauded ones like Firebug and AdBlock? Somehow, I doubt it.³

No, the success of Firefox is down to offering a familar enough UI (Opera fails here, however compelling the features are once you get through to them), free (again, until recently, an Opera weakness), and with better security than IE (perhaps less so now, but older versions of Microsoft's browser didn't get their reputation for nothing). That's not to say that the work on XUL isn't good - extensibility helps get geek mindshare, just like passing Acid tests - but again, I do wonder if it's costing more than it's worth. After all, if easy hackability keeps a project alive, what does a lack of the same do?

¹ A fair chunk of the discussion was about how KHTML and WebKit were related. I don't think it's particularly relevant here and nobody bothered with the relevant Slashdot forensics, so I'm going to skip it.
² Hopefully that wording is clear enough to be understood as meaning "things that aren't browser plugins". I believe that none of the other WebKit based browsers offer much of a UI customising API either.
³ I'm more willing to believe they install themes. Shudder.

This post has been brewing for a while, but I've been prompted to actually write it by seeing John Gruber's offhand remark on his most recent linked list entry, about CSS gradients in WebKit:

Just me, or is WebKit racing way ahead of Gecko in terms of support for cool new stuff?

No, it's not just him. WebKit, and Opera's layout engine Presto, raced towards Acid3 compliance in March, with both effectively reaching a photo finish on the 26th. Meanwhile, Microsoft hasn't even shipped a non-beta Acid2 passing browser¹; no surprise there. But where's Gecko, the Mozilla layout engine, the one that powers Firefox?

Well, to be blunt, it doesn't look as if they care much. We have one developer saying that Acid3 is basically worthless, and another (more diplomatically) stating that it's a missed opportunity and an exercise in making browsers jump hoops, rather than improve "real" functionality. As others (almost certainly more qualified than I am) have noted, this sounds a lot like the noises from Microsoft around the time of Acid2's release.

The thing is, I'm not here to kick Gecko, but to understand its problems, if it has them. Does the team's response to Acid3 mean it does? Possibly not on its own, but coupled with events like the move of Epiphany to WebKit², and the aforementioned speed of development on WebKit (and to a lesser extent Opera's Presto³) I have to wonder. Why is development there so slow?

One stated reason is that the Mozilla Foundation is on a rush to release Firefox 3, and it's certainly true that it is coming up for release. On the other hand, Apple certainly seem to be able to keep the open-source WebKit tree distinct from the version used in releases - Safari 3.1 shipped with an Acid3 score of 75 when nightlies were scoring 90-odd - so I should hope that's not the real reason. Maybe they're pulling people off the layout engine to work on the browser? That's not as stupid as it sounds for most apps, given the way the Firefox UI is set out using XUL, a markup language. Even so, it feels like a bad use of engineering. Maybe Gecko's reached that point where extending it's no fun. The language the team themselves uses, with talk of Gecko 2, makes me wonder if that's true.

I don't have answers, anyway, but I'd love to hear from people who do why Gecko is giving the appearance of stagnation, while WebKit seems full of life.

¹ Bafflingly, it seems that Microsoft develops not one, but four layout engines: Trident, for IE/Win, Tasman, originally for IE/Mac and now part of Office:Mac, and two unnamed engines, one in Word and Outlook 2007, and another in Expression Web Designer.
² Admittedly that's got contributing factors beyond merely Gecko; it sounds like the wrapper they were using to embed it (GTKMozEmbed) had some seriously nasty issues of its own.
³ I mentioned to Tom Insam that I was surprised I'd never heard of the name of this engine, but he sagely noted that, as it's not open source or embeddable, there's no reason I would have.

Firefox 2 came out on Tuesday. Even if I hadn't been silly busy at work, I wouldn't have installed it.

People who know me will be aware I still run Mac OS X 10.3.9, because 10.4 doesn't look worth it as an upgrade. (Well, it does now, but that's because (Mac?) developers are a bunch of magpies who love the new shinies; who'd consider coding for something two years old now, when it means you can't use Core Data? Get with the program!) At work, I run Windows XP with the Windows 95 theme, because it doesn't make me feel like a toddler (and it conserves screen space too).

Therefore, finding out that I spurn an "upgrade" to the browser I use all the time at work because it's fucked up session management, tab handling, and the fact it's had a reskin that also comes from the Fisher Price school of interface design should come as no suprise to anyone.

Oh, IE7? Well, even it it was supported by the IT staff (which it isn't), that ribbon looks even more eye-pluckingly awful than the Firefox 2 default. I bet you can tell how big a bargepole I'm not touching that with.

Why, yes, I do generally hate software. How did you tell?