What’s new in S5?

The current version of S5, available from the Mercurial repository, is not the same as Eric’s last version. I’ve made some changes. Please note that when I started making these changes, I was doing it just for fun and as a private fork. I’m open to changing any of them.

First of all, the reason this all started– I added previews of the actual slides to the notes window. I say “the reason this all started” because I made this hack while working on a presentation at XTech (with the help of Simon Willison). After hacking this feature in (then finishing my presentation), I realized that S5 could benefit from having a wider development community. So, here we are.

Anyway, my implementation of this is still lacking. I’m using innerHTML to copy the slides to the notes window. I chose not to use iframes because I didn’t want to create the overhead of loading a separate resource for browsers. As always, I’m open to changing this.

Either way, the current version is ugly – the layout isn’t quite consistent and the slides don’t have the actual styles from the theme. I’m sure someone would love to volunteer to work on this. *hint*, *hint*

The second change I’ve made is to incorporate MochiKit. The second round of work I did on S5 (after the aforementioned hack), included using MochiKit for both DOM manipulation and signaling. I really like their signaling API, despite the fact that there’s a bug with it in Safari (its a Safari bug, AFAICT).

Why’d I choose MochiKit? Well, to be honest, I was working on this offline during a layover at Heathrow airport on my way from XTech to WWW2006 and MochiKit was the only suitable library among the interesting Javascript libaries (dojo, MochiKit, YUIjQuery) that I had already downloaded. So, there it is.

A feature I’d like to add in the future is transitions, both between slides and in incrementals. MochiKit doesn’t have support for this, but some of the above libraries do. As cool as all the libraries are, I’m concerned about require too large of downloads for presentations. But, we can cross that bridge when we get there.

A third change I’ve made, which may be a bit controversial is this: I rewrote the whole application as an object. I know that Eric has expressed a liking for the non-OO version, but I think there’s a real and significant advantage to the OO version- it’s easier to write unit tests (and we will have them soon, I hope). I’ve written it by building on the prototype object, not as an object-literal. I’m sure this will cause a religious war. I dont’ really care either way, I’ve just never gotten used to the object-literal syntax.

There may be some concern about the Object-based version being less performant. This may be the case, but even so, I’ve made other changes that had even more drastic improvements in performance. There were several situations where an entire list of DOM nodes was being retrieved repeatedly (i.e., on every slide change). In those situations, I changed S5 to grab that list at startup and store a reference to it. I noticed a significant speedup from this change, though I don’t have any numbers to back it up.

I have a done a bit of timing/profiling, and it seems that for most interactions (like changing slides), only a few milliseconds is spend actually executing the javascript, then a significantly longer period of time (on the order of hundreds of milliseconds) is spent re-rendering. If we want to make S5 faster, I think we need to look at ways to make rendering happen faster.

There have been some other minor changes, which you can see in the commit logs.

Ok, hopefully I’ve gotten everyone caught up to what I’ve done. Next up, I have some ideas for the future (and I’m sure you do, too), but I won’t get to those until tomorrow.