WebExpress

An update to the earlier post about the View, State, and Service architecture. When the View, State, and Service architecture was introduced, it replaced scattered state, direct DOM manipulation, and implicit service calls with a clear unidirectional data flow. Each control gained an explicit state object, a typed service descriptor, and a predictable path from initialization through user interaction to re‑rendering. The model worked well and was written entirely in C#. The previous post showed how a list evolved from a handful of scattered properties into a single, well‑structured definition. As the architecture rolled out across control families, a deeper boundary became visible. The state was clean but still belonged per control. Each control seeded its own state island, resolved its own service, and loaded itself on mount. Two controls on the same screen showing the same data fetched it independently. There was no natural way for one control to trigger a re‑render in another when ...

It is no longer a secret that most of the code entering WebExpress today is no longer typed by hand. I propose it, generate it, and ideally also review it with the help of an AI. This has fundamentally changed how I develop the framework and forces me to ask whether I could maintain the pace the project now demands without this support. I am not trying to create hype or issue warnings. I want to describe honestly what AI gives me and what it costs me. When I look back two or three years, much of WebExpress was built in fragments. I implemented the critical paths carefully, yet many areas remained unfinished. Tests existed but were often postponed. Comments were present but rarely convincing. With AI assistance, this changed abruptly. Even non‑critical modules now receive the attention they previously lacked. Edge cases, validation, and clean error handling are no longer deferred. Test coverage has increased significantly, and instead of a single happy‑path scenario, I now cover difficu...