Ticket #137 (closed enhancement: wontfix)
|Reported by:||JeremyRuston||Owned by:||JeremyRuston|
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.