Web 2.0, tested?
Being on both sides of the fence between server side and client side programmers I hear two different calls to duty. On the server side it’s test, test, test. On the client side it’s get it out the door! Client side testing is absolutely no different from server side testing but since web site widgets are here to stay, where is the emphasis on testing.
This is the first part in a series of creating and testing JavaScript functions and libraries for use across all browsers and in conjunction with other libraries a user may include from other vendors. I mean just because you might write a beautiful library and completely test it, doesn’t mean another vendor doesn’t kill yours. Or is that testable in itself?!?
If you develop in .NET, Java, PHP, or any language that resides on the server to deliver the application I’m sure that you have heard the Test Driven Development (TDD) or Behavior Development Development (BDD) for writing your tests first and then code to make it happen and be bug free. Maybe even validate your producing HTML against the various W3C validator. When it comes to the client side programming of JavaScript you just grab a handy library from the most relevant open-source search. Maybe you test the application in your browser of choice or even use such applications as Selenium.
As the buzz word for today is Web 2.0, in that web sites are “interactive”. Yet the emphasis for applications is still on testing server side code to make sure that the server side programming still operates as expected, although continuing to use or creating client side libraries that are not tested and don’t operate as expected in various browsers. In short no matter how awesome your house is if no one can get to it then what’s the point.
Web 2.0 is not built on the fashion of server side programming, it’s built on the premise that a user can have interaction with a website without the traditional delays as refreshing the page. This means that JavaScript and DHTML is to be incorporated correctly for all browser supported. This requires a paradigm shift in thinking that JavaScript and HTML is a small part of the “total programming” that a web application can have.
Let’s explore the server side programming environment for a moment. On the server side you have a controlled environment. As a programmer you know your environment, you know your current version of the language you are programming in, you know when updates/upgrades are going to be performed. These things are no surprise to you and you know what exactly you can do to optimize your code. Fundamentally, server side programming a a clean room environment here you have total control.
On the client side it’s a bit different. You don’t know everything about the visitor you are try to serve. It’s well known that as far as JavaScript and CSS support across the different browsers isn’t always the best since. Even the difference’s from the same host JavaScript object in Safari and Firefox makes client side programming difficult.
Client side programming is not necessarily about knowing code it’s how to code to prevent crashing in the browsers. Your elegantly written JavaScript library that works beautifully in Firefox but fails in Internet Explorer 7 and completely crashes Internet Explorer 6 will cause you to lose a lot of visitors. It’s the same code, different environments. Certainly it’s easy to say “Firefox” is only the supported browser. Seriously?
Client side testing also about downloading as well. Here the price is doubled for bad code. The first price is for the visitor leaving the site because the download time is to long. Unless the website has a flat usage fee arrangement then most come with a transfer overage stipulation.
Where the script src include statement has a huge effect on how long it will take a site to load. Most sites typically include these just before the ending head tag. If the JavaScript file is huge or is loaded slowly the rest of the page load is severely delayed. Hence the long wait time for the visitor. Off-site JavaScript files suffer server outage that can kill the web page completely.
So a JavaScript file has been called for inclusion to a web page. The file being huge makes the visitor leave, the bandwidth has still been used. Evaluating that how can this be made more efficient without changing the code. You can minify this by removing all the white space from the file. The other thing that really does not need to happen is “cache busting”. Ever since a file(JavaScript, Image, object) with a src url of “my_image?324234″? The query on the end (?324234) is keeping the visitor browser from caching the file. So every time they repeat visit they still get a file download.
I’m all for server side testing in whatever language that’s chosen. If you’re a programmer in those languages you certainly know what I mean. I also love client side programming, yet every job or consultation I have been on takes this area as superficial; at least until the application doesn’t work correctly. More times then naught it’s because a “library” was chosen and not tested before integration.
JavaScript and DHTML client side testing is no different from server side testing. In the next part I’ll describe the initial set up of a library so that you have control of it even if the user of your code includes other vendors.
