This work extends the HtmlFlow Kotlin DSL with statically typed support for reactive Datastar attributes and signal-based bindings, aiming to reduce frontend/backend heterogeneity while nearly eliminating the need for JavaScript.

The paper was submitted to Software: Practice and Experience (Wiley) and is available on arXiv at arXiv:2607.29338.

Abstract​

AI-assisted coding tools (e.g., Copilot, Cursor, Claude) are increasingly ubiquitous and enable rapid generation of web applications. However, this raises concerns regarding complexity, longevity and the long-term maintainability of generated systems. A key source of complexity is the heterogeneity between backend and frontend programming models, where multiple languages and paradigms are combined within a single application, often leading to duplicated logic and fragmented state management. To address this issue, recent approaches (e.g., HTMX, Turbo Hotwire, Datastar, etc.) follow the Hypermedia-Driven Application (HDA) model, positioning HTML as the primary communication medium between client and server. Unlike SPA-centric architectures, HDA systems shift the application state and interaction logic to the server, where backend-driven reactive signals synchronize with the client user interface. However, these approaches still introduce complexity through custom attributes and do not fully eliminate JavaScript, particularly in computed expressions. In this work, we propose a statically typed approach using a Kotlin-based HTML DSL (Domain-Specific Language) for backend-driven reactive web applications. We extend the HtmlFlow Kotlin DSL with typed custom HTML attributes (i.e., Datastar data-* attributes) and signal-based bindings using statically typed builders. We demonstrate the approach through a catalog of reactive interaction patterns and a Petclinic Spring MVC case study. The results indicate that the proposed approach can nearly eliminate the need for JavaScript while improving type safety and preserving a homogeneous programming model across frontend and backend, bridged through a backend-driven reactive, signal-centric architecture.

This feature enables the creation of HTML fragments that can be embedded in other HTML documents, such as tables, without requiring a complete HTML structure.

🚀 DataStar Kotlin DSL​

A major milestone was reached with the introduction and evolution of an idiomatic Kotlin DSL for DataStar integration:

• Introduced DataStar extension functions and the new Signal type.
• Added support for dataBind, dataInit, dataIndicator, dataAttr, and other DataStar attributes.
• Expanded support with additional data-* attributes.
• Added modifier support for DataStar attributes.
• Refactored builders and organized DataStar tests into their own package.

These improvements make it easier to build reactive HTML declaratively while keeping the API clean and type-safe.

🏗️ HTML Builder Improvements​

The HTML DSL continues to become more flexible:

• Added Span as a valid HtmlPage root element.
• Added Tbody as a valid HtmlPage root element.
• Introduced new root builder extensions for div, tr, span, and tbody.
• Expanded test coverage for all new builder capabilities.

🧹 Refactoring and Quality​

Several improvements were made to enhance maintainability and reliability:

• Refactored HTML extension functions.
• Applied Spotless formatting across the project.
• Added missing unit tests.
• Simplified imports and cleaned up obsolete tests.
• Improved internal builder implementations.

⚙️ Build & CI Improvements​

The development workflow has also been modernized:

• Upgraded the project to Kotlin 2.3.10.
• Replaced JaCoCo with Kover for code coverage.
• Added a GitHub Actions workflow to enforce Spotless formatting checks.
• Merged multiple feature and CI pull requests.
• Prepared the htmlflow-parent 5.0.3 release.

📦 Overall​

This development cycle focuses on three key goals:

• Expanding the HTML DSL with more expressive root builders.
• Delivering first-class support for DataStar through an idiomatic Kotlin API.
• Improving project quality with stronger testing, automated formatting, updated tooling, and modernized CI.

Together, these changes make HTMLFlow more expressive, easier to maintain, and better prepared for future releases.

HtmlFlow is now free of any Kotlin dependency, and only htmlflow-kotlin requires the Kotlin standard library.

In the new xsd2poet-java, the ElementVisitor no longer includes visitSuspending. The visitSuspending method is now exclusively part of the Kotlin version.

This release also resolves Issue 136.

As a result, the core Java HtmlFlow module no longer depends on the Kotlin coroutines library or jsoup (which is now only required by the reverse-engineering tool Flowifier, moved to its own module).

HtmlFlow is now organized into four distinct modules:

• htmlflow-core: The main library (the htmlflow artifact) containing the Java API.
• flowifier: A reverse-engineering tool for translating HTML documents into equivalent HtmlFlow view definitions.
• htmlflow-kotlin: The idiomatic Kotlin API (which depends on htmlflow-core).
• htmlflow-view-loader: A reflective inspector for HtmlFlow view definitions. It loads Kotlin functions of type T -> String that return rendered HTML.

Additionally, an mfe() builder has been added to dynamically load HTML fragments, supporting both SSR and CSR approaches within HtmlFlow view definitions.

This paper studies how Java virtual threads can simplify the implementation of progressive server-side rendering by enabling blocking template engines to operate effectively in non-blocking environments.

The article was published in Software 2025, 4(3), 20 on 13 August 2025.

Abstract​

Modern web applications increasingly demand rendering techniques that optimize performance, responsiveness, and scalability. Progressive Server-Side Rendering (PSSR) bridges the gap between Server-Side Rendering and Client-Side Rendering by progressively streaming HTML content, improving perceived load times. Still, traditional HTML template engines often rely on blocking interfaces that hinder their use in asynchronous, non-blocking contexts required for PSSR. This paper analyzes how Java virtual threads, introduced in Java 21, enable non-blocking execution of blocking I/O operations, allowing the reuse of traditional template engines for PSSR without complex asynchronous programming models. We benchmark multiple engines across Spring WebFlux, Spring MVC, and Quarkus using reactive, suspendable, and virtual thread-based approaches. Results show that virtual threads allow blocking engines to scale comparably to those designed for non-blocking I/O, achieving high throughput and responsiveness under load. This demonstrates that virtual threads provide a compelling path to simplify the implementation of PSSR with familiar HTML templates, significantly lowering the barrier to entry while maintaining performance.

It also introduces ViewFactory.Builder, allowing configuration of HtmlView parameters, such as isIndented, threadSafe and preEncoding.

Finally, it adds a new type of Hot view that recalculates all HTML—including static HTML blocks— on each rendering, which is useful for http4k integration with hot-reload support.

1. Unified API Generators: Combines two previously separate API generators—one for Java and another for idiomatic Kotlin builders using function literals with receivers—into a single unified infrastructure.

2. Simplified Manual Integration: Streamlines the process of merging manually written builders (e.g., of(), dynamic(), async(), suspending(), etc.) with automatically generated HTML builders.

Initially, when we introduced an alternative Kotlin API alongside the existing Java API, the automatic Kotlin generation mechanism was not integrated into the existing HtmlApiFaster infrastructure. Instead, as an experimental approach, we integrated it directly within the HtmlFlow module using KotlinPoet to generate Kotlin source code. This was a departure from the previous approach, which relied on ASM (a Java bytecode manipulation library) to generate the element classes that make up the HtmlFlow Java API.

Additionally, extending the autogenerated Element base interface to include new dynamic features was cumbersome. The legacy process required manually merging custom additions after running the automatic generation.

With the introduction of the new xsd2poet dependency, which replaces the legacy XsdAsmFaster and HtmlApiFaster, we now generate source code instead of bytecode. Furthermore, we have refactored the backbone of the org.xmlet.htmlapifaster API to be maintained as source code rather than dynamically generated classes.

This new approach significantly simplifies the maintenance and enhancement of HtmlFlow’s custom features.

This work presents a proposal for server-side rendering web templates that support the async/await pattern while preserving well-formed HTML output and enabling progressive server-side rendering.

The paper appears in Web Information Systems Engineering - WISE 2024: 25th International Conference, Doha, Qatar, December 2-5, 2024, Proceedings, Part V, pages 458-473.

Abstract​

Progressive server-side rendering (PSSR) enhances the user experience by optimizing the first contentful paint and supporting incremental rendering as data becomes available. However, constructing web templates for asynchronous data models introduces complexity due to undesired interleaving between data access completion and template processing, potentially resulting in malformed HTML. Existing asynchronous programming idioms, such as async/await or suspending functions, enable developers to create code with a synchronous appearance while maintaining non-blocking progress. In this work, we introduce the first proposal for server-side rendering (SSR) web templates that seamlessly support the async/await pattern. Our proposal addresses the challenges associated with building SSR web templates for asynchronous data models, ensuring the production of well-formed HTML documents and preserving the capability of PSSR.

You can write HTML structures in a natural, hierarchical way using nested lambdas, or use method chaining for concise simple sequences:

body {
    div {
        p { 
            text("Hello") 
        }
    }
}

body.div.p.text("Hello").l.l.l

Both approaches are available depending on your preference - nested lambdas for readability with complex structures, or method chaining for concise simple sequences.

• Added Kotlin extensions, such as the .l property, which can be used to close tags in Kotlin instead of .__().
• Introduced a new .suspending() builder to support the use of continuations in Kotlin, allowing suspending functions to use await.
• Resolved Issue 105 by integrating new attributes in globalEventAttributes, included with the release of HtmlApiFaster 1.0.15.
• Added new unit tests verifying multi-threaded scenarios.
• Updated the documentation to detail setIndentation() usage and the correct application of threadSafe().

• Resolved Issue 103. Using .text() interleaved with attributes is no longer supported and will now throw an exception.
• Resolved Issue 104. Disabling indentation incorrectly removed newlines inside text and script blocks. This has been corrected.
• Enhanced the documentation with additional examples of data binding, conditionals (if/else), and loops.
• HtmlView is now strongly typed with the type M corresponding to the model.

• HTML boolean attributes are no longer emitted when assigned a false value.
• Added new types for the Script tag, including module and importmap.
• HtmlViewAsync now supports thread-unsafe views, allowing sequential execution even if asynchronous relative to the data model.

• DynamicHtml and StaticHtml are replaced by HtmlView and HtmlDoc, respectively. Both inherit from the new HtmlPage type.
• The factory methods DynamicHtml.view() and StaticHtml.view() have been moved to the HtmlFlow class, becoming HtmlFlow.view() and HtmlFlow.doc().
• The HtmlWriter interface, which previously defined standard methods (write and render) for all HTML pages, has been removed. With the dynamic nature of HtmlView (formerly DynamicHtml), render(model) and write(model) now require a model argument. These methods are not applicable to HtmlDoc (formerly StaticHtml), leading to the removal of HtmlWriter. The base class HtmlPage no longer defines write or render methods.
• HtmlPage, HtmlView, and HtmlDoc are no longer parameterized with the model type. The model is now parameterized only when using the builder <M> dynamic(BiConsumer<E, M> consumer), where E is the parent HTML element and M is the model type.
• The model object is now passed directly as a parameter to the consumer of a dynamic block (e.g., calling .dynamic((elem, model) -> ...)), eliminating the need for closures to capture the model object.

For example, the dynamic blocks approach has been simplified:

public void template(DynamicHtml<Pet> view, Pet pet) {
    view.div().h2().dynamic(h2 -> pet.getName()).....
    ...

public void template(HtmlPage view) {
    view.div().h2().<Pet>dynamic((h2, pet) -> pet.getName()).....
    ...

• Partials are now the only place where closures can capture a model object of a different type than the enclosing template. When doing so, you must use a dynamic() block to prevent the partial from being stored as static HTML and ensure it renders whenever called with a model. If the partial uses the same model as its container, avoid the closure and instead use the model provided to the dynamic(cons) builder.
• The addPartial() builder has been removed. A partial is now simply a consumer function of an HTML element (Consumer<E extends Element>). You can combine partials using higher-order function composition. The element serves as the parent HTML where HtmlFlow continues to emit code. Additional arguments corresponding to context models can also be passed to partial views.

You can find this sample in the unit tests at htmlflow.test.views.HtmlCustomElements.

Invoking .custom("alert-info") returns an instance of the new CustomElement class, which inherits from the existing Div class. As a result, the returned instance has most HTML features available.

Example usage:

StaticHtml
  .view()
      .html()
          .head()
              .script()
                  .attrSrc("alert.js")
                  .attrDefer(true)
              .__()
          .__()
          .body()
              .div()
                  .attrClass("container")
                  .p().text("Testing custom elements!").__()
                  .custom("alert-info")
                      .addAttr("title", "Information")
                      .addAttr("message", "This is a message for a custom element")
                      .addAttr("kind", "success")
                      .ul()
                          .li().text("For any reason we could even include other elements.").__()
                      .__()
                  .__()
              .__()
          .__()
      .__();

This feature introduces a couple of new internal methods, including newby() in HtmlVisitor, which creates a new instance of the same type while preserving indentation.

Resolves Pull Request 75.

Updated the JUnit release to address a reported vulnerability. For details, see Pull Request 68.

The project defines templates as first-class functions, leveraging Java language features while removing auxiliary Spring infrastructure components like ModelAndView and ViewResolver. Consequently, validations regarding these mechanics have been removed from the unit tests.

This change improves compatibility with applications such as spring-comparing-template-engines that do not support higher Java versions.