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
Bloggers – the Unsuspecting Victims
Widgets 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
Flash widgets have their own issues; from being heavy, to being unresizable, to being unable to
to support minimum interactivity and quick manipulations of HTML documents, on the client site. But because
Perhaps the most shocking reverlation to any experienced technologist is that
evaluated, everything else has to wait.
And that is exactly what is happening all over the blogosphere. So what is the solution?
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
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
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
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
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?
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.
to make them work well today. The initial symptoms of blogs being slow to load, that are visible today,
to ask bloggers to understand the complexity, interdependencies and problems that can be caused by
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.