A couple of fairly extensive email threads on the TiddlyWeb google group have resulted in some noodling on the nature of TiddlyWeb, tiddlyweb-based applications and how those things differ from other tools associated with web based development. The threads have made it clear that those differences are less clear but more important than was previously obvious so I’m restating them here for future reference.
While it is the case that TiddlyWeb can be used as the basis for developing web applications, it was not designed or developed to be a general web framework. Yes it does have facilities that allow one to create what amount to views and controllers that operate with a model that is stored in and represented by TiddlyWeb. But no, it does not (yet) have facilities which ease the creation, construction and deployment of a project which could be identified as a TiddlyWeb project. Such things might be created at some time, but if they are they will be pieces that are external to TiddlyWeb itself. Add ons.
This is because TiddlyWeb is not and has no intention of being a full-stack, all in one, web application rapid application development platform. It adheres to a philosophy of componentization, modularization and composition. This philosophy is most apparent in the TiddlyWeb approach to installation and deployment of applications or projects. Those were the topics at hand in the email threads referenced above.
TiddlyWeb makes a big distinction between deployment and installation. Installation is getting the software and related common components installed on the server. This involves packaging and is closely tied to what is found in the setup.py file associated with a python package (and thus a TiddlyWeb application, because that’s what a TidldyWeb application is: a Python package).
Deployment is getting a version of the application, customized for my specific needs, running on my target machine(s), with all the expected initial data. In the TiddlyWeb universe, when you deploy, what you are doing is handling the special cases of a particular instance. All the general cases should be handled by simply installing (e.g. pip install) the package which contains the general application.
This differs quite a lot from “proper modern” frameworks like Rails. In Rails you install Rails, you generate a project, you install (in the project) the various plugins you might need. You then edit, in the project, your views and controllers and associated files. Throughout this process you are likely committing the entire project, or at least significant portions of it to a code repository. Other developers, on their machines, have Rails installed too, they can hack on your project too by doing a checkout. On the production server(s) you’ve got Rails installed and something like Capistrano which takes your project and makes it go.
That model could be developed for some TiddlyWeb applications if an enterprising person were to aggregate the necessary parts into a TiddlyWeb-as-a-framework toolset. Using TiddlyWeb as a framework is a relatively new thing so there hasn’t yet been time to identify and extract the kinds of patterns that would lead to the application development systems. Django and Rails, the two most buzzworthy full-stack frameworks, emerged out of existing applications and application development processes.
I personally have not spearheaded development along those lines because it is not the way I, personally, prefer to work. I work via a process of decomposition to comprehensible and distinguishable parts. I then make, as independently as possible, those parts. Later I compose those parts, plus parts from other people, as required, in different and exciting configurations. Those “parts” are usefully black-boxed for me but at the same time extremely flexible in how they can be used.
I work like this because I come out of the Unix tradition. 20 happy years of me working with small tools doing small, fairly specific, jobs. All these tools composed in fun and flexible and ultimately extremely powerful ways.
So the TiddlyWeb application development strategy (for me) is:
- Think.
- Decompose.
- Make some bits (i.e. tools).
- Make a bit which is the bit which assembles the bits.
- Install the bits somewhere.
- Tweak them as necessary for special cases in any instance.
If you are the sort of person who can’t think without coding at the same time (I’m often like this) then fine: Think in code then extract the decomposable bits. Use code as a scratchpad, with the results eventually being something you can reuse later.
There are two critical parts to this model: One is that it is essentially reentrant at any step. Your environment may already include some bits (i.e. tools) which you are using as fundamental building blocks to make your building blocks (which you’ll use later to build other things). They are “just there”. TiddlyWeb itself is such a thing for TiddlyWebWiki.
The other is the bit which is the bit which assembles the bits. This must exist, but because it addresses granular bits, the assembly is both easy to comprehend and to adjust. And because it is itself just a bit, it can be addressed by other assemblers.
It is clear there are plenty of people who do not work this way. In my efforts to understand the differences I’ve looked for parallels or patterns. What I’ve found is that the people who seem to get my method easily come out of a Unix administration or systems programming background or are just Unix naturals, whereas the people that struggle are traditional OO-based developers (with a preference for inheritance and identification by class rather than composition and identification by behavior), developers raised on rails/php or other start-you-from scratch frameworks, or just plain non-Unix people.
It takes all types to make the world go round, so that there is difference is good but what’s needed are some ways (I’d say tools) to bridge the gap. What this comes down to is a need for greater engagement from the non-Unixy side. Any takers?
