A single line of JavaScript is what powers a lot of blogging technologies these days. Widgets, sharing tools,
visitors tracking, advertisers. In many cases a single line of JavaScript is all that a blogger needs to
add a new technology to their blog. The problem is what happens when a lot of these single lines of JavaScript come together...
There is a well-known phenomenon in physics called non-linearity: When a lot of different things interact with each other, the outcome is hard to predict. Software is no different - when you put together a lot of components, you just do not know what you are going to get. This is because each component acts as if it is standalone, but they are literally fighting for real estate space and people's attention. The truth is that this war is hurting everyone - the readers, the bloggers and the services. Everyone is frustrated.
In this post we'll take a look at what is causing pages to hang from too many single lines of javascript; and what can be done about it.
]]> Bloggers - the Unsuspecting VictimsWidgets are the new black and microchunking content is here to stay. Bloggers love showcasing their personality and favorite content on their blogs. This is why people rush to install new widgets like del.icio.us, Flickr, Twitter, AddThis, Sphere - because they are useful and there is a lot of demand for them.
Widgets are fairly easy to install if you are familiar with HTML and your blogging platform. All you need to do is paste the HTML for the widget where you would like it to appear. Sometimes you need to insert code into the head of the HTML document, but it is not that difficult. So with a bit of technical understanding, you can do it or use a platform like Widgetbox to install it automatically.
It's simple enough that people are installing more and more widgets onto their blogs; and that's where things have started to get hairy - as it may result in blogs taking a long time to load.
Not All Widgets are Implemented Equal
There are two major technologies for implementing widgets today: Flash and JavaScript. Flash widgets have their own issues; from being heavy, to being unresizable, to being unable to manipulate the DOM. However, typically it's not Flash widgets that are causing problems, it is the JavaScript ones.
The irony of this is that JavaScript was envisioned and designed to be a lightweight language to support minimum interactivity and quick manipulations of HTML documents, on the client site. But because of the twisted paths that our technology trails have taken us, JavaScript evolved to be the programming language for the web. From Ajax to Widgets, JavaScript is being used in a lot of cutting edge projects these days. But the truth is, JavaScript has its issues. Let's explore those...
How Browsers Handle JavaScript
Perhaps the most shocking reverlation to any experienced technologist is that JavaScript is a single threaded language. What this means is that it performs things sequentially and not concurrently (with the exception of Ajax calls). Anytime a piece of JavaScript is being loaded or evaluated, everything else has to wait.
This means that a single slow JavaScript add-on can slow down the loading of an entire blog. And that is exactly what is happening all over the blogosphere. So what is the solution?
Can JavaScript Widgets be Better and Faster?
Unfortunately there is no silver bullet for this problem. That is there is no single trick or technique that will resolve the problem. While there is a combination of things that companies can do to moderate the impact of being put together with other widgets, ultimately - given enough of a mix - problems are bound to happen. While as an industry we ponder on what can be done, here are some things that JavaScript providers should consider:
1. Defer the execution of the JavaScript
One of the frequent problems is that all JavaScript wants to run at once, but it really can't. If the script does not need to modify the page as it loads, the execution of the script should be deferred until after the load. This way, the content of the page will come up fist. Unfortunately, not all browsers respect this directive to defer.
2. Minimize the amount of code that runs on load
Anything that runs on a page load, slows down the load. The less code there is to run the better. Another related issue is traversing the entire page looking for something. This is a major 'no-no', since it will cause theUnresponsive Script popup. In general, any JavaScript that runs over a few seconds (typically 5) will cause a problem. Splitting the long execution by using timeouts is the right (although painful) way to go.
3. Load-balance requests by generating different URLs
Most scripts these days give you back the same URL, for example: www.mycoolwidget.com. This is not easy to scale. As the widget becomes more wide-spread, the amount of concurrent requests going through the same server will be quite large. A better approach is to give out different URLs, like this: server1.mycoolwidget.com, server2.mycoolwidget.com, etc. Even though for now they can be pointing to the same domain, in the future there will be an option to split the traffic.
4. Use Standard Libraries
Probably the worst thing is to reinvent the wheel, since JavaScript is so easy to get wrong. Unlike Java there is no set of standard libraries, but some like prototype have effectively become a standard. The libraries are written by experienced people who know and understand the pitfalls of the system, so it is a good idea to reuse their code.
5. Most Importantly - Think About it
Being aware that there are other pieces of JavaScript that will run on end user's sites, is the most important thing. By wearing the "I am part of a bigger system" hat, developers will minimize the likelihood of undermining another widget, as well as ensuring an all-round smoother user experience.
Where Do We Go From Here?
While being a good Javascript citizen is encouraged, there is still only so much that developers can do. You simply cannot know how and where your widget is going to be used. What other things will be installed? Without this information, tuning the script is difficult. And the impact is on bloggers and blog readers. So what do we do?
If we look at the Java community, this problem has actually been solved many times over. Applets, Servlets and even scary-sounding Enterprise Java Beans are not really different from widgets conceptually. The big difference is that they all are managed by containers.
A container is a hosting environment that provides delivery infrastructure and communication interfaces. It handles loading, unloading, callbacks, clicks, messages and all the good things that we engineers love and non-technical people dread to hear about. In short, we need a container for JavaScript - because a container is what brings order to the component chaos.
Conclusion
While widgets and JavaScript tools are very cool and very useful, there is no good infrastructure to make them work well today. The initial symptoms of blogs being slow to load, that are visible today, are only going to get worse as more widgets and bits of JavaScript hit the blogosphere. It is not reasonable to ask bloggers to understand the complexity, interdependencies and problems that can be caused by combining widgets.
We need automated and standard ways of delivering these widgets. Ideally we should look at how this has already been done before in the industry. The Java community was a huge success and leveraging the experiences that it had could be of great value to the widget startups.
As always, please let us know what you think. If you are a widget developer, we would love to hear the ways that you optimize your code to be more environment friendly and quick.
]]>