Why Files
· Andrew Lisowski
The core idea behind tcm is that there are no files: your code is stored in a database (called a codebase). But that raises the question: why do we store code in files at all?
Well, the answer is kind of obvious: that's just how computers work! But that's not the full story. Files are there because we put them there. Files help us define something, organize similar things into groups, and then group those further into folders. Seems necessary? Maybe not.
The downsides of files for code
So files and folders are (seemingly) good for organizing our code, but what baggage comes with them?
- Placement comes with constraints - Putting a bit of code in a package seems simple, right? Not really. That package might only work on the server, so code the client needs can't go there. If you want that code on both the server and the client, you have to set up a third package to hold the shared code. You'll also have to make sure that package stays isomorphic, or else your bundle might blow up or your server might crash.
- Files need managing - Is a value really used? We can try to rely on our tools, but cruft accumulates. Is the file too long? Too short? Too spread out? You need to decide ahead of time how much or how little should go where. That might make sense in the moment, but not as a project evolves.
- Folders - And once you have files, which folder do you put them in? Oh, that changed? Now countless files have to change. Just like with files, we have to anticipate the ideal structure, then suffer later when it inevitably turns out to be slightly the wrong shape.
That's a whole lotta problems that aren't code! Files and folders are littered with hurdles that have nothing to do with shipping code, just with organizing it to appease the beast.
Knowledge bases
An interesting thing about knowledge bases is that the less organization, the better! Folders and organization are choices, and those choices mean constant maintenance and having to categorize things. If you free yourself from that, and instead keep a single flat folder of files that organizes itself through the connections between them, you start to do a lot less work.
Another concept found in knowledge bases is "evergreen notes". These notes are bite-sized concepts that you link together to form a web of thoughts and knowledge. With this, you don't repeat yourself much, but you have very detailed context embedded in the thoughts.
Could we apply these principles to code?
A graph of values
When you add code to your codebase, each value (types, constants, functions, classes) is stored as a row in a database. If you follow their imports, you get a big graph of how all the code in your program connects.
You can think of it just like a knowledge base. Instead of a directory of files with relative links to each other, it's a graph of bite-sized values.
Apps, packages and scripts become subsections of the graph, picked out into whatever output format we want. Need a package? It materializes with the things you need, and none of the things you don't. Because we work in values, we don't have to worry that an array lives in a server package: we just need the value.
Suddenly, all the problems of files are gone! (There are, of course, many new problems caused by this.) We didn't need to anticipate the needs of the future with how we structured our code's files. Instead, our code can transform to meet the demands of the moment.
Working on a feature? Pull all the relevant values into one file, or as many as you want. The code can meet your needs right there, no planning needed.
Files are human
Files are ultimately a tool for humans. Managing code the way tcm does, in a codebase, is a very different way of working. It's a bit easier to remember where a file is. After working in a codebase for a while, you get to know the lay of the land: you remember where that function is stored, like a mark on a map.
But that topology comes with constraints, and with our code as a graph, we can work around many of them.