[S5-discuss] what's new in s5

[ryan king]

Just published to the blog [http://s5project.org/news/2006/07/whats- 
new-in-s5.html]:

The current version of S5, available from <a href="http:// 
hg.s5project.org/">the Mercurial repository</a>, is not the same as  
<a href="http://meyerweb.com/eric/tools/s5/v/1.2/dev/ 
v12a2.zip">Eric's last version</a>. 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  
<a href="http://xtech06.usefulinc.com/">XTech</a> (with the help of  
<a href="http://simon.incutio.com/">Simon Willison</a>). After  
hacking this feature in (then finishing <a href="http:// 
theryanking.com/presentations/2006/xtech/talk/">my presentation</a>),  
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  
<code>innerHTML</code> to copy the slides to the notes window. I  
chose not to use <code>iframe</codes>s 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 <a href="http:// 
www.mochikit.com/">MochiKit</a>. 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  
<a href="http://www2006.org/">WWW2006</a> and MochiKit was the only  
suitable library among the interesting Javascript libaries (<a  
href="http://dojotoolkit.org/">dojo</a>, MochiKit, <a href="http:// 
developer.yahoo.com/yui/">YUI</a>, <a href="http:// 
jquery.com/">jQuery</a>) 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 <a  
href="http://meyerweb.com/eric/thoughts/2006/07/19/s5projectorg/ 
#comment-39782">Eric has expressed a liking for the non-OO version</ 
a>, 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 <a  
href="http://hg.s5project.org/s5-main">commit logs</a>.

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.

-ryan