This is probably best shown by example. I've created a demo tiddlywiki
using a modified 2.1.0 beta 2 that extracts the maximum amount of JS
into a separate JS file:
http://www.scss.com.au/family/andrew/tiddlywiki/tiddlywikibeta.html
http://www.scss.com.au/family/andrew/tiddlywiki/tiddlywiki.js
The benefits should be obvious. If you have more than one tiddlywiki,
the JS code is shared and can be cached. If you upload your tiddlywikis
the cached JS code saves folks from having to download the whole thing
every time you make some small changes to a tiddler.
I understand that one of the primary design goals of tiddlywiki is to
have a single-file wiki. I don't disagree with that, but some simple
changes would make it a trivial exercise to pull out the engine if you
wanted.
To summarise what I've done; none of these are critical, but simply
minimise the code left in the HTML:
- Moved the version (is there a reason that's in a separate script element?) and copyright comment into the JS.
- Replaced the body onload/onunload attributes with addEvent calls at the end of the JS.
- Added a new "writeLoadSavePlugins" function to write out the Safari plugin code (and my new Opera load/save applet) and replaced the corresponding code in the HTML with a call to that function.
- I also optimised the CSS slightly.
What I also realized after doing that, was that nearly 7000 lines of
code had been removed from the HTML, leaving just over 50. The reason I
wrote a Java applet to load/save was because the Opera support using
LiveConnect? had a significant performance hit proportional to the
number of lines to be loaded. With so few lines to process, the
applet-free code becomes quite usable.
I don't expect an external JS file to ever become the default, but if a
couple of changes can make extracting the code as simple as a single
cut-and-paste operation, then that seems quite worthwhile to me.
See the discussion here.