This is a loose follow up to GNOME and the cloud. You might want to read that post first.
There are 2 ways to provide access to the web for GNOME. One is to integrate into an existing framework. The other is to write our own. I think I can safely ignore the “write our own browser” option without anyone complaining.
I know 2 Free projects providing a web browsing framework that we could try to integrate into GNOME: Webkit and Mozilla. I’ve recently talked to various people trying to figure out what the best framework to use would be. As it turns out, there is no simple answer. In fact, I didn’t even succeed in coming to an opinion for myself, so I’ll discuss the pros and cons of both options and let you form your own opinion.
current browser usage in GNOME
GNOME’s web browsing applications currently use a Mozilla bridge (epiphany, yelp, devhelp) or the custom gtkhtml library (evolution). However, none of these are actively developed any more, because roughly a year ago we started to switch to Webkit, trying to build the webkit-gtk library. This switch has not been completed. It was originally scheduled to be delivered with GNOME 2.26, but has been postponed to GNOME 2.28.
It should also be noted that vendors shipping GNOME mostly ignore the GNOME browser epiphany and ship Firefox instead, which is based on Mozilla. There is no indication that this will change soon.
Mozilla and Webkit in a nutshell
Mozilla is a foundation trying to Free the web. Most of the work done by the foundation’s members is focused on the Firefox web browser, which ensures that it is very cross-platform by shipping almost all functionality required internally, including their own UI toolkit. A smaller side-project is XULRunner, which aims to provide the framework Firefox uses for integrating into other applications. It is not related to GNOME in any way.
Webkit is a fork of KDE’s KHTML browser engine by Apple for creating the Safari browser and adding web functionality to their desktop. It is also used by Google Chrome and various other projects (Nokia S60 browser, Adobe AIR, Qt).
It only contains a web browsing component and a Javascript interpreter and requires the backends to provide integration into their platform. Among other things a rendering library, a network layer and an API to successfully write an application are required. The webkit-gtk project aims to provide this for GNOME.
development drivers
Mozilla’s development is driven in large part by employees of the Mozilla Corporation, which was founded and is owned by the Mozilla Foundation to develop the Firefox browser as its sole purpose.
Webkit’s core has been developed in large part by Apple after forking from KHTML. Other browsers built on it have usually been forks of the Webkit codebase. Recently this changed when the Google Chrome and Nokia Qt teams started to merge their code back into the Webkit codebase and started to base their work on top of Webkit directly. I do expect to see more formalization of the government model during the next year, though I have not seen any indication of this yet.
community
Both Mozilla and Webkit have an active development community that is roughly the size of GNOME (that’s estimated, I could be off by a factor of 2-5). A lot of them are open source developers. Members of the different projects know each other well; they hang out on the same IRC channels and mailing lists. A lot of the current Webkit developers have been former Mozilla contributors.
Mozilla has also managed to gain respect in the web development community, both by sponsoring development of web tools and by creating channels of communication< with them. Add-On development is a strong focus, too. Mozilla encourages development of sophisticated customizations to drive the browser. Last but not least they are reaching out to end users directly. As a result, Mozilla and in particular Firefox have become strong brands.
In Webkit country, outreach to web developers and end users is done by the browser vendors themselves. Google and Apple are well known brands themselves and market their browsers using traditional channels. As such, the name Webkit itself is relatively unknown and attracts relatively few external contributors from the web and add-on development communities. However, Webkit encourages porting the core for different purposes and as such attracts a lot of browser developers, including the webkit-gtk port.
compatibility with the Web
Mozilla probably has 20-30% of the world-wide market share, Webkit has 5-15%. Both numbers are big enough to ensure that websites test for the browsers, so that in general, websites should work.
However, no website will check for GNOME, so all features that are provided by us will not be tested. This means that all features we maintain exclusively for GNOME can cause issues if they don’t work exactly the same way as in the other backends. And from Swfdec development I know that this is incredibly hard to achieve, as it does not only require an identical featureset, but also identical performance characteristics. This is less of a problem in Mozilla, where the GNOME-specific code is pretty small, but might become a big problem in Webkit, where a lot of code is solely written for the GNOME backend.
featureset
First a note: This point is subjective, you are free to have a differing opinion. If you do, please explain yourself in the comments.
Both browsers implement a similar set of features. I don’t know of a single (non-testcase) website that provides reduced functionality in either of the browsers. Still, the codebases are very different. Mozilla is a pretty old codebase that grew into what it is today and while there were some attempts to clean it up at times, there is still a lot of cruft around and it is easily the bigger size. I know lots of GNOME hackers that use Mozilla code as an example for scary code. On the other hand, Mozilla makes up for this by providing a lot of small niceties that Webkit does not provide and that make for a smoother experience in general. An example is kerning between tags: L”L”L (In Mozilla, the L and ” glyphs will overlap, in Webkit they won’t). Another example I know is windowless browser plugins.
Webkit in general is simpler, more compact and easier to understand code. I attribute this to KHTML being newer and focussing on maintainability and clarity. This shows when Webkit is able to show excellent performance. However, this quality is not always true. Parts that are not maintained by the core team are often very ad-hoc, lack design and bitrot easily. In short, everything out of the ordinary can be very ugly. Also, I am not sure if the old goals are still held in the same high esteem by the current maintainers. Code quality doesn’t sell after all.
code handling
Mozilla is written in C++ and uses a heavily customized version of autotools as the build system. The source code is since recently kept in Mercurial, older branches still use CVS. Webkit uses Subversion with an official mirror in git. The core is written in C++. Each port adds its own build system and API on top; Apple Webkit for example uses Objective C and Xcode, webkit-gtk uses Gobject-style C and autotools.
Both Webkit and Mozilla use a review process where all features and bug fixes have an attached bug in the respective bugzillas (Webkit and Mozilla) and all patches need to be reviewed by at least one reviewer. Webkit uses buildbots to check that the various ports and branches still compile. It pales in comparison to Mozilla’s extensive QA that also includes performance regression testing and important policies that govern checkins.
Releases in Mozilla are handled centrally, all Firefox ports are released with a common release number at the same time. This is built on top of a core branch, which other projects built on Mozilla (Camino, Epiphany) use. This allows an easy matching of browser version to feature availability. Webkit projects releases are not coordinated between different ports, and contain their own branches. so Safari, Chrome, webkit-gtk and Webkit master may all support different features.
initial work required to integrate
The next two paragraphs again are heavily subjective. They assume that GNOME wanted to include a library for integrating the web.
For Webkit, work is being done to integrate GNOME. The problem is that a lot of base libraries are required that do not exist today. So not only does webkit-gtk still need to gain basic features, it also requires testing all the new code excessively for conformance to standards, stability, security and performance. None of this is being done today.
Were such a library to be based on Mozilla, much less code would need to be written. However, a lot of integration work would need to be done, so that GNOME had proper access to the library functions (like for manipulating the DOM, http access or the Javascript interpreter). A lot more work would be needed to convince the Mozilla developers to support such a stable API, as currently Mozilla does not guarantee stability on any internal APIs and even add-ons have to be adapted for every major Firefox release.
Regardless of which project were to be chosen, my expectation would be that if we were to start now, it would take 5 experienced GNOME developers roughly a year to get this work to a point were it would hold up against todays requirements of the web. For Webkit, this would mostly require writing source code. For Mozilla, both writing code and evangelizing inside their community would be necessary.
predicted maintenance required once project is running
If the project in the above paragraph were done today, continuous maintenance of this library would be required. Not only for bugfixing and adding features, but also to keep up with the constant change in the browser cores, which refactor for performance and security or add new features for new web standards. I’d expect the current GNOME browser team to be able to do this.
However, we would need to build up respect in the browser community, both for ensuring our work was still necessary and for driving change in the browser’s core and the standards community to help our goals. Currently no GNOME developer that I know participates in any W3C working group. This would likely require people working on this project full-time, as respect is usually concentrated towards single people. Also, contributing to the core requires knowledge of not only the large code base, but also keeping up with the multiple different ports. I don’t see any developer of GNOME doing this currently.
view towards GNOME
Mozilla and Webkit developers pretty much share their opinion about GNOME: It doesn’t matter. This has two reasons. The first reason is that it doesn’t have a significant enough market share for them to be interesting. Even though they target the Linux desktop, none of the browsers target GNOME in particular, as they try to ship a browser that works everywhere on Linux, like KDE or CDE.
The second and more interesting reason is that the browser development communities think desktops are going to die sooner or later and the browser will be the only application that you run on your computer, so developing “desktop stuff” is not in any way interesting to them. Just like the GNOME community treats the web, the web developers treat the desktop.
view towards Free software
Mozilla has it this in their manifesto:
Free and open source software promotes the development of the Internet as a public resource.
This is shown by the Mozilla code being tri-licensed under GPL 2 or later, LGPL 2.1 or later or MPL.
Webkit is de-facto licensed under the LGPL 2 or later, as that is the license of the original KHTML code. New contributions are encouraged under the BSD license, but code licensed as LGPL 2.1 is accepted, too. All Apple and Google contributions are BSD-licensed. However, while the companies follow the letter of those licenses, they don’t follow the spirit. Both Android phones and the iPhone contain a Webkit browser that is not updatable by users.
conclusion
This is the short version of things I evaluated. In short, Mozilla is the adult browser engine with clearly defined rules and goals, while Webkit is the teenager that is still trying to find its place in the browser world. I don’t know which one would benefit GNOME more, so feel free to tell me in the comments. Also, if you feel things in here are factually wrong, feel free to point them out there or privately.
45 comments ↓
Nice writeup. Don’t forget accessibility! Currently Mozilla has the lead with full ATK support and WAI-ARIA implemented.
On OS X, at least, WebKit managed to deliver the OS’s instant web connection in each and every app that wanted it; it was quite a boost to the community when Apple suddenly introduced an embeddable, serious, stable widget for WebKit to the platform.
My hope is naturally, that something like that can be delivered to the Gnome platform.
And, at least the switch of backend makes epiphany adoption more likely, since it can then hopefully deliver a more marked alternative to Firefox/Gecko, and maybe also a memory usage reduction.
One thing i am missing in this summary is a note on the fact that Mozilla’s primary aim is to provide a browser while WebKit’s primary aim is to provide an engine. This has some serious effect on how smoothly the integration into GNOME can be.
Another option would be to contribute to firefox itself, making it better integrate with gnome. I think a gnome web browser is never going to have enough users to be well supported at random crappy websites. Firefox has enough users though.
Dude this is like an Arstechnica article. Great verview. Thank you!
Really nice writeup. Maybe you can submit it to LWN?
Firefox is already a great browser in GNOME,
therefore it might be harder to get testers for the GNOME browser (Epiphany) if it uses the Firefox engine.
I believe those users will use Firefox instead. Epiphany could be a really alternative browser, and get more testing through the webkit-gtk route.
Also, the work on Epiphany and webkit-gtk will hopefully benefit other projects that might switch to webkit-gtk. *hint* Evolution *hint*
I believe using webkit-gtk is the way to go.
Really interesting.
Just a fyi, your kerning example doesn’t work. It renders the same in Midori (pure webkit-gtk) and Firefox. Just thought I’d point it out.
Webkit-gtk is already available to developers as a serious, embeddable html widget. Liferea for one makes use of it (they’re switching from gecko even… which was available before too.)
Thanks for such a well-written and fair-minded evaluation!
We should have two separate goals.
1. Having a First Class browser application for GNOME. This is Firefox, we should work on integrating gnome into ffox (lets say integrating its password manager with the gnome-keyring for example). Webkit is very far from reaching this goal. Epyphany-webkit is a joke.
2. Having an embeddable widget, my understanding is that the Mozilla people are working on a cross-platform embedding API, that said, this API probably is probably very un-gnomish… This is where webkit may be interesting…
Maybe we want both ?
IMO any GNOME browser should support both rendering engines, with a gconf option to switch between them.
bratarsch: Chris Blizzard has promised a better API for Mozilla embedders http://www.0xdeadbeef.com/weblog/?cat=43
Something worth thinking about is which apps should have access to the shared cookie store etc. Perhaps a feature required for the chosen framework is PolicyKit integration?
Regarding this part of the “view towards GNOME” section:
“The second and more interesting reason is that the browser development communities think desktops are going to die sooner or later and the browser will be the only application that you run on your computer, so developing “desktop stuff” is not in any way interesting to them. Just like the GNOME community treats the web, the web developers treat the desktop. ”
I don’t think this is accurate for Mozilla developers (of which I am one). The first point seems reasonable (modulo webkit not being a browser project, so their GNOME support or lack thereof is kind of meaningless because *it’s not even their mission to support a browser*), but I don’t understand where you’re getting this second point. I think it might be reasonable to say that Mozilla’s concern is that a web based on published standards flourish, not that GNOME’s web in particular flourish. (I’d use “open web” here except that going by Planet Mozilla it feels like it’s all but reached full buzzword status — it’s beginning to evoke the same feelings of revulsion that “Web 2.0” and “AJAX” bring to me, regardless how much more meaning it might have than those terms or how much I might agree with its goals.) Mozilla and Firefox are extremely viable in GNOME and on Linux in general, and thus the goal once the basic freedom to use Mozilla in GNOME is provided for, further support doesn’t bring huge wins.
Here’s an illustrative question: is it better for Mozilla to work on and promote things like native Ogg Theora/Vorbis support for video/audio content on the web, or is it better for Mozilla to work especially on things that will more directly support GNOME? Mozilla could do both, perhaps, but I think it’s clear we can be most effective at advancing choice and freedom on the Internet doing the former. Comparative advantage, then, dictates that we work on the former — although if people step up (consider, for example, Michael Ventnor’s hacking over the last few years), we’re more than willing to help with the latter as well.
At a more meta level, I’m not sure it’s really a great idea to lump all of Mozilla or all of Webkit into one monolithic community; motives vary greatly within each. To name a few names, a Michael Ventnor might work on Linux functionality because he wants Linux to succeed, while a Markus Stange might work on OS X functionality because it’s what he uses (I’m totally guessing at his motives, no idea what they actually are), while a person like me might work on things (JavaScript and automated testing goodness, as well as the latter’s multiplicative effects for reducing overall bugginess) that don’t relate to any platform at all because he likes working on intricate machinery and making a system that works correctly.
You didn’t talk about ABI stability – I know Mozilla has been bad for this in the past, I’m not sure what things are like now.
Even with the font style italic AVAVA looks the same on WebKitGtk as on Firefox.
Nevertheless Firefox supports some things better than WebKitGtk and the other way around. It’s the same for Opera and Firefox. Or if you compare Internet Explorer with the rest of the world.
That’s the way it is. Different engines support different things in different ways. You won’t avoid that, even with web standards.
The innovation perspective? I guess both do lots of development, I only know a few things from the WebKit camp; they are introducing lots of innovative features and feature previews, like HTML5, CSS animation or some things that Apple needed for the iPhone etc. Anyway, some of these things are not relevant for the web (yet), but can be very interesting if WebKit becomes a desktop technology.
@Jeff Walden: I thought that concern was true from an end-users view – Firefox using it’s own dictionary and not the same one that every other Gnome application does is a major PITA. They also lack input methods, which again every Gnome application has, is annoying (typing stuff out in one program and then c/ping it into Firefox is… tedious. Especially when you’re translating online.)
Minor factual correction: the Mozilla build system does not use heavily customized autotools. It uses stock autoconf (albeit an old version). It does not use automake at all, but rather a hand-grown shared-rules system that predates automake by several years.
Vadim: Gecko supports input methods, in general. Can you give a specific example where it doesn’t support the standard input methods (or file a bug!)?
I can right-click on an input field, select ‘Input Methods’, select my language, and start typing in it. In Firefox, right-click does not show any option for ‘Input Methods’.
First of all, great post Benjamin. It’s nice to see this overview. From the Mozilla side I would make a few comments that I think are relevant. I think that Jeff Walden covered most of what I want to say, but I’ll expand on a few topics:
1. There is a clear alignment between Gnome and Mozilla. I don’t think that this should be understated. We’re both non-profit organizations with the aim of creating freedom in places that desperately need it. Mozilla backs that up with action in terms of support for open formats, free software and activism. Gnome does as well. There are huge opportunities here to work together on stuff, even outside of technology. I think that this should grow over time.
2. We support both Linux-as-a-desktop and Gnome in particular. I think that there’s a perception that we don’t support Linux or only doing so grudgingly – that’s not the case. You can see this because Linux is still a top-tier platform right there along with Windows and OSX.
Now, we understand that Linux and Gnome aren’t as successful as either party would like them to be. But at Mozilla we understand that this is the best chance that anyone has seen for a free desktop. Everyone knows you can’t trust Microsoft and none of us trust Apple as far as we can throw them. So even though it doesn’t make great business sense, we continue to support Linux and Gnome. (Don’t confuse our use of Apple products or with our support or love – we know what they are like better than most. But we have to live in the same world as our users.)
Also we care a lot about Mobile and one of the main environments we’re targeting right now is Linux and Gnome-based. So we’ll have a browser there.
3. I think that the desktop vs. web is a false dichotomy. For me it’s a question of what surface area you want to expose to developers. We’re exposing more and more of what looks like desktop APIs to the web – offline page access, databases, raw drawing APIs, near-native performance and soon 3D support. We’re doing this in order to make it possible write a lot of apps using web technologies because we want the web to expand. It’s a uniquely transparent technology and hugely empowering to developers. (Discussions of the cloud being evil aside, think about how successful those Linux-based netbooks would be without a decent web browser an being able to live almost entirely on the web these days?)
So are we competing with desktop functionality? Sure. But we’re also making it possible for a huge number of developers to target Linux and Gnome-based systems. Thought experiment: how many developers know JS and HTML and how many know C and GObject? That’s what the real battle is. I’ve never understood why Gnome hasn’t figured that out and just gone whole hog into supporting JS as a base language (happy to see this is finally changing, though. I don’t think that people understood this until the Mozilla add-ons community exploded.)
4. Note that on the embedding front I don’t think there’s much – if any – resistance to supporting it. But what’s missing is someone really competent to own it full time who can operate easily in both environments. If someone showed up who showed that they could hack on it and make it successful no one would stand in their way. I see this as a person problem, not a technology problem.
Mozilla’s more intense and directed than Gnome is, that much is true, but I never really had a problem bouncing back and forth. And we have our own release schedules and criteria, just like any non-Gnome upstream library. But quite a few of our Gnome contributors are able to live in the Mozilla world. And they are quiet and effective when they do so.
So that’s longer than I expected. But I hope it’s useful. Cheers!
I think it’s clear from the experiences of Debian and Ubuntu where Mozilla’s priorities are. I also value the experience of the epiphany developers wrt how useable gtkmozembed is, and making the decision to dump the most popular rendering engine at the time cannot have been an easy one. From a web browser POV, I don’t think epiphany need worry. Chrome has shown that there is still interest in trying out new browsers and plenty of room in the market for new ones, the key is to make a really GOOD one. I’m confident that focussing on making a really kick-arse browser will be enough for epiphany to shine. From the POV of an embeddable GNOME component, if a web browser developer found the gtkmozembed component painful enough to abandon it, that really says something to me.
I think the Epiphany guys did the right thing when they announced the move to WebKit. Maybe a little too soon, but hey… it’s finally coming together and from what I gather, it’s fun to work with for those who do it :)
WebKit is new but Apple seems to care a lot about it and now Google is actively supporting it. Sure, none of them do any work on WebKitGTK (tho Apple seems to be committed to keep all ports compiling) but ultimately we will all benefit from much of the work being done on Safari and Chrome.
Firefox is a nice browser but in terms of integration with GNOME it has reached a point where not much more is possible. Epiphany, on the other hand, can now share a lot of code with GNOME and easily integrate with the keyring for example.
Mozilla is very committed to improve Firefox, but they have not heard the call for an easily embeddable html/css/js engine for years. This way, they have lost the opportunity to be the core for browser like Chrome, but also being the 1st choice for hand-held devices like Android phones.
Webkit actually has regression testings wrt. performance. You can check nearly any Changelog file or the commit messages and you’ll see them. Of course they’re not done where they would be irrelevant (build fix for instance ><) but they appear for js/html/display.
[…] best to reassure him of course, providing arguments that support their choice and pointing him to a blog post by a GNOME developer that gives a fair and balanced assessment of the merits and drawbacks of the two platforms. The […]
Vadim, regarding this:
“Firefox using it’s own dictionary and not the same one that every other Gnome application does is a major PITA”
To whom? In what ways does dictionary divergence significantly affect the user experience? You might have to download a different dictionary, or you might have to readd obscure words, but those are one-time efforts. Once the dictionary you want is there, once that word you want recognized is there, that’s that, no more pain for the user. It’s not optimal, perhaps, but it’s not that important a bug, overall. Now, *distros* might think otherwise, but Mozillians are generally and primarily concerned about users, not about distros (distro reps excepted).
I really can’t speak to the input methods complaint as I’ve never had a need for the functionality you describe (and, to be honest, I’m not even sure *what* its purpose is from your description).
Tom, there really isn’t anything preventing Firefox from integrating with the keyring except someone to step up and implement it. Also, isn’t “not much more is possible” good, not bad? Why the “but”? I don’t understand the complaint.
@Jeff Walden
” You might have to download a different dictionary, or you might have to readd obscure words, but those are one-time efforts.”
This is typically what’s wrong with Mozilla i18n in general. These are not one-time efforts. They require continuous maintenance and care. When you use the system components it’s done system-side. When you don’t it’s pushed to the user. Firefox is one of the few Linux Desktop apps which is periodically broken i18n-side, because of this.
i18n should “just work” as a core feature, not as a badly bolted on option.
Firefox devs should change their default locale and dictionnary to something else than English so they experience first hand the “one-time efforts” you dismiss here.
Sorry to reply kinda late, people catching me on IRC kept me busy. ;)
So far I’m quite happy that the article wasn’t perceived as biased by anyone. Both Webkit people came to me and said “Great article. Just a minor thing: …” and then listed a thing were they thought their project was badly judged. In fact, it were almost always the things I disliked about those projects most.
@bratarsch: In this article I wanted to focus on Mozilla the engine, not on the browser. And as they do have an engine, I think the comparison is fair.
@Tester: While those 2 goals are the logical first steps, I think we need more than that. I want tight integration with GNOME apps (http lib with shared cookies and cache, modifying with the DOM) and I want to do more than display web sites in widgets (html thumbnailer, cell renderer, …), to name just a few things I can imagine.
@John: I’m all for supporting both rendering engines. But unless you find someone who codes that support, it’s not gonna happen. We only barely have enough people for supporting one engine.
@Dirk: I replaced the AVAVA with L”L”L to make it more obvious – I had to ask font people what the most-kerned letters where to find that example. :)
@Christopher Blizzard: I had almost started writing a response to your comment, but then realized that a) we probably talked about these points before – or at least I did with some of you guys and b) it’s probably worth its own blog post. And a proper response would get long. So I stopped. If you (or anyone else) still wanna discuss specifics about this, poke me on IRC.
@Adrien Nader: Webkit does not do performance _regression_ testing. They do test manually when they make stuff faster. But I have never seen them back out commits because some automated test system complained that something went slower than before.
Jeff Walden: “In what ways does dictionary divergence significantly affect the user experience?”
… I’m sorry, but when I add a new word and it appears in a dictionary of every single application but Firefox, and then I have to add it again in Firefox, that is -not- an optimal experience. Especially when it’s a lot of words, and when Firefox’s auto-suggestions for typos are typically worse than the ones suggested by Gnome applications too.
“I really can’t speak to the input methods complaint as I’ve never had a need for the functionality you describe”
Just because you don’t, doesn’t mean I don’t or others do, and saying that’s not needed is simply not caring for the end-user. In my case, I use this to type in the Russian language – I’m on an English-only keyboard, and Input Methods allow me to type in Russian. Since I also do translations online in Rosetta, I have to type my text out in any Gnome application and paste into Firefox.
“Mozillians are generally and primarily concerned about users, not about distros” No, what you showed here is a concern for your own personal use, not the Gnome user.
@otte
The kerning example looks exactly the same for me on Safari 3.2.1 and Firefox 3.0.6. Both on Mac OS X.
Same here on Firefox and Midori: http://www.ubuntu-pics.de/bild/10532/screenshot_01_97tZk4.png
It depends on font settings of course. Using Deja Vu Sans as my default font I get http://www.ubuntu-pics.de/bild/10533/kerning_1O9T8W.png in Mozilla and no overlap (like in all your screenshots) in Webkit.
@otte
It’s still in the category “This engine support this and that engine supports that” for me. There are many things, that are not supported by Firefox (Gecko, because we are talking of engines), but by WebKitGtk and (of course) the other way around. A very special example is your L”L”L problem with Deja Vu Sans and there are a lot more of them, but bidirectional. And all are working on a smoother experience for the user.
Sigh, I shouldn’t have responded past my first comment, I knew where this was going to go.
Nicolas, as I understand it (maybe I’m wrong) Firefox ships with a dictionary for each locale that’s been translated, so I don’t know why it matters that a developer might use or not use the English version. Also, I dispute that i18n is “bolted on”, but I’m not sure we’re going to be able to come to any sort of agreement on the state of i18n, so I’ll drop it.
Vadim, as to the dictionary thing, I agree it’s not optimal. That said, there *is* a dictionary to use, which is the primary concern if you’re the user. As to the input method stuff, I was simply saying that because I don’t use it, I have no idea whether it’s good or bad or not or how poorly we support it. I think Firefox’s personal certificate UI is pretty horrible, but odds are you’ve never had to use it, so assuming that all you could say about that UI is that you don’t use it much. That’s not an indictment of the UI’s utility, that’s just saying you don’t know anything about it. Regarding distros/users, it’s clear we’ll get nowhere if I try to respond, so I’ll leave that alone.
Only thing I see being clear is that a Windows machine gets a nice installer that the user can run and delete the file after, while the Linux user has to make a place for the browser, get no shortcuts or any integration with launch methods like Gnome DO via Firefox’s .tar.bz2 download.
So no, sorry, I am not sure what is Mozilla thinking about here when they say distros are bad and they care for the end-users.
Esp. with latest news like this: http://www.tuxradar.com/content/benchmarked-firefox-javascript-linux-and-windows-and-its-not-pretty
Where it turns out that Windows version of Firefox get optimizations that aren’t enabled in Linux. Nyeh? Some PR explanation would be nice if I’m misunderstanding.
Isn’t the installer thing supposed to be a problem for the distros to solve? Many if not most Linux users get Firefox through their distros, and frankly, I’m not really sure what you’d do to make the Linux install experience from downloadable executable better — there really aren’t any standard practices to follow, and numerically there probably isn’t much point given that distributions are the standard distribution mechanism.
Speaking of which, “distros are bad” is a strawman; I’m glad there’s a Fedora so I don’t have to bootstrap a Linux system, install X, GNOME, and so on to get things done. (Frankly, I’m probably incapable of doing it unless I massively lowered how much I value my time.) If you want a politically provocative restatement, how about “distros good, end-users better”? :-)
The benchmarking is primarily a result of Microsoft’s compiler plus profile-guided optimizations being better than gcc, and a few people who’ve done PGO Linux builds report the difference is not significant enough to make up the difference. A more worthwhile comparison might be to do the same comparison using Intel’s C++ compiler, which I hear does a much better job of optimizing some areas of Mozilla than gcc does. It’s not free in either sense, but I’ve heard that you can get a trial license that would at least demonstrate how much difference is due to the compiler.
The installer question is easy – we used to have one but no one used it and everyone wanted to get Firefox from their distributions – so we stopped supporting it.
Jeff is right on on the JS benchmark question. The compiler on windows does a better job of optimization. We’ve spent quite a bit of time optimizing on Linux as well as Windows. we spent a huge amount of time testing a lot of different command line options with gcc and we know which set of optimizations work best on the JS engine. (It actually compiles with a different set of options than the rest of Firefox because we did measurements to figure it out. In the process we also found bugs in various versions of gcc as well.)
If you’re doing tests in the browser the graphical front end does have an impact as well. And GTK+ and X are slower than the win32 graphics system. That’s just how it works out.
I see. Thanks for the explanation!
But I still want my integrated dictionary for not having to teach Firefox separately / having it give me better suggestions (don’t know why, but gnome apps ▸ firefox ▸ adobe buzzword is the order of suggestion quality).
And me input methods :]
[…] browsing in GNOME GNOME’s web browsing applications currently use a Mozilla bridge (epiphany, yelp, devhelp) or the custom gtkhtml library (evolution). However, none of these are actively developed any more, because roughly a year ago we started to switch to Webkit, trying to build the webkit-gtk library. This switch has not been completed. It was originally scheduled to be delivered with GNOME 2.26, but has been postponed to GNOME 2.28. […]
Guys, do not forget about accessibility, which is mentioned in first comment. for now, good accessibility experience under linux is provided only by gecko engine.
I thought I’d comment briefly on some things from the WebKit perspective. The article says the following:
“Mozilla and Webkit developers pretty much share their opinion about GNOME: It doesn’t matter. This has two reasons. The first reason is that it doesn’t have a significant enough market share for them to be interesting. … The second and more interesting reason is that the browser development communities think desktops are going to die sooner or later and the browser will be the only application that you run on your computer… ”
I think that’s a little inaccurate as to WebKit. First, WebKit the project itself in a sense doesn’t care about any platform. Or to put it another way, we see the project overall as a technology provider, not a product organization. Thus, we care about any given platform to the extent that contributing individuals or organizations step up to develop and maintain support for it. Our main focus isn’t on market share but rather that the embedders on that platform take responsibility.
Second, WebKit overall doesn’t have an ideological position on the desktop going away. I can’t speak for every contributor. But Apple as a company clearly believes in the power of native software and native applications. Mac OS X and iPhone are both strong platforms for native development, even though the Web experience is a huge and defining part of both. Again, seeing ourselves as a technology provider, we want to enable developers to build more powerful Web applications, but we also want to enable easy use of Web technology in native desktop apps.
I would say that overall WebKit is less ideological, and this could be either a good thing or a bad thing from the GNOME perspective, since GNOME itself has an ideology and shares much of it with Mozilla. WebKit’s project goals have a largely technical focus: http://webkit.org/projects/goals.html . I think these goals mesh fairly well with GNOME’s needs, but it is true that GNOME-focused developers would have to step up to drive and maintain good integration.
Great post.
I don’t think it’s true that Mozilla doesn’t care about GNOME/Linux. Any more than it’s true that GNOME doesn’t care about the hardware vendors. They care, it has to be there, but they have to make their stuff work on more than just one platform. (On a different note, GNOME should make more apps work cross-platform as well. The ones we do have don’t always install easily or well on Windows. Gimp is probably the exception.) Mozilla has been a big supporter of GNOME and the GNOME Foundation.
I think Mozilla and GNOME are very aligned in values and if we could align more in the technical space it would only be good for the people of the world that should have a free desktop and access to the internet.
I appreciate your write-up – it helped me understand the GNOME, web, webkit, Firefox space better. I always learn something. :)
[…] Benjanmin Otte: browsing in GNOME […]
[…] http://blogs.gnome.org/otte/2009/03/03/browsing-in-gnome/ […]