Rearrange code to allow easy extraction of the "engine"

[andrewg_oz]

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:

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.

[Hans]

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.

[BidiX]

On 8/14/06, andrewg_oz <andrew....@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:

I think BramChen at http://ptw.sourceforge.net/ had already done a similar job and he maintains such a distribution. He has also coded a plugin that load extensions as js file: http://ptw.sourceforge.net/index-en.html#LoadExtPlugin

Hope that helps,

-- BidiX
http://TiddlyWiki.bidix.info

[andrewg_oz]

@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]

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.

 

simon...@gmail.com>

[Udo Borkowski]

FYI: Jeremy added a ticket for this issue: http://trac.tiddlywiki.org/tiddlywiki/ticket/137


Udo

[andrewg_oz]

Cool. Thanks Udo - and Jeremy! :-)

[Ken Girard]

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.

Ken Girard

[BidiX]

On 8/15/06, Simon Baird <simon...@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.

Cheers,

-- BidiX
http://TiddlyWiki.bidix.info

[Udo Borkowski]

>
>
>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?

Udo

[freewargamesrules]

If like me you don't have PHP enabled on your webhost separating the
javascript from the tiddlers in HTML would be a big saving.

My wiki is over 800k if I can shed with all the plugins 300 - 400k by
javing all the script in the.js file this would save on download time.

I might play around with this one to see what savings I can get

pete

[Jeremy Ruston]

> 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.

Cheers

Jeremy

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[Jeremy Ruston]

> 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:

http://www.google.com/search?q=wikionastick

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.

Cheers

Jeremy.

[freewargamesrules]

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.

This was using version: 2.0.11

Pete

[Bob McElrath]

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."

[freewargamesrules]

Without PHP on my server as it would double my hosting costs, this
"could" be worthwhile.

It reduces the upload for each change as I'm saving 161k on each
upload. As I have a capped upload/download host as well it all helps.

Just a thought..

[Hans]

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:
>
> http://www.google.com/search?q=wikionastick
>
> 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.

/Hans

[Simon Baird]

My experience with adsense on a TW site does show its not all hopeless.

 

Take a look here:

http://monkeygtd.tiddlyspot.com

 

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...

 

Simon.

 

--
Simon Baird <simon...@gmail.com>

[coolcold]

Hi,

not sure if you would be interested but freeshell.org have "free"
accounts that provides PHP access.

CC

[Jeremy Ruston]

I've just implemented for 2.1 a nice solution for getting TiddlyWiki
to produce properly formatted RSS feeds, with HTML links etc:

http://trac.tiddlywiki.org/tiddlywiki/changeset/567

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