If someone were to closely study my major public projects like Extwee, Twine Space, and Snowman over multiple years of their development, they would see distinct software patterns. When I was first working on Extwee in 2019, for example, my dominant pattern was to use JavaScript classes.¹ Every operation required a separate instantiation of its base class. Functionality was matched to classes, even if the operation was only a single verb such as “read.” Roughly a year later, the next major pattern was classes with static methods.² No instantiation would be needed, but the file scope would still be populated with multiple classes. A couple of years later, my latest pattern, seen in the work of Extwee 2.2.0 and in the current “lite” branch of Twine Space³, is in smaller parts. If there is a single operation, it is a single function in Extwee.⁴ No extra classes are needed.

Trees and Components

I have tried to embrace support for what is called “tree shaking.” JavaScript projects are often packaged using tools like WebPack and Rollup. These try to create the smallest packages possible by examining the total syntax tree of the result of combining all the parts together. If certain exports are not used, they can be “shaken” off the tree. This reduces the overall size and generally produces more optimized code.

In order to effectively “shake” a particular branch from the root tree, the functionality must be able to be separated from another. In programming, this is known as “de-coupling.” For most projects, complex sections can — and often should — be broken into smaller ones. This allows for easier testing and better human readability. Dozens of lines of code in one function is generally better than the same functionality found in a hundreds-of-line class or larger data structure.

Much of the change in my thinking is due to teaching the front-end framework React over the last few years. Within the framework, its base unit is a Component. In early versions of the React documentation, the pattern was to create JavaScript classes based on their Component class in an is-a object relationship. This has changed into functions acting as components. By creating single functions connected to different parts of a web application, testing and readability can be improved. A single file with a dozen lines can often accomplish the same general functionality as a complex class. While the greater complexity could do the same thing, the smaller structure is generally more efficient and human readable.

With Extwee now off my TODO list, I’m turning my eye toward finalizing Twine Space and then Snowman. This has meant thinking about my previous programming patterns and ways I might make things easier for myself in the future. As I was reminded upon reading Please Don’t Ask if an Open Source Project is Dead by Woolf (2023) last month, I’ve been thinking about my responsibility to the future.⁵ While I should keep an eye toward producing good software, there isn’t an index-zero for GitHub. I’m not paid for my open source development currently, and I haven’t been in the past. It is perfectly fine if I don’t update something non-breaking for months to up to a year.

1. An example of this pattern can be seen in the FileReader.js file for Extwee 1.0.0. It uses a constructor() method but only has a single, sister method in the same class. ↩︎
2. Comparing the 1.0.0 pattern to the released 2.0.3 in 2020 shows this change into static method. In the FileReader.js file, there is only a single static method (and static class as a result). ↩︎
3. The Twine Space de-coupling shift has files like the Parsing/ParseMarkdown.js file with its ParseMarkdown() function. ↩︎
4. The shift the component model has meant short files. An example of this the newer Twine2HTML/compile.js file with its single compile() function export. ↩︎
5. Woolf, M. (November 2023). Please Don’t Ask if an Open Source Project is Dead. Max Woolf’s Blog. Retrieved from: https://minimaxir.com/2023/11/open-source-dead-github/ ↩︎