The 5 Rules of 3rd-Party Widget Development

As web developers, we incessantly complain about other people's code that we embed (out of necessity sometimes) on our pages.  Most of the time, our complaints are justified since the vast majority of 3rd-party providers develop their widgets and code in a way that negatively impacts the performance and functional integrity of the host page.

Now that we're embarking on becoming 3rd-party providers ourselves, we want to make sure we avoid all the traps that others have fallen into and that we've complained about endlessly.  Here is a list of the 5 rules that I think could make 3rd-party code a pleasure to work with:

1. USE STANDARD WEB TECHNOLOGY: Completely avoid plugins, including Flash, when building out widgets. Almost everything you can do in Flash is doable using HTML 5.
   
   


2. DO NOT IMPACT PERFORMANCE: One of the main complaints we developers have about most 3rd-party widgets is that they invariably bring our page performance down.  With page performance being part of the overall credibility of sites these days, it's very important that the widgets you create are not impacting performance at all.  This is done by:




1. Using non-blocking methods to download resources


2. Making as little HTTP requests as possible


3. Executing code when needed


4. Cache resources that don't change often
   
   




3. DO NOT USE document.write(): If you do not want to piss off the developer that is working with your code, don't use document.write().  The problem with document.write() is that it needs to be executed before the page is done loading, which doesn't give the developer much choice of when and how to include the widget.  Avoid it at all cost!


4. DO NOT DEPEND ON DOM EVENTS: Depending on onLoad or onDOMReady or any other time event on the page is a bad idea.  You're forcing the developer to add your widget before these events are fired, which might impact the performance of the page he or she is developing. 
   
   


5. PROVIDE AN API FOR YOUR WIDGET: The power of the Application Programming Interface (API) is that it gives the end developer control of when, where and how to incorporate your widget on his/her page.  The goal here is to be as unobtrusive as possible and with an API you can make that happen.  Developers will love you for it!

What do you guys think?  Does this make sense?  Did I miss anything?  It would be great to develop a test through which every 3rd-party widget goes to make sure it plays well with other components on a page.

Looking forward to your feedback.