The whole world is going to widgets. This overused, overhyped term refers to third-party code one places on their website or blog in order to display such things as Flickr photos, Twitter status, or iTunes playlists. Everybody and their mom is putting out widgets these days, and although only about 1% of them are useful or interesting, they are an important new distribution mechanism that is changing the way companies think about syndication.<\/p>\n
But there is a big problem with widgets: they slow down the sites that use them<\/a>. In the best case, you have a company like Flickr whose servers are almost always snappy, and in the worst case, you have a young startup that is constantly struggling against increasing demand and occasionally can’t serve up any code at all.<\/p>\n The problem is that in either of these cases, the completion of your site’s loading and rendering depends on someone else’s code living on someone else’s server. Including a fast and reliable Flickr widget still slows your site down by at least a split second and including a less stable one can leave your site hanging indefinitely.<\/p>\n We’ve been developing what we think is going to be a gangbusters widget at Newsvine<\/a> over the last few months but just as we were getting ready to deploy it, Intern Rob<\/a> and I hacked together what we think is a method of deploying widgets in such a fashion that they don’t affect the load times of their parent sites whatsoever.<\/p>\n Following is a breakdown: Most widgets are deployed using one of two methods: raw embedding or javascript embedding.<\/p>\n Raw embedding usually involves providing a chunk of Javascript embedding involves using a Providing a raw embed method is still a necessity if your target environment is MySpace, but if you’re going after people with their own sites\/blogs, javascript embedding is still a better ideal. We need a catchy acronym for our method in order for people to use it so we’re going with: WEDJE. Or, “Widget Enabled DOM Javascript Embedding”… which is an acronym inside of an acronym, so it’s extra cool.<\/p>\n In a nutshell, here are what the two existing javascript methods do versus what WEDJE does:<\/p>\n Most javascript embedding simply uses The other method of javascript embedding is to write out a WEDJE is similar to the By linking elements together in this way, browsers appear to completely decouple the loading and execution of our attached javascript from the loading and execution of the original document, which is exactly what we’re looking for.<\/p>\n An example of WEDJE in action is below. Reload this page and watch the area below. There is a 7 second delay in the execution of the javascript file in order to simulate a slow-loading script:<\/p>\n This text is before the widget code.<\/em><\/p>\n\r\n
\n<\/p>\nRoot Causes<\/h3>\n
object\/embed<\/code> code to display a Flash widget inline. The advantage of this method is that it works in environments like MySpace which don’t allow the use of javascript. The disadvantages are that a) many people don’t like placing raw Flash code in their pages, b) some widgets aren’t Flash-based, and c) the widget author can’t change much after the fact since the widget’s code is more or less set in stone.<\/p>\nscript<\/code> include to remotely deploy code into the user’s site. The advantage is that it’s much cleaner and more flexible. The disadvantage is that it slows sites down a little every time and a lot<\/strong> when there are problems.<\/p>\nThe Solution: WEDJE<\/h3>\n
Standard
document.write<\/code><\/h4>\ndocument.write<\/code> to write code into your site inline. The problem is that if the widget server hangs, the rest of your site can’t draw until the script is done executing. This could be a split second or it could be forever. Many people mistakenly think you can use the defer<\/code> attribute in your script tag to keep this from happening, but defer<\/code> effectively kills the document.write<\/code> function entirely so this is not a solution.<\/p>\nDeferred
innerHTML<\/code> code<\/h4>\ndiv<\/code> with an ID<\/code>, load the javascript with the defer<\/code> parameter added, and then use innerHTML<\/code> to write to the div<\/code> whenever the script has loaded. This seems great in theory, but in reality, Internet Explorer is the only browser which seems to properly render the rest of the page before the script is done executing.<\/p>\nWEDJE<\/h4>\n
innerHTML<\/code> method above except it creates what is effectively a cross-platform, cross-browser defer, enabling your script to load and execute asynchronously across all environments. We write out a div<\/code> with javascript, then we create a script<\/code> element with javascript, and then we append the script<\/code> element to the div<\/code>, again with javascript.<\/p>\n