Okay, okay… I’m guilty. The title is provocative and slightly misleading. I do care about developers. Developers are my people and I want nothing but the best for them.

That said, when I’m sitting down planning a site, application or component, my first thought isn’t about making things easier for developers. It’s about making things easier for users. If I can do both, great. The world is just that much nearer to perfection. If not, whenever possible I’m going to err on the side the user by trying to make the site they see better/stronger/faster.

(well, maybe not stronger…)

That’s why I cringe when people enthuse about how easy something was to implement.

“That was great. I just had to write two lines of JavaScript and I’ve this cool Ajax component.”

Sometimes that can be great. Easy is great. Especially if it’s a really tight library with no dependencies, but if, for example, someone includes the full, uncompressed Prototype/Scriptaculous codebase for a single effect or feature, then things (in my mnd) skew to the negative. Yes, the component might be cool, but all the added script might make the page load so slowly that a user will bounce before ever seeing it.* That’s not what you want. Why do something cool if no one is ever going to see it?

Don’t get me wrong, I don’t want people to have to re-invent the wheel every time they sit down to write some code, but that “let me grab this kewl component” attitude is indicative of the sloppy mindset that creates situations like the following:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js"></script>      
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/scriptaculous/1.8.1/effects.js"></script>  
<script type="text/javascript" src="/scripts/niftycube.js?version=2247"></script>                                              
<script type="text/javascript" src="/scripts/global.js?version=2247"></script>                                              
<script type="text/javascript" src="/dwr/engine.js?version=2247"></script>                                              
<script type="text/javascript" src="/dwr/util.js?version=2247"></script>                
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.2/build/yahoo-dom-event/yahoo-dom-event.js"></script>      
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.2/build/container/container-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.2/build/menu/menu-min.js"></script>      
<link rel=stylesheet type="text/css" href="/scripts/ext-2/resources/css/ext-all.css"/>      
<link rel=stylesheet type="text/css" href="/scripts/ext-2/resources/css/xtheme-gray.css"/>                                    
<script type="text/javascript" src="/scripts/ext-2/adapter/ext/ext-base.js?version=2247"></script>                                              
<script type="text/javascript" src="/scripts/ext-2/ext-all-debug.js?version=2247"></script> 

The above is from a live site and represents three major libraries (Ext JS, YUI and Prototype/Scriptaculous), one minor (NiftyCorners) and a whopping total of 1549.1KB of Javascript (~400KB GZip compressed!) being attached to a page. This is a public facing, consumer oriented site.

Before anyone jumps up defend them, I can easily see paths to the above solution. There’s no need to give me examples. I get it.

• Time
• No dedicated JavaScript resources
• Lack of budget for concentrated front end development
• Back-end solutions in use mght include the above libraries as dependencies.
• A “good enough” is good enough philosophy (whether tied to a particular methodology or not.)
• Etc.

Whatever it was, at the time, in their particular scenario, it seemed like a perfectly valid choice to include probably 50,000 lines of library code on their site.

Now that I’ve shown some empathy for their choice, I’ve got to say the above is a bit of a nightmare to me. Seriously, if you really need to throw that much third party code at your end users, then it’s time to re-evaluate some things. Remember, it’s not free to the end user, just because you didn’t have to write it. They still have to download, and parse (blocking parallel downloads) all that code. Considering it’s the layer that users actually see, and that a poorly engineered front end can undo all kinds of expensive back-end optimisations you ignore the front end at your own peril. I mean, what good is killer server side code if no one sees anything because they’re too busy hitting the back button waiting for 1.5MB of JavaScript to be parsed?

Would choosing one library (in their case, I vote YUI) and doing some custom code have cost more time and money? Yes. If time and money were the overriding concerns, then they definitely made a valid choice, On the other hand, would the end user experience have been improved with custom code, possibly improving the real bottom line- through conversions and other activity on the site? Certainly. Even beyond the simple speed improvements from dropping the extra libraries, using custom components allow the user experience and visual designers a lot more flexibility in terms of designing the right solution and not simply using the one that came along with Scriptaculous.**

In a nutshell, the mantra is this-

While you code a site only once, your end users will potentially (hopefully) use it millions of times over its lifetime.

To that end, whose time is more important? Who should be the focus of the decision-making process. You, the glorious code monkey that you are, or your sea of users?

Obviously, it’s the users that we should be paying attention to whenever possible. Otherwise what’s the point, exactly?

Personally, I never go for the easiest solution if there’s time for a better solution.

Convenience only excites me when it comes along with top quality and cleverness is nice, but counts for nothing to the end user, so it rarely features in my technology analysis.

All of which, I spend a lot of time hunting for milliseconds and tweaking an interface to get it “just so.” Which makes my days interesting and hopefully makes my end users’ days just a little bit better.

*some folks might scoff at that, but I’ve seen some JS libraries take a full second to load.

**As an aside, that’s one of my main reasons for not relying on any library effects, ever. When I have used them, I invariably end up tweaking someone else’s code to change some library behavior. It usually gets to the point where I would have been better served writing my own code and having complete control of how it operates.