The cross-platform browser fallacy
2009-04-08
As I watch my browser sluggishly scroll a page, I can’t help but think: with all this hardware, why can’t we have decent performance in our browsers?
I have 320 processors1 on my graphics card, together with half a gigabyte of memory. Four cores crunch instructions at over 3GHz, storing data in four gigabytes of main memory. Surely that is enough for smooth page scrolling? I mean, seriously — my 1MHz Commodore 64 could scroll things smoothly!2
The problem with todays browsers is that everyone assumes that a browser has to be cross-platform. A new browser obviously has to rule the world, so it has to run on all the major platforms. And since those have wildly different APIs, a compatibility layer is needed on top of them. Performance, you ask? Oh, it got lost along the way.
Let’s list the benefits that multi-platform browsers bring to users:
- slow rendering and scrolling
- code bloat resulting in low performance
- large memory consumption
- bugs resulting from overly complicated code
For all the unified experience talk, not a single browser can even sync bookmarks across platforms!3 Don’t believe the hype; there is exactly zero benefit from the multi-platformness of our browsers.
It used to be that for economic and political reasons it was necessary to have a unified multi-platform solution. Mozilla/Firefox had to do it to fight the IE monopoly and the misconception that Internet==IE (also to get money from Google for directing searches to them). Safari and Chrome had to be multi-platform because of Apple’s and Google’s world domination goals. IE didn’t have to be multi-platform, but curiously enough was designed as such anyway, so even though it only runs on Windows now, it carries a load of platform abstraction cruft.
Today, we live in a world where it is generally accepted that there can be many browsers and one has to stick to standards when designing web pages. World domination goals can safely be dropped: you don’t have to rule the world anymore.
Every major platform out there exposes the GPU to applications. There are also platform-specific approaches to threading, networking and disk I/O, providing great performance.
I would like to see a Mac-specific browser4, a Linux-specific browser and a Windows-specific one. Each one should be light and trimmed, make the best possible use of platform-specific features, use the native GUI and integrate with the OS.
Stop building multi-platform monsters, users don’t need them.
1 Give or take a hundred.
2 …and do it in the overscan area where supposedly it was impossible to display anything!
3 Foxmarks/Xmarks finally came along and did the job right.
4 Safari 4 is close, but it could do better.
I utterly and completely disagree. Let me look at the first fallacy
you attribute to multiplatformness of the browsers:
* slow rendering and scrolling
Slow scrolling, you say? Well, I'm reading this post in Firefox 3.1b2
on an old Celeron 2400 box with 512 megs of RAM (and a Radeon 9200
w/32 MB), running a current installation of Arch Linux, and I really
can't accuse it of unsmoothness -- once it loaded up, it's actually
pretty good. In fact, it's trivially easy to make a smooth scroll
these days: just grab any GUI framework (cross-platform or not),
create a scroll pane and stack it up with content. Hey, it's out
there, you can install qtdemo and see for yourself.
Sure enough, this blog is just a bunch of mostly static HTML pages,
which are the easiest case (Gmail is barely usable for me in the very
same browser). But this shows that the problem is not really in
scrolling performance, which is easily achieved; it's in the way
browsers create and show the content to be scrolled.
Now, as for slow rendering (by which I understand the amount of system
resources taken up by the browser while loading and rendering a page
and its general responsiveness at this time), that's a different
kettle of fish. Don't take me wrong, Firefox certainly is a hog, and
this shows -- so much so that I've mostly switched to Midori for
casual web browsing on this box, despite its immaturity and
instability. But whence does this sluggishness come from? There is
probably no single good answer, but I'll try to make some points.
First, over-engineering. Firefox didn't start out as just a browser,
but as an extraction of the browser from the Mozilla suite, and it
shows. At the core of Firefox there is a general, abstract,
heavyweight framework for writing anything (XPCOM); then there are
compatibility layers for making it fit into multiple environments;
then there's the XUL way of doing GUI (also incompatible with pretty
much everything); then there's Gecko, which itself is quite sluggish
thanks to...
Second, code bit rot. There's still code in there that traces back
its heritage to the early days of Mozilla and Netscape; it was written
in C++, and the ARM C++ of those days and the thing that is nowadays
called C++ are almost two different languages. (Not to mention the
very nature of C++, which is the Bible of programming languages: it's
horrendously big, complex, self-contradictory and next to impossible
to parse (and compile) correctly.)
But going back to the original question of slow rendering: What does
it take to write a rendering subsystem of a browser? You need to
design and implement all the HTML/XML/CSS/JS/... parsers, a
standards-compliant layout engine that takes into account all the
complicated algorithms set forth by W3C standards, a JavaScript
engine that seamlessly integrates with the previous components, etc.
It's all just a matter of good algorithms and good implementations.
And the big question is: Where in the world do you see the
opportunity for system-specific APIs to help in these tasks?
Leveraging GPU power, you say? Hey, I've got an old graphics card,
it's not compliant with all this modern stuff -- I want smooth
browsing experience, too! (Besides, if we did it that way, doesn't it
shift the focus to writing _hardware-oriented_ rather than OS-oriented
extremely efficient browsers? Isn't CUDA NVidia-specific?) Even my
old Commodore 64 could do wonders with the little power it had!
(To make a short digression: Despite everything that other platform's
afficionados might say, C64 is alive and thriving. The last version
of the Contiki OS, a considerable achievement (including a web
browser, no less!) appeared in March. But hey, Contiki is portable!
It even runs on the VIC-20! Talk about code bloat caused by
portability!)
Yes, for (say) Web servers or FTP daemons, it makes a lot of sense to
write a Linux-specific program to make use of the sendfile() syscall
to avoid copying data between kernelspace and userspace. This is what
vsftpd does, and it does wonders. But those are I/O-bound rather than
CPU-bound applications, and there's little room for algorithmic
improvement there.
I'm dreaming of a lean and mean, standards-compliant browser, too.
But the claim that "there can be many browsers and one has to stick to
standards when designing web pages" is also not exactly true. Let me
quote some comments from the source code of Google V8, Chrome's
JavaScript engine:
From runtime.cc:
// In Firefox/SpiderMonkey, Safari and Opera you can access the characters
// of a string using [] notation. We need to support this too in
// JavaScript.
From conversions.cc:
// NOTE: We optimistically try to parse the number as an octal (if
// we're allowed to), even though this is not as dictated by
// ECMA-262. The reason for doing this is compatibility with IE and
// Firefox.
Yeah. All hail standards compliance!
1) Internet Explorer is not cross platform, yet it doesn't have the magical smooth scrolling you are looking for. That scrolling has little to do with cross-platform code.
2) Use a plugin such as XMarks to solve your cross-platform bookmark woes.
The reality is that cross platform browsers have a much larger user base, justifying increased amounts of effort on the browser. Chrome for instance has a much better Javascript engine than IE, the costs of which can be amortised across many different users on many different platforms. Were it locked to one single platform, the costs would be harder to justify.