Over the last few months I’ve been writing tons and tons of javascript. When I started using prototype it was like someone let me trade out an old broken down underwood keyboard for a modern one. Writing javascript just got WAY less painful. My code got shorter, cleaner, more complex and simpler at the same time.

As many others have said before, it’s crack for javascript coding. It’s very addictive and once you use it you’ll never want to let it go, and maybe that’s the problem.

I’m a big proponent of prototype (and javascript in general), but maybe it’s worth really looking at what prototype does that I don’t like. Afterall, my efforts at bringing clientside scripting into our design and development cycles have thus far included me pushing various 3rd party libraries and, for better or for worse, I’ve been successful to a certain extent.

But prototype, as beautiful as it is – I wouldn’t be the first person to call it a work of art – has its pitfalls, and to the extent that I’m having an impact on decisions that are having an effect on our network, it’s only fair to talk about these problems. I think, also, it would help to dispell some rumors for anyone out there (reading this) who might be afraid of using the library.

• It ain’t tiny – The current version 1.5, weighs in at a whopping 55K. This can easily be the biggest thing on the page. If your page is saturated with a lot of javascript of your own, using prototype will make your own code optimized by using its functionality rather than writing it yourself, but if you don’t have much code running, the cost maybe not worth the benefit (see the bit about prototype.lite.js further down).
• Betcha can’t eat just one – Once you start using it you’ll never want to stop. Even when I write php or java I find myself wishing for the shortcuts in Prototype. The downside is here that once we start using it, we will be increasingly dependent upon it, such that if we ever decided to remove it from our systems it would be too expensive to do so. We may already be at that point.
• It changes javascript – Prototype extends the native Array object in javascript. Other’s have written more eloquently and intelligently than I could about this topic, but the nutshell is that Prototype changes the way Arrays work in a very useful way, but if you are using Arrays in a manner for which they were not intended (specifically, using them as a hash to contain key value pairs – myArray["this"] = that;) then you’re going to have some problems here.

That last one is the rub. I think we can deal with the other two issues, but the problem with the Array object change is one I haven’t really figured a way out of. If the only javascript that we had to support on our site were the code we authored and the 3rd party libraries we decided to use, we’d be fine. But we don’t; we have advertisers that load up our pages with their own scripts.

These scripts are troublesome in numerous ways – they have a global scope of their own and therefor can have namespace conflicts with our code. They are often large, include superfluous code for debugging, and may not be well written or even buggy.

The problem is that it’s likely that some, even a small percent, of these scripts might include the usage of Array objects as hash maps. This would likely put them in conflict with the Prototype extention of that object type (only if they use for (x in myArray) or for each(x in myArray) to iterate through the items). What’s not acceptable is to expect tech prod to debug every ad on our site, or qa to test them all. This is our revenue stream, and we can’t muck with that.

I think there is a solution here, but it may mean re-writing prototype.js for our own uses to exclude this functionality (or, more likely, to include it only when it’s explicitly requested). Maybe it just means we need to work with the ad agencies to understand what they are doing and to find a work around through ad dev. Maybe it means abandoning the library entirely.

Anyone who has used it extensively will tell you that Prototype feels like magic, or maybe witchcraft. Unfortunately that seems to come with a price, and I’m a little less convinced that the price is worth it.

I’ll end on this note however: whether it’s prototype or some other framework library, we’ll end up with something on cnet, that’s for sure. If it’s Yahoo’s library, an altered version of Prototype, or a library we write on our own, or something else, you can be sure that a year from now the % of page weight dedicated to javascript will be dramatically higher than it is today. We can’t just decide not to do this stuff because users will exepect it. This period is a little painful for us to deal with as we start trying to work more of this functionality into our development, but if we don’t start now we’ll be left behind.