First posted to MSDN on Dec, 02 2011
Developers, and the people responsible for the productivity of those developers, have long known that code reuse was something we should aspire to.
Don Box, in his seminal book
Essential COM
walks through the progression we made in the Windows world around code sharing. I strongly recommend reading through the entire work (which I won’t reproduce here), but I’ll summarize the first few pages:
Writing everything from scratch is too expensive
First we have to overcome developer resistance to code developed by somebody else (which remains a struggle sometimes). But we achieved this, and the C++ language made this easier. Now, we could share code as libraries which you could re-use by simply calling into the classes that provided the functionality you wanted. Great news! But eventually we ran into a little problem…
Having a unique copy of this code for every app consumes too many resources
There was a time when we didn’t have 1TB hard drives and 8GB of RAM in our computers – we had to be parsimonious with these resources, and having many copes of a particularly useful library meant that we weren’t using these resources as wisely as we could. So, along came dynamic linking, which allowed us to share the same copy from disk, as well as to leverage tricks in the memory manager to back multiple instances in application virtual memory with a single instance in computer physical memory. Great news! But then we run into a bit of a problem…
There is a lack of standardization at the binary level
Once you try to link against a dll compiled using a different development environment, you may run into important differences, such as differences in how name mangling is implemented. That makes it difficult to have truly universal components! Plus, while C++ supports syntactic encapsulation, it doesn’t support binary encapsulation, and your application must know everything about an object layout in order to instantiate a class. No problem – we can solve that by dividing interface from implementation (they are joined by C++) so the layouts won’t change.
Carrying on (reading the remainder of the story is left as an exercise to the reader – a very valuable exercise), Don discusses runtime polymorphism, object extensibility, and resource management, to eventually engineer COM.
So, why I am talking about COM? Because I’m seeing something very parallel happening right now in the world of web applications…
So, where are we on the web?
Writing everything from scratch is too expensive
Developers are finally embracing this fact, and starting to reuse more than ever. We see this when people use weblog software to communicate, rather than writing HTML. We see this when people buy software which generates ecommerce sites for them. But, most analogously, we see it when developers opt for reusable libraries others have created to save themselves a lot of time re-implementing the basics. So, rather than write everything from scratch, more and more developers are using libraries such as
jQuery
. Great news! But eventually we ran into a little problem…
No, we didn’t run out of RAM or hard drive space (we’re in the cloud, baby!), but something else happened…
Having a unique copy of this code for every app introduced too much security and compatibility risk
If you recall back in 2004, you may remember the
bug in GDI+
which affected a lot of applications. Now, had this been linking against a single copy, we could have just patched the operating system. But, alas,
GDI+ is redistributable
, so not only did we have to patch the OS version, but every application which chose to redistribute GDI+ had to ship its own updates. How many of those are there? Nobody knows for sure! By redistributing it, you know that you have it, and that it has a compatible version to your application, but you also take on complete responsibility for managing somebody else’s code as part of managing your application!
Alas, this is exactly the state we are in for web applications. If you choose to redistribute a library, such as jQuery, you are also choosing to take responsibility for keeping it updated. It turns out that there are a number of bug fixes you would probably benefit from. More importantly, browser support keeps changing. As new browsers are released, new bugs are surfaced and fixed.
The customers I work with are enterprise customers, and as a general rule enterprise customers love to standardize on things. If you standardize on an older version of jQuery, you’re limiting your ability to perform a browser upgrade without applications failing on the new browser. (If you swap out jQuery, you also have the potential for the application to fail because of jQuery incompatibility, though that probability appears much lower in my experience.) Even if there isn’t a mandated standardization effort, there is almost never a programmatic, organizational effort to track and update implementations of jQuery, and therefore this comes up regularly as app compat issues with block IE9 upgrades
How will we solve this one? I have no doubt that we will, given how systematic the potential problem is and the importance to developers and the industry in solving it. I suspect there will be several steps along the way, we’ll eventually come up with an elegant solution that at least one person can actually understand, and some even bigger change in technology will disrupt that work and we’ll be on to the next big thing. But, for now, you are accountable for managing this.
Are you aware that you are accountable, and are you managing it?
