Monday, 7 September 2015

Software complification - Please make it stop

Today I have something more visual than my usual text rants: An image! Yay! Because an image is more expressive than words. Have a look a this:
This graph lists the sizes of the source tarballs of different browsers hitting the FreeBSD ports tree over the past decade. (By the way, Git, Python and Google docs were my friends in creating this.) It illustrates two major points I want to talk about:
  • Starting with Firefox in 2004 (red line colour) and a tarball size of 29.7 MiB, the code base gained weight very slowly until September 2009 where it started to gain a little faster (in the graph this is roughly where the leading '0' of '01/01/2011' is placed.
    Coincidence? I don't think so. Less than a year earlier, in December 2008, Google released a public beta of Google Chrome and it became blindingly clear to most developers how powerful web apps can become if powered by the right technology. Chrome's release changed the game. It fuelled the development of new features in browsers to a velocity that we haven't seen before and sparked the development of browsers that are quite possibly the most complex piece of software you have installed on your devices.
    Then, after the open source release of Chromium (Chrome's non-commercial code parts) things really took a spin and the code base size of the leading browser implementations increased close to exponentially over the next 4 years to the point of my blog post today, at which Chromium's source can be downloaded xz-compressed into a 279.8 MiB tarball, with Firefox's tarball measuring 170 MiB in size and Seamonkey's 193.6 MiB. Without Chrome sparking this trend, for all we know we could still be at less than 40 MiB for Firefox and the slow JavaScript interpreter we all learned to hate. So far so good.
  • Now comes the issue with this. Apparently for a while now we are locked into a mindset in which each new browser release has to be filled with an ever-growing list of new, cool, features. Features that, I'd argue, in part only serve edge cases and more often than not do not concern the average user. Pushing features at every cost has its price. Firefox's recent vulnerability which allowed malicious PDF documents (!) to read local hard drive files is but one example that justifies the question What the hell is missing in current browsers? Do we really need a PDF viewer built into the browser? I have no problem downloading the PDF file and open it in a PDF viewer app. The same goes for other features: Ever-increasing numbers of supported audio and video codecs, offline-applications, "Pocket" (never used it), built-in instant messaging apps, you name it. Focusing development teams (or communities) of a finite sizes strongly to features comprises the danger of omitting the necessary code refactoring, purging the code base of unused or rarely-used components, and old-fashioned maintenance releases which may improve performance, memory efficiency, security without delivering new exciting features. I am not alone here. Enjoy this well-written statement by Paul-Peter Koch who explains a lovely edge-case feature to us: Navigation transition. Quite possible that you have never heard of it before. Read the post and be stunned that this kind of stuff actually exists in your browser.
  • Tiny extra point: Seamonkey, in a simplified approximation, is Firefox plus E-Mail client plus IRC client plus HTML-Editor. The graph above also shows (comparing Firefox with Seamonkey) how huge the browser code base is compared to the rest of Seamonkey's components.
So please, please, please, for heaven's sake: You Googles, Mozillas, Microsofts and players in the industry. Stop complicating things and strive for the lean, lightweight, small, fast, secure software that we really need and give the dev teams the chance to implement them.

No comments:

Post a Comment