Peter's Blog

Redefining the Impossible

Items filed under tiddlywiki


My hunt for the perfect notetaking software has led me back to TiddlyWiki. TiddlyWiki is an amazing thing, it's a complete wiki application written in javascript and encoded into a single html file and stored on your local disk. You open the html file and can browse through the entries (or 'tiddlers' in tiddlywiki parlance) at will. You can then modify the entries or add your own and then save a new version of the html file with the modified content.

A nice feature of a TiddlyWiki file is that it is a self contained wiki, application and data, and all you need to access it is a decent modern web browser (or IE will do). While it would be nice to store all my project notes in an application such as OneNote or on a blog or server based wiki, this has a significant downside in how could I possibly store these notes in such a format that I can refer to them in ten years time without having to set up the servers needed to run them or install the applications needed to read them? The TiddlyWiki file is simply opened in a browser, how hard is that? In desperation it would even be possible to open it in a text editor. Since the files are simple html format it would be a straightforward task to write a python or ruby script to extract the Tiddlers from a file and store them in some other format.

I have used it recently on a project and was happy with my ability to keep the project under control. I made extensive use of the tagging system to use the wiki for change control. For each 'Issue' that needed dealing with I created a tiddler and tagged it as 'issue' and 'unresolved' and another tag to indicate which version of the software the problem was found in. When the issue had been fixed I could change the 'unresolved' tag to 'resolved' and add a new tag to indicate which version of the software the issue had been fixed in. Voila, I have a database within a wiki and I can list changes made to the software in any version. The resulting single html file goes into the project documentation and could easily be checked into your source control system.

TiddlyWiki also has a 'journal' feature, effectivly a way to add datestamped tiddlers making it possible to use it for a blog. A standard feature of TiddlyWiki is a Timeline listing of Tiddlers in chronological order.

If there is one looming problem with TiddlyWiki it would be scalability: as you add more and more Tiddlers to a single file it is going to consume more memory, linear searches are going to take longer and performance is going to suffer. The best solution to this would be to seperate notes into multiple wiki files. It is easy enough to link from one file to another. Another possible downside would be that graphic files are not stored in the main html file so you would have to deal with the html file and it's associated graphic files but that is not a major problem.

Recent versions of TiddlyWiki have added support for server backends so that you can save your Tiddlers on a server. There is even an online service called TiddlySpot that gives you a web based TiddlyWiki. I am not sure if storing Tiddlers on a server alleviates the scalability problems or not. The real advantage of these systems is that you don't need to carry the TiddlyWiki file around with you.

It's worth having a look at TiddlyWiki if only to admire a great piece of software design.


Filed under: tiddlywiki


Based on comments left on this site I decided to look at TiddlyWiki, a personal Wiki system. I'm quite amazed by it as it is based on a single html file that does it all: it contains the code in javascript and also the CSS. It gives you a wiki editor plus storage for your wiki entries, all in the same file.

The entries in the Wiki are stored in 'Tiddlers', most of which are hidden when the html file is displayed. When you click on a Wikilink in the file the corresponding tiddler is displayed in the same page (not in a different page as is the case in a regular wiki). You can double-click on any open tiddler to open it in an editor. If you edit the file or add new tiddlers you can save it to your local hard disk, giving you a new version of the html file, complete with your edited tiddlers. The TiddlyWiki html file can be stored where you like, even on a USB flash key, giving you a pretty portable notebook with no software to install wherever you are using it. If you were so moved you could put the file on a web server, unmodifed, where folk could explore it wiki-fashion or download the thing to their own computer and edit it themselves. Cool. The TiddlyWiki site http://www.tiddlywiki.com, is itself a TiddlyWiki.

There are variations on the TiddlyWiki code that work with a server backend to store the tiddlers but the mainstream implementation is designed to work as a personal wiki system stored on your own computer (or flash key).

In a way the single file implementation bothers me because it means the wiki wouldn't scale very well: if I put 1000 entries in a wiki these are all embedded in one html file. This will take time to load into the computers memory where the browser will create a huge DOM model for it. FireFox is pretty memory hungry.

The ServerSide implementations that exist appear to load the tiddlers on demand so may not have this problem. However, in this case I am not sure how the search facility is implemented, whether it is delegated to a database engine. I have the code, I should look. There is a closed source Ruby-On-Rails version and in theory I could download the client side code and reverse engineer the server side code but that would be an objectionable way of doing things by my value system. I would only do that with an open-source system, maybe based on PHPTiddlyWiki creating PythonTiddlyWiki.

I think I could live with multiple TiddlyWiki files, one per subject, all bookmarked in FireFox: not such a big problem to context switch. In terms of Quick Blogging there is an ALT-J keypress that starts a new 'journal entry', leaving me to type what I want, press TAB, enter the tags, CTRL-Enter to finish. That's nice.

The way entries are stored in the html file is pretty clean: DIV's store the entries, with attributes holding the metadata: title/wikiname, modification date, modifier and tags. Easy to get the data out if need be.

I'll give it a try, see if I am still using it after a week.