JavaScript Battles

I’ve written a post on Read/WriteWeb about issues with JavaScript blog add-ons. Most of this post is based on our first hand experience with SmartLinks. Because this is a big deal, I felt compelled to bring the issue out there in the open and to start a discussion.

Take a look at the conversation, it is interesting already, even though the post was published late last night. If you are a developer and just want to skim for tips, here they are:

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.

A few people pointed out that you can put a widget into an iframe. This is a good idea and would work for widgets. Unfortunately it would not work for something like SmartLinks because it would not have access to the parent document.

Please share your experiences here or on Read/WriteWeb. This is an important topic and we would love hearing from you.