Introduction & Philosophy

Pragma CMS was built because we believe developers should understand the code they deploy, and content creators should be able to focus on content, not tooling. Modern CMS platforms have become black boxes, heavy layers of abstractions that hide the actual work being done by the CPU. Pragma chooses the Lean Monolith: a codebase designed to be read and understood without digging through layers of indirection, without the "magic" of complex frameworks or the latency of fragmented microservices.

Architectural Rationale: Low Complexity, High Performance

Modern web systems suffer from both performance and complexity. As complexity increases, systems become harder to understand, debug, and control, and performance inevitably degrades.

Pragma CMS is built to solve this:

• No "Abstraction Tax": We avoid unnecessary layers and dependencies. Why introduce megabytes of dependencies just to render a page? Pragma uses Vanilla JavaScript and Native PHP. No bundlers, no compilers, no unnecessary "middlemen" between your code and the browser.
• Explicit Error Handling: We avoid the hidden complexity of Exceptions. By preferring explicit return values over try/catch blocks, we ensure that the error path is as visible and predictable as the success path, preventing 'hidden jumps' in logic.
• Minimal OOP: We use OOP where it makes sense (as simple data containers), but we avoid complex inheritance and "object soup." Logic remains procedural and visible, making the system easier to debug and faster to run.
• Data-Oriented Design (DOD): Most CMSs wrap data in thick layers of Object-Oriented behavior, leading to "Object Soup." Pragma treats data as the primary citizen. Our code is organized around the shape of the data, not abstract mental models. We prefer flat arrays and simple structs over deep class hierarchies. This ensures cache-friendly execution and makes data transformation (from Database to HTML) predictable and blazing fast.
• MVC-lite Organization: We avoid heavy MVC architectures which rely on deeply nested controllers or redundant service layers, making the system harder to follow. Instead, we use a minimal MVC structure for separating themes, templates, and application logic. The goal is not to remove structure, but to keep it as flat and direct as possible, with a clear execution path from HTTP request to output.