WebExpress

Long before I started developing WebExpress, I was a passionate Windows Forms developer. During my university years, I also built websites using PHP, which gave me insight into the strengths and weaknesses of both worlds. That experience sparked a desire to combine desktop and web development, but in my own way. From a simple idea and an early prototype, the WebExpress project gradually took shape. It’s a lightweight web server written in C# that generates HTML directly from class information. You can think of the core concept as “LINQ to HTML,” designed to make web development dynamic and data-driven. First Steps and Milestones December 29, 2017 – PlanExpress begins: Drawing from my Windows Forms experience, I created a planning tool that already carried the seeds of WebExpress. March 11, 2018 – Renamed to WebExpress: The project finally received a new name and a clearer direction. March 18, 2018 – Open source on GitHub: A defining moment: I opened the project to the communit...

In many REST frameworks, the same question eventually arises: Where should I annotate my HTTP methods? Directly on the class or on the specific method that handles the request? Both approaches work, both are valid, and both lead to completely different architectural characteristics. That’s exactly why it’s worth making this decision consciously instead of leaving it to chance or framework conventions. In this article, I compare two models that have become established in REST systems: the linear, class-based model and the non-linear, method-based model. I also show how modern Java frameworks like Spring Boot solve this question and why. In the end, I want to find a solution that feels right for WebExpress , performs well, and can be adapted dynamically. In the linear approach, the HTTP method is defined directly on the class. The class represents exactly one endpoint and exactly one HTTP verb. The implementation contains a single method that processes the request, often with a fixed nam...

When I look back today at my first steps in web development, I see one thing above all: tables. Back then, tables were my universal tool for structuring websites. No matter whether it was about arranging text, images, or navigation elements, I put everything into tables. Every row and every column was a building block of my layout. It was a time when people believed that tables gave them control over the design. But with experience and the progress of web technologies, I realized that tables are not only impractical for layout purposes but also limiting. Today, I try to avoid tables wherever possible and instead rely on container-based layouts. Even in cases where tables are needed in the traditional sense, such as for displaying tabular data, I use modern grid techniques that go far beyond old HTML tables. In this blog post, I want to describe my journey, explain the advantages of container-based layouts, and critically examine why tables are no longer a good choice for designing webs...

With version 0.0.10-alpha of WebExpress , a new development phase begins for TableCtrl. The previous solution was certainly rich in features, but its structure was monolithic, complex, and error-prone. It combined both data presentation and editing into a single component and offered a wide range of features: declarative configuration via HTML, client-side row sorting, column reordering with persistent configuration storage, manual row movement, hierarchical nesting, cell templates, inline editors, per-row options menus, row icons, and row URLs. Derived classes even added dynamic data loading, search, paging, and row editing and deletion. However, this abundance of functionality led to blurred responsibilities and reduced maintainability, even though existing controls were used to display cells. The reason this realignment wasn’t undertaken earlier lies primarily in the pragmatic and pressure-driven nature of the original development. The goal was to quickly deliver a broad spectrum of...