Previous article: Alone, Building Systems
From Contract Engineering to Solo Internal Systems
Before Cotomy existed, I left a contract engineering services company and moved to a non-IT company. In that role, I became responsible for executing and coordinating the company’s IT adoption and internal systemization, which meant I had to design, deliver, and keep improving multiple systems in a practical way. I had also been taking small personal development jobs before that transition, so I already had experience building simple systems under tight constraints.
Why PHP Was the Practical Choice
Around the same period, smartphones were just starting to spread widely, and that made web delivery a hard requirement because desktop-only applications could not cover the use case. I had already been developing with C#, and I wanted to keep using it for the next systems, but practical deployment constraints were stronger. I could set up on-premises servers at a rough test level, yet building and operating an internet-exposed environment with reliable security was beyond what I could trust my skills to handle at that time, so the risk was too high. At the same time, I had several systems that needed to run on cheap rental servers, and C# hosting on managed or low-cost rental environments was still rare or expensive. For those practical reasons, I consciously gave up C# and moved to PHP.
Why Smarty, and Why It Became Friction
My first PHP project was an EC site, and the OSS I adopted in that project happened to use Smarty. I started using Smarty mostly because of that starting point, not because I had a strong template strategy.
As I remember it, Smarty was often presented as a way to separate programmer and designer responsibilities. In real templates, though, loops and conditions inevitably appear, so that separation never became clean in practice. I also had to learn a separate syntax on top of PHP itself, and in that environment and at my skill level, the learning cost felt high.
I still used Smarty across about 3 to 4 systems over a few years. But when I began making my own PHP framework, I dropped Smarty and switched to standard PHP embedded HTML.
The First Self-Made PHP Framework
The first framework I made was intentionally simple. It had routing, a common base HTML layout through inheritance, and standardized database access so each screen did not reinvent basic data operations.
I remember two core base concepts, though the exact names are fuzzy now, something like Worker and HtmlPage. Subclasses plus routing definitions in mapping.json determined what would be called. It was lightweight and not something I would call public-quality, but it improved my day-to-day delivery speed dramatically.
Earlier, I had made a Swing control set in Java, but that was just a library. This PHP framework was the first one that directly improved real ongoing work.
Building the framework myself also deepened my understanding of web development far more than I expected. It fit my personality to be able to fix or reshape anything I disliked, because the framework was mine to adjust, not a black box I had to accept. I do not mean I had a complaint about other people’s design sense, but I did want to control as much as possible. Also, most of my systems shared very similar mechanics, so the required feature set was limited, and that made a large framework feel unnecessary.
The Project That Forced a SPA-Like Direction
This happened around the PHP7 era. I received a project that combined an organization-chart-like interface with internal chat behavior, and I wanted a smoother screen flow that felt closer to what we now call SPA, even though I did not know that term then.
As complexity grew, jQuery usage became heavy and harder to reason about. I started looking into AltJS options and found TypeScript.
TypeScript: The One-Reason Decision
I chose TypeScript almost immediately for one reason: type constraints. At the time, that was the clearest way to reduce breakage while scaling client-side code.
By then, I had already spent enough time in plain JavaScript to know how hard I could get trapped without type constraints. As the code grew, mismatched assumptions about object shapes and parameter usage kept slipping through until runtime, and debugging those failures took too much time.
I had enough time to build TypeScript runtime and tooling quickly, but my rendering assumptions stayed server-first. HTML rendering was still server-side, I was not yet thinking in terms of HTML and CSS as a paired unit, and I continued using jQuery heavily, so the benefits of TypeScript were only partially realized.
The “Clone and Append” Era
For complex UI elements, I first built DOM structures line by line with jQuery, and that approach soon hit limits. Then I shifted to a pattern where the server output template parts, and TypeScript located those parts, cloned them, and appended them where needed.
Looking back, the code was unbelievably irrational and ugly!!
Even so, this approach helped me ship several systems. Most of those systems are still running today, and I plan to replace or retire them within this year.
I also started feeling that generating simple HTML on the client side would be useful. At the same time, generating everything on the client did not feel realistic, so I was aiming for a hybrid: SPA-like interaction plus screen-per-feature practicality. I believe Cotomy aims to achieve that balance today, though I am still critically examining whether it truly succeeds.
Moving Away from jQuery
Eventually, jQuery started to feel pointless because I was already implementing SPA-like behavior around it. I had no real webpack understanding at the time, no AI assistance, and I struggled to pair screens and endpoints cleanly, so I decided to stop depending on jQuery.
One concrete pain point was box measurement. I needed viewport-relative box metrics such as those returned by getBoundingClientRect(), and accessing them required stepping outside jQuery’s abstraction layer. That repeated friction pushed me toward a wrapper boundary: if I wrapped HTMLElement directly, I could build a class around the exact behavior I needed.
Closing
This part covered what I did and why before Cotomy existed. I still feel I am discovering what I really wanted structurally. In the next article, I will move closer to the first true DOM wrapper, early boundary decisions, and how those eventually became Cotomy.
Development Backstory
This article is part of the Cotomy Development Backstory, which traces how Cotomy’s architecture emerged through real project constraints.
Series articles: Building Systems Alone , Early Architecture Attempts, The First DOM Wrapper and Scoped CSS , API Standardization and the Birth of Form Architecture , Page Representation and the Birth of a Controller Structure , The CotomyElement Constructor Is the Core , Dynamic HTML Boundaries in CotomyElement , Reaching Closures to Remove Event Handlers Later , and The Birth of the Page Controller .
Next article: The First DOM Wrapper and Scoped CSS
