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:
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:
1. Moved the version (is there a reason that's in a separate script element?) and copyright comment into the JS. 2. Replaced the body onload/onunload attributes with addEvent calls at the end of the JS. 3. 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. 4. 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.
I would just like to say that I find your ideas very interesting. Not only will it smooth loading, but I guess it would make it a lot more search engine optimised.
On 8/14/06, andrewg_oz <andrew.greg...@gmail.com> wrote:
> 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:
@BidiX: Thanks for the links. I wasn't aware of ptw, nor of the external plugin loader code there. Very nice.
My point still stands, though: that as much of the code as possible should be grouped into a single block. It's already 99% there, just a few small bits to tidy up.
I've been pondering this approach for tiddlyspot.com.
With a cached js file sites would load faster.
The store.cgi file could split out the js and the data. The download url could stitch them back together. Could even have a common js file for the majority of users who don't hack their code.
Might be worth the effort.
Simon.
On 8/15/06, andrewg_oz <andrew.greg...@gmail.com> wrote:
> @Hans: I hadn't thought of search engines.
> @BidiX: Thanks for the links. I wasn't aware of ptw, nor of the > external plugin loader code there. Very nice.
> My point still stands, though: that as much of the code as possible > should be grouped into a single block. It's already 99% there, just a > few small bits to tidy up.
Simon Baird wrote: > I've been pondering this approach for tiddlyspot.com > <http://tiddlyspot.com>.
> With a cached js file sites would load faster.
> The store.cgi file could split out the js and the data. The download > url could stitch them back together. Could even have a common js file > for the majority of users who don't hack their code.
> Might be worth the effort.
> Simon.
> On 8/15/06, *andrewg_oz* <andrew.greg...@gmail.com > <mailto:andrew.greg...@gmail.com>> wrote:
> @Hans: I hadn't thought of search engines.
> @BidiX: Thanks for the links. I wasn't aware of ptw, nor of the > external plugin loader code there. Very nice.
> My point still stands, though: that as much of the code as possible > should be grouped into a single block. It's already 99% there, just a > few small bits to tidy up.
Also think of the ease with which you could update multiple TWs....Point them all at the same file and then all you have to do is replace the main js file, or each plugin if they are their own file.
Question: Would having each plugin as a seperate js file mean that they could be set to download only when needed?
Either way it seems to get me closer to my mad dream of trying to get the GenCon program book into a TW. 5500+ fully searchable events, with tags to help group them, in a file small enough that folks can download it, allowing them to toggleTag the events they want to attend so they can print thier own itinerary. Just a nice way to get 25,000+ gamers exposed to TW.
On 8/15/06, Simon Baird <simon.ba...@gmail.com> wrote:
> I've been pondering this approach for tiddlyspot.com.
> With a cached js file sites would load faster.
> The store.cgi file could split out the js and the data. The download url > could stitch them back together. Could even have a common js file for the > majority of users who don't hack their code.
> Might be worth the effort.
Simon,
I think you are right. Inspired by your post, I just release a new DownloadService that do the trick. See other thread.
>Question: Would having each plugin as a seperate js file mean that they >could be set to download only when needed?
That's an interesting idea. I guess currently this is not possible, because of the way plugins are currently written.
Some plugin code must be executed at startup time to do "registration stuff" (e.g. to tell TW that a macro with a given name exists or for doing the formatting). But probably one could try to separate out this registration code (that is typically quite small) and rewrite it in a way that the main (and big) block of code is only loaded when really used. The small "register/loader" part would be included in the TW and the main code in the external file.
Especially for large plugins that may not always be used (like my IntelliTaggerPlugin (http://tiddlywiki.abego-software.de/#IntelliTaggerPlugin) ) this would be an interesting alternative: if you are just viewing a TiddlyWiki (and never edit its tags) you don't need the extra 35 kByte of JavaScript of the IntelliTagger. The first time you start editing tags the rest of the code is downloaded (may take a little) and then you can continue working at full speed.
BidiX: do you think this can already be done (with some extra client side coding) with the code you provided, or needs the server side code to be extended?
Ken Girard wrote: >Also think of the ease with which you could update multiple >TWs....Point them all at the same file and then all you have to do is >replace the main js file, or each plugin if they are their own file.
>Question: Would having each plugin as a seperate js file mean that they >could be set to download only when needed?
>Either way it seems to get me closer to my mad dream of trying to get >the GenCon program book into a TW. 5500+ fully searchable events, with >tags to help group them, in a file small enough that folks can download >it, allowing them to toggleTag the events they want to attend so they >can print thier own itinerary. Just a nice way to get 25,000+ gamers >exposed to TW.
> 1. Moved the version (is there a reason that's in a separate script > element?) and copyright comment into the JS.
Yes - originally I wanted to keep the two copies of the date and version close together at the top of the file to minimise the chances of me forgetting to update them both when publishing a new revision. These days, though, the Cook utility should really stitch in the version number and date.
> I would just like to say that I find your ideas very interesting. Not > only will it smooth loading, but I guess it would make it a lot more > search engine optimised.
I've not investigated it seriously, but to a cursory examination TW appears to be already at least fairly search engine friendly. For instance, searching for the generic phrase WikiOnAStick returns TW.com quite high up the results:
Similarly, ego searching me returns tw.com as the top match. So I think that means that google can certainly see TW entries, and treats them fairly compared to other type of web page.
Well I tried it with my site and here are the results:
Main tiddlywiki file before: 819K after removing the javascript it reduced to 658k (a saving of 161k). I also had to remove the code for the spashscreen script as this refused to work with the new method.
The javascript file ended up at 165k.
So the saving was not that great but it makes a difference if using dial up modem.
> Well I tried it with my site and here are the results:
> Main tiddlywiki file before: 819K after removing the javascript it > reduced to 658k (a saving of 161k). I also had to remove the code for > the spashscreen script as this refused to work with the new method.
> The javascript file ended up at 165k.
> So the saving was not that great but it makes a difference if using > dial up modem.
Saving? How are you saving? Are you uploading the entire TW file somewhere? Why not use a server-side, which would upload only tiddlers one at a time as you edit them.
-- Cheers, Bob McElrath [Univ. of California at Davis, Department of Physics]
Only after you've tried to figure something out for yourself and failed are you ready to absorb "the answer."
Jeremy Ruston wrote: > I've not investigated it seriously, but to a cursory examination TW > appears to be already at least fairly search engine friendly. For > instance, searching for the generic phrase WikiOnAStick returns TW.com > quite high up the results:
> Similarly, ego searching me returns tw.com as the top match. So I > think that means that google can certainly see TW entries, and treats > them fairly compared to other type of web page.
Sure Jeremy,
But as we all are familiar with, Google don't just return the web documents with the right words. They also rank the pages according to links leading to your site. And I can tell you that there must be thousands of people and sites linking to tiddlywiki.com and mentioning your name.
But what do I know? My knowledge about search engine optimization is limited and Tiddlywiki could be quite well adapted. Thanks for a great product anyway.
I sometimes get GTD related ads, which makes me think that google can index the site reasonably well. Of course it could be using links to the site to help guess.
I sometimes get car related ads, I think because one of my GTD example projects was selling a car...
> Jeremy Ruston wrote: > > I've not investigated it seriously, but to a cursory examination TW > > appears to be already at least fairly search engine friendly. For > > instance, searching for the generic phrase WikiOnAStick returns TW.com > > quite high up the results:
> > Similarly, ego searching me returns tw.com as the top match. So I > > think that means that google can certainly see TW entries, and treats > > them fairly compared to other type of web page.
> Sure Jeremy,
> But as we all are familiar with, Google don't just return the web > documents with the right words. They also rank the pages according to > links leading to your site. And I can tell you that there must be > thousands of people and sites linking to tiddlywiki.com and mentioning > your name.
> But what do I know? My knowledge about search engine optimization is > limited and Tiddlywiki could be quite well adapted. Thanks for a great > product anyway.
In a subsequent release I'd like to use the same technique to optionally produce a static HTML rendering of the DefaultTiddlers and splice it into the top of the HTML section of the document. This HTML rendering would enable the document to be viewable on simple browsers, as well as presumably being more search engine friendly.
Cheers
Jeremy
On 8/23/06, coolcold <google.coolc...@dfgh.net> wrote:
> Hi,
> not sure if you would be interested but freeshell.org have "free" > accounts that provides PHP access.
