We recently issued a new release of the Sharendipity platform that was aimed at improving launch performance. One of the issues that we addressed was the scripting engine that allows advanced users to extend the core functionality of the platform.

You might think that the underlying scripting engine is only important to the authors of shared assets in Sharendipity. The reality is that the wrong scripting engine can provide a very negative impression of application performance to any user.

Originally we used the Jython project to provide scripting using the Python language. The functionality was great. It was even fast. Despite this, there were a few big problems.

Jython is large. The download size for Jython alone was nearly 1.2MB. The result of this is that the user’s first experience when launching our applet takes significantly longer, directly affecting the percentage of users that are willing to sit through the download.

This wasn’t the biggest problem though. Our number one issue was the initialization time. On many users’ machines this was commonly around 10-15 seconds. When a user launches an application in Sharendipity, it may require the use of scripts before doing anything else. We needed the application to launch and run immediately and this just wasn’t possible with Jython.

Our most recent release changed our underlying scripting engine to use the Rhino JavaScript implementation. Rhino fixes every single issue that we had with Jython.

The Rhino developers understand the importance of a small footprint. Rhino provides a very easy way to reduce the download size to as small as 204KB, or about 20% of the size of Jython. There is no initialization time for the Rhino engine either, so there is no pause when loading an application in Sharendpity.

The smaller download and lack of initialization are a huge win for us already. There’s also something else that developers might not think about when choosing a scripting engine, and that’s portability.

We’re still in Alpha mode, so we have enough flexibility to change our scripting implementation. JavaScript (or ECMAScript), is the only scripting language that was really an option when creating a Rich Internet Application. This is what ActionScript, Flash’s language, is based on, and Silverlight supports it as well (in some respect, at least). Furthermore, just about every web developer in the world knows it.

We’re trying to strike a balance between the demands of our power users and the ability for our casual users to launch existing content very quickly. We’d love to hear your feedback on walking this tight line!

Trackback URI | Comments RSS