“ 的对话框。一般来说，运行时间超过一定时间（通常是5秒钟）的 JavaScript 代码会产生这个问题。一个适当（也很痛苦）的解决方案是：使用定时机制来分割一个较长的执行过程。

3. 通过生成不同的 URL 对请求做负载均衡

大多数 JavaScript 代码只提供同一个 URL，例如：www.mycoolwidget.com。这样做不利于系统伸缩（scale）。JavaScript 小应用使用得越广泛，同一个服务器接受到的并发请求的数目就越多。一个更好的尝试是使用不同的 URL，例如像这样：server1.mycoolwidget.com，server2.mycoolwidget.com，等等。当前可以暂时把所有这些 URL 指向同一个域，作为未来分流流量的一个可以选择的后备方案。

4. 使用标准库

因为编写 JavaScript 代码容易出错，所以重复发明轮子（reinventing the wheel）的尝试可能是最糟糕的一种做法。JavaScript 与 Java 不同，没有所谓的标准库，但某些库（比如：prototype）正在变成事实上的标准。这些库由富有经验、了解系统特性的开发者编写，重用他们的代码是一个理想的选择。

5. 最要重要的是要考虑到别人

要认识到在最终用户的网站上还运行着其他的 JavaScript 代码，这是最要紧的事情。脑袋里有了 “我是一个系统的一部分” 的想法，开发者就能够在最大程度上避免破坏其他 JavaScript 小应用的正常运行，从而带来全面、流畅的用户体验。

从现在起能做些什么？

做一个良好 JavaScript 公民是受到鼓励的行为，然而，开发者还可以做得更多。作为开发者，你不能预测你的 JavaScript 小应用会在哪里、会被怎样使用，以及除了你的 JavaScript 小应用之外还安装了什么东西。不了解这些，就无法对代码做进一步的性能调整。而不好的结果却要让网志作者和网志读者来承担。那么我们要怎么做呢？

如果我们将目光投向 Java 社区，就会看到这个问题已经被解决了许多次。Applet、Servlet 甚至 EJB 在概念上和 JavaScript 小应用都没有什么本质的不同。最主要的差别在于Applet、Servlet 、EJB都被容器管理。

容器是一种寄存环境，提供传送基础设施和通信界面。容器处理载入、卸载、回调、点击、消息等等所有这些工程师热爱而非技术人士害怕听到的东西。简而言之，我们需要 JavaScript 的容器，从而给混乱的组件带来秩序。

结论

JavaScript 小应用和 JavaScript 工具看起来确实很酷，也很有用，但现在还没有合适的基础设施能够保证让它们好好工作。网志载入越来越慢的初始症状现在已经出现，随着更多的 JavaScript 小应用和 JavaScript 代码进入网志的世界，情况会变得更糟。而要求网志作者去理解组合使用 JavaScript 小应用带来的复杂性、相互依赖性等问题显然并不合适。

我们需要自动化、标准化的方法传送 JavaScript 小应用。我们应该在观念上学习软件行业中已经成功的做法。Java 社区已经取得了巨大的成功，充分利用他们取得的经验对于刚起步的 JavaScript 小应用开发企业来说有着重要的意义。

和往常一样，请告诉我们你的想法。如果你是一个 JavaScript 小应用开发者，我们很想知道你如何优化你的代码使之对环境更友好、运行得更快。