A while back I was working on a javascript based video solution, and I wanted to make it as simple as possible to include a video widget into a page. This would be roughly along the lines of…
1: <script type="text/javascript" src="blah.js"></script>
2:
3: <script type="text/javascript">
4:
5: mycompany.video.addVideoWidget({
6: siteId: "Heat",
7: keywords: "Britney Spears",
8: parent: "Id of the container"
9: });
10:
11: </script>
When authoring a script like this, it needs to be entirely self-contained as you have no knowledge of what other scripts have been included on the host page, or what versions etc.
The issue is how to offer this script when you have a dependency. In this case I wanted to use swfoject as a reliable way to add a flash movie to a page. Another common scenario would be writing script on top of jquery. An example is Typekit who end up packaging up and distributing jquery as part of the code they require you to download – discussed here.
Given that you have no working knowledge of the host page, the only possible option is to package up the dependency, avoid naming conflicts, and include it with your script logic. However this seems quite wasteful given that the host page may also include the same library.
We are so used to using libraries now to make javascript a pleasurable activity, the idea of writing raw script, while possible, is really not an enjoyable prospect.
I don’t have a good answer to the problem – I ended up going down the same route that Typekit have gone. The only other option is to provide a flavour which requires the host page to implement the dependency, but then you lose the simplicity and are open to tricky issues around versioning.
Still, I guess life is short and bandwidth is cheap.
