Javascript ‘memory leaks’

August 15th, 2007

Well, we all call them memory leaks, anyway - although they are more like the telltale signature (kind of like William Shatner singing Karaoke) of a garbage-collecting-challenged browser. In addition to reference counting maybe the garbage man should add reachability counting?

Speshy tries and prevents these leakish-like events by by letting JS objects point to DOM objects, and NOT letting DOM objects point to JS objects - except for event handlers, of course.

Event handlers on DOM objects point to JS objects, and we use Prototype’s Event.observe method to cache these event handlers and remove them, calling Event.unloadCache, when no longer needed.

Since our pages are dynamic, we are constantly adding and removing objects, and so we added a method to Prototype, in addition to Event.unloadCache which blasts all event handlers, to blast just those event handlers that are assigned to the DOM object sub-hierarchy we want to remove.

For grins, here it is:

unObserve: function(element) {
    if (!Event.observers) return;
    element = $(element);
    if (!element.sp_oid) return;
    element.sp_oid = null;

    for (var i = 0; i < Event.observers.length; i++) {
        if (Event.observers[i][0] == element)
        {
        Event.stopObserving.apply(this, Event.observers[i]);
        Event.observers.splice(i, 1);
        --i;
        }
    }
},

DOM elements that have been assigned an event handler have their sp_oid attribute set. In order to speed this up some, since the vast majority of elements will NOT have an event handler, and it would be a crying shame to iterate through this loop for each and every one of them in each DOM sub-hierarchy we want to remove, we just quickly return if sp_oid is not set.

It seems to work so far, according to the Drip (a memory leak detector for Internet Explorer) . Not a very ‘Spock’ thing to say, more a Bones-like prevarication, but the probability of an error creeping back in is not close to zero (kind of why we got rid of malloc and free in the first place, right?)

Anyway, hope these insights into the amazing adventures that are our daily life are of interest. Not too many javascript frameworks out there yet…

Enjoy!

Release 0.88

August 12th, 2007

Another Alpha (Pre-Beta :-)) release.

In this release:

The widget API has stayed largely the same.

Added the toolbar which widgets can add and remove buttons from as they are loaded and unloaded, respectively.

We took the page and site-wide plugin panels out for this release - they didn’t get converted to the new look-and-feel quick enough. They should be back into the next release.

We went back to using real URLs. Previously, all 160 or so of Speshy’s pages were at one URL, each page with a unique (#) bookmark to support some kind of bookmarking and the browser ‘back’ button. It worked OK, and we didn’t run into any stability issues (re-installing the javascript app every single page, like we do now, is kind of like rebooting every page). The problems were that the URLs would look like ENTRY PAGE URL/#ACTUAL PAGE, which might be OK if there was only one entry page, like ‘/pages/’ but we wanted to support categories in the URL (for SEO purposes), so we ended up with URLS like /technology/computing/#pets . And, with the browser caching the javascript, the difference in speed between building the page and reloading and building the page were not that large (about a second on Firefox on this ancient single-processor 3.2 GHz box, a second of two longer on IE 6)

Next releases:

We are going to enhance the API to specifically callout widget refreshes - in order to optimize network traffic a little.

Welcome Speshy Developers

August 12th, 2007

This blog is supposed to be about developing 3rd party widgets on Speshy - but I think the topic may meander some as we talk also about the trials and tribulations of developing Web 2.0 apps, 99% javascript pages, SEO and whatever else strikes our fancy (I have to be careful, my fancy ain’t what it used to be).

Speshy is implemented as a widget-based desktop written in Javascript that has some unique advantages for developers and one disadvantage.

To get the disadvantage out of the way first, it is that the code is still changing. And we all know what it is like to develop on top of a platform that is changing - while not quite willy-nilly - still more than someone who wants to remain sane would like.

So, developing widgets for Speshy at this time is not for the faint of heart. Just so’s you know and all…

The advantages are:

  1. The source code of each widget can be viewed directly on the page it is being used on. This allows you to kind of poke around and see how other widgets are being written. To see the source code, open the widget’s form by putting the mouse over it’s header and clicking on the ’form’ button, and then the ’advanced’ button.
  2. The source code of each widget on the page can be modified by the javascript programmer. This means you can create your widgets by modifying someone else’s widget. Note that this is not a subclass but a implicit copy operation.
  3. The widget can be edited directly on the page. Fast turn around times. The page is the development environment.
  4. Speshy can be run in ‘debug’ mode with uncompressed source with inline documentation (such as it is, we’re working on it) and logging is provided to help debug any problems. Good/bad ole logging. We also use the Venkman debugger but you are free of course to use whatever. Debug mode can be entered by putting ‘debug’ in the URL.
  5. Full source is available to help debug any problems.

It seemed to us, that 1 and 2 and 3 together make for a very intuitive environment, where any widget on any page can be customized by a programmer, right there on the page. Much more like the real world outside of the computer. And for this we really have to thank javascript coming of age, broadband internet, and cheap disk space.

Well, that’s it for the first post.

’till next time…
-Mike