API Hell: The Rise of Application Frameworks and the Fall of Sanity

Software development has started down a path of no return. With the rise of so-called “rich web applications” and application development frameworks such as Adobe Flex, Mozilla, and Ruby on Rails, application developers are struggling to fit their applications into the rigidly-defined frameworks that promise to save development time and maintain developer sanity. In the end, this couldn’t be further from the truth.

Take the Mozilla Platform. Serving as the basis for the Mozilla suite of Internet applications, Mozilla comes packaged with thousands of pre-fabricated components for developing rich desktop applications. At first glance, this would seem to be the holy grail of rapid development. Components could be used and reused in place of proprietary code, and this will save development resources, right? Wrong. Instead, this API bloat increases the learning curve for new developers and leaves them at the mercy of arbitrarily defined interfaces which do not serve their purposes properly. What’s more, the Mozilla Platform is in bed with the W3C, and uses web standards as its main development toolset. This means that in order to develop a complex Mozilla application, a developer needs to learn XML, XUL, XBL, RDF, JavaScript, CSS, C++, and XPCOM. In addition, unit and acceptance testing becomes a two-tiered operation (C++ versus JavaScript), with some code left untestable due to restrictions placed on the Mozilla DOM implementation (XBL and templates, for instance). This leads to regression hell, where one part of the application is no longer functioning properly due to inconsistencies in the other.

Development teams should measure how much time they are taking to learn their development environment versus actual practical development and design. If developers are spending more time understanding the API and less time generating functionality, it may be time to migrate to a simpler development environment. What’s more, developers are often happier when they are creating real functionality. Even if this means reinventing the wheel on several occasions, an application developed from the ground up will ultimately reflect the needs of the client, and will not be subject to compartmentalization due to the framework chosen.