Intially TiddlyWeb was oriented toward being the perfect "reference" server-side for TiddlyWiki: other implementations would be created that use the same HTTP API, but optimize for different situations or environments. Being a reference impacted the design and architecture:
- The code needed to be transparent and easy to read. I chose Python. I was coming down from a few years on Perl so it was the obvious choice for me. There were concerns at the time that this would mean it would not get used by non-technical users, who more commonly had access to PHP. The hope at the time was that someone would do a PHP port if the API was proven useful.
- The architecture should be effectively layered and extensible to allow use in lots of different situations (e.g. different storage and authentication scenarios).
- The implementation of HTTP handling should be relatively pure, to set a good example.
- TiddlyWeb would need entities that represented containership and composition of tiddlers. Thus bags, recipes and filters.
- Tiddlers were to have names, not identifiers to preserve their character. This was a contentious decision.
Because there was a desire for the code to be clear about what was happening to the HTTP request and response, straight WSGI was used, without frameworks such as Django or request objects such as WebOb or Werkzeug. These abstract away important details.
I set to work. I made sure that I had good tools for testing (py.test, wsgi-intercept) and took a test driven approach while being willing to throw away anything that didn't work. There was a fair bit that could be borrowed from the Socialtext setup:
- notions of how to do content negotiation
- multiple representations of resources
- clean, clear and cool ~URIs
but more importantly there were several things which we didn't do but wanted to so I did them in TiddlyWeb:
These turned out to be of critical importance. A default TiddlyWeb installation is simple with low requirements. That same code base can be built up to support thousands of users and hundreds of thousands of tiddlers with the right extensions and plugins. That's how we get TiddlySpace, wiki-data and ILGA.
TiddlyWeb was initially built working to an abstract goal. I tried to have good YAGNI behavior, but taken too far that would have resulted in nothing being created: There was no active customer of the concept. Once an initial working prototype was available other people were able to help get it built in the right direction.
This is when it started becoming clear that a lot of our early assumptions were incomplete or wrong. The original belief was that TiddlyWeb would be used as a backend to TiddlyWiki-based applications (called verticals) allowing TiddlyWeb to remain relatively simple. Turns out this was only partly the case. People wanted to be able to use TiddlyWeb as a web app development framework with tiddlers (not TiddlyWiki) as the main data store and point of entry. The flexible serialization system meant that rather complex things could be done with one or many tiddlers with ~UIs created and managed from the server. An early example was ILGA.
All this development was happening in full view of the TiddlyWiki open source community. As they and the other Osmosoft developers tried things, the many eyes made bugs shallow.
Eventually TiddlyWeb came to a bit of standstill. It was sufficiently complex to setup and then to manage that it did not penetrate beyond a savvy but fairly small audience. In particular many existing TiddlyWiki users who might have been interested in using TiddlyWeb did not have access to the resources to make it go. At Osmosoft we decided to create TiddlySpace to make tiddlers on the web easier to access by creating a multi-user environment where people could curate and share tiddlers and reuse (through inclusion) tiddlers from other people.
Again the initial goal was to make a TiddlyWiki based interface and again this proved to be constraining. TiddlySpace has made it clear that in the tiddly universe the tiddler is the thing. To some extent this is simply a matter of physics: a TiddlyWiki is a large single entity containing lots of other things. It is big and slow to load, just one thing, yet non-atomic. It is complex. A tiddler is just one thing, but one thing that can come in many forms.
The vast majority of use on TiddlySpace is done from within TiddlyWiki, but the (IMHO) innovative work is done with tiddlers and simple JavaScript based applications, often presented as ~SPAs: Single Page Applications. A tiddler operates as the data entity, the viewer of those entities, and as documents. Many different JavaScript tools have been used in the process: jQuery, Backbone, Bootstrap, etc.
TiddlySpace caught on pretty well, re-energizing TiddlyWeb development. For the first time large numbers of requests for large numbers of entities were being made. TiddlyWeb was shown to be slow and needed to be fixed. The large user base provided the data necessary to do accurate measurement and optimize those parts of the code that matter. This mostly meant turning naive Python into slightly more interesting Python (e.g. lists into generators) but also hardware, database and cache tweaking.
Additional features were created as well:
Eventually TiddlySpace became fast and functional enough that it is now a useful place to do web development in addition to web publishing. Either with TiddlyWiki or without. The tiddler operates as a nice augmented container for //something// on the web. It is quick and easy to make stuff and reference stuff. A web with some improved webby affordances.