There was no single bad afternoon behind Dvl'epr. A long-held belief that building applications could be made easier, the lack of any genuinely good server-side framework at the time, and years of COBOL/CICS experience — all three pointed the same way at once.
The framework that wasn't there
The means arrived, unglamorously, while building one specific application — a large workplace information management system — in 2005, when PHP was the obvious language of choice. Web applications were still in their infancy, and what I ran into wasn't really a PHP problem. It was two problems underneath it that PHP simply had no answer for.
The first was that web applications are, by nature, pseudo-conversational: a screen goes out, the user does something, a request comes back, and the application has to pick up where it left off — over and over, screen after screen, with nothing holding the thread between requests except whatever you build yourself.
The second was that PHP gave me nothing to manage that. No built-in concept of state across a conversation, no structure for it at all. Every application had to invent its own way of remembering where the user was and what they'd already done.
Neither of those problems was new to me — I just hadn't met them on the web before.
Twenty years on a mainframe
My background was IBM mainframe, writing COBOL under CICS. CICS applications are pseudo-conversational in exactly the same sense: a transaction sends a screen, ends, and a later transaction picks the conversation back up. That part of the shape was completely familiar. What was different — and what I felt the absence of immediately — was everything CICS did around that shape.
CICS (mainframe)
- Managed conversational state for you
- Handled transaction routing and recovery
- Screen definitions were separate from logic
- The platform carried the repetitive weight
PHP, circa 2005
- No concept of conversational state
- No frameworks yet — they were years away, and plenty didn't last
- Screen logic and processing logic tangled together by default
- The developer carried all of it, every time
There was nothing comparable to CICS for web applications at the time. Whatever CICS had done for me automatically, I now had to do by hand, screen by screen, application by application.
Building the application became building the platform
So while I was still in the middle of that first large application, I started building a way out of the repetition: a platform driven by declarative XML, where I only had to describe two things — what a screen contained, and the SQL behind it. The platform would take that description and generate the actual HTML, which is all a web application script produces in the end anyway. If the output was always going to be HTML, there was no reason I should be the one hand-writing it every time.
Because I was building a real, full application alongside the platform rather than a toy example, the first iteration of the engine came together fast — reaching roughly 80% complete quite early on. It also needed an escape hatch from day one: not everything a real application does fits neatly into "screen description plus SQL," so the platform supported plugins — plain PHP scripts for any processing the declarative model didn't cover.
How the rest got built
The remaining 20% didn't arrive all at once — it got filled in as the web itself kept moving. AJAX in particular came later, as it became a normal part of how web applications behaved, and had to be folded into the platform after the fact rather than designed in from the start.
The frustration
Building a large workplace information system in PHP, hitting the pseudo-conversational/state problem head-on, with no framework and no mainframe-style platform underneath.
~80% there, fast
A declarative XML engine — screen description plus SQL in, HTML out — reaches most of its shape while still embedded in building the real application, with plugins covering whatever the model doesn't.
The last 20%
AJAX and other web-native capabilities get absorbed into the platform as they become standard, closing the gap between what the engine generates and what modern web applications need.
Why I'm still using it, 20 years later
The landscape didn't stand still after 2005. PHP frameworks arrived, and plenty of them quietly disappeared. JavaScript frameworks multiplied, and a handful — React, Vue, Angular among them — became what most developers reach for without a second thought. I've used them. More than once, on real projects, not out of curiosity. None of them gave me back the speed or the simplicity Dvl'epr already had, so I stayed.
Part of that is architectural, not just habit. Dvl'epr never locked me into a front-end stack in the first place — the platform generates the plumbing, but what sits on top of it has always been my choice. Tailwind, Bootstrap, a charting library, anything a project actually needs — none of it fights the architecture, because none of it was ever mandated by it.
More recently, AI-assisted coding has made the gap wider, not narrower. Ask an AI assistant to vibe-code a full-stack feature in a conventional framework, and it has to get several moving parts right at once — component structure, state management, an API contract, and the wiring between all three — which is exactly where AI-generated code tends to introduce the most convincing-looking bugs. Ask it for the HTML structure and the SQL a screen needs, and there's almost nothing left to get subtly wrong. Vibe coding on Dvl'epr is faster not because AI got better at writing more code — it's faster because there's so much less code left for it to write.
What that frustration became
That early engine is the direct ancestor of Dvl'epr as it exists today: a platform where you describe a screen and its data in XML, and the engine generates the HTML and JavaScript that would otherwise have to be hand-written, and rewritten, on every single screen. The core insight hasn't changed since 2005 — most of what a web application's code does is repetitive, and repetitive code is exactly what a platform should be generating for you, not what a developer should be typing out again.
No front-end code. Just HTML structure and SQL
Post 2 covers how that idea actually works today — the core loop, the five-layer file structure every app is built from, and exactly what you stop having to write once the engine takes over.