I’ve been having an argument with myself for years over my reluctance to use third party code in my work. I am referring to everything from simple JavaScript libraries to complete CMS platforms. I’m not saying I never use third party code, but I use a hell of a lot less than most people. This makes me arrogant, blinkered and quite possibly a dinosaur – or – perhaps it makes me experienced, focussed and a veteran.

On any given day I may be feeling guilty about my attitude; or smug and satisfied. Yesterday I was cursing the [generally wonderful] Smarty template engine, and feeling smug that my favouritism toward my own code was righteous. The day before I was interviewing a chap about a possible Drupal gig and was feeling guilty that I had so far ignored Drupal, to my detriment.

Regardless of right or wrong, it seems that third party code is more relevant in web development than ever before, and the trend is fairly clear. However, I don’t believe this is a simple, black and white issue. It’s a huge topic, and I have so many arguments, anecdotes, rationales and personal feelings, that I’m going to split this post up into a series just to stop my brain exploding. I’ll kick off with a brief synopsis of what I see as the status quo.

One CMS to rule them all

The current state of play (as I see it) is that the vast number of open source projects out there are slowly simmering down to a handful of de facto market leaders. Just as web giants seem to be slowly conglomerating into monopolies, (one true search engine, one true auction site), so I see this happening with code libraries. Drupal seems to be the definitive CMS for PHP, jQuery the definitive JavaScript library, PaperVision the definitive 3D engine for Flash. Of course there are plenty of alternatives, but the leaders are more in the lead than I have ever witnessed.

From a business perspective there are obvious advantages to this ubiquity: Our clients at Public often ask if we can develop their site in Drupal, and some have even stipulated that their “preferred” JS library is jQuery. I think this probably has a lot to do with PR; are the successful open source libraries really the best ones? or are they just the best marketeers? Does a one-size-fits-all approach really work?

The text book benefits of building your web application on top of a popular third party system are not rocket science:

• Massive time saving;
• Mature, tested & maintained;
• Well documented & large support community;
• Not tied to the original agency/author;

You don’t need an expensive consultant to tell you that, but is this all there is to it? I don’t think so, and that’s what I’m going to ramble about in further posts. Along the way I shall be questioning my own reluctance to use third party code, and perhaps I’ll have an epiphany and change my ways for good.

I just read this blog article by John Resig, the author of jQuery. The article in general is a criticism of various projects like my very own “JASPA” – A criticism of frameworks that attempt to bring JavaScript into the 21st century by abstracting it into a different language.

I knew I wasn’t alone with JASPA – There is GWT and Jangaroo for Java, Pyjamas for Python, and Cappuccino with its own syntax called Objective-J. These projects are all slightly different takes on one core principal – that to truly make JavaScript “better” you can’t just write JavaScript, you have to introduce a more advanced syntax to leverage more advanced features.

Understandably JavaScript evangelists like John don’t all like this idea, and I do understand why. John makes some good points; most of which I completely agree with, but also some that I feel apply equally to his own jQuery and libraries like it.

Native JavaScript vs foreign language syntax

Pure-JavaScript libraries like jQuery, Prototype, Base2, (the list is endless) all attempt to address the short-comings of JavaScript from the inside, so to speak. That is to say that they are implemented in JavaScript and can never escape JavaScript. John argues that this is preferable, but I argue that the way in which these kind of libraries attempt to bend the syntax of JavaScript make them guilty of most of the same charges. Furthermore I argue that these libraries stand in the way of someone new to JavaScript gaining any real understanding of it.

My main defence of JASPA is of course that the language syntax is that of ActionScript (AS3), which regardless of its rocky relationship with ECMAScript 4, is still an evolution of JavaScript, and not a total departure from it, which is what John Resig seems to be most offended by.

So naturally I posted a comment about my feelings..

.. except not only did I manage to cock up the posting of the comment, but for all I know it will be taken down to punish me for my shameless self-promotion. So because of these reasons, and because I feel I made some good points, I thought I’d re-post my comment here with a tiny bit of editing.

--8<-------
I see your point when it comes to non-ECMAScript languages, but what about ActionScript? I chose AS3 to implement my “abstraction” called JASPA – jaspa.org.uk

I know many JavaScript evangelists reject ActionScript, (especially due to its recent history with ES4), but it’s like writing an extended version of JavaScript rather than a whole different language.

The OOP enhancements in ActionScript are intuitive and the syntax for procedural code remains largely the same. I would in fact argue that the OOP enhancements in ActionScript are much more intuitive than constructs like this:

$(document).ready(function(){
   // ...
});

- or sugaring approaches like this:

Class.method('example', function(){
   // ...
});

I appreciate what these kind of constructs achieve, but I cannot agree that they are particularly intuitive or respectful to the natural form of JavaScript. I would go further and suggest that people who aren’t JavaScript experts may not see how these formations really relate to JavaScript syntax, particularly due to the use of whitespace.

There some libraries that convert functions to strings and overwrite them with altered versions – surely this approach is even less intuitive and has even less respect for JavaScript than an extended form which provides real OOP enhancements such as classes, packages, imports, and super; not to mention strict typing.

Anyhow, I would ask that anyone looking at JASPA realises that what I am doing is purely out of respect for what JavaScript is and what it isn’t.