Support for DataStar tags
There is a new star in the web development firmament: DataStar https://data-star.dev.
It is currently in release candidate, but is making waves in the server world and would be a perfect fit with HtmlFlow.
It was recently presented on the main stage at KotlinConf 2025:
They have a very active community on Discord https://discord.gg/bnRNgZjgPh.
Essentially, DataStar (short D*) used HTML5 data-* attributes to provide powerful capabilities (similar/more powerful than HTMX https://htmx.org) via a range of very small plugins.
It would be very useful to be able to easily express, in a typesafe way, a data-* attribute.
Regardless, please take a look at DataStar - it is something special.
Thanks for the suggestion! Adding support for data-* attributes should be straightforward, as we can extend the XSD definitions accordingly. For context, the entire HtmlFlow API (both in Java and idiomatic Kotlin) is auto-generated from the HTML 5.2 XSD using our xsd2poet engine. You can find the current XSD here:
👉 https://github.com/xmlet/xsd2poet/blob/main/src/main/resources/html_5_2.xsd
Beyond that, I'm also exploring the possibility of promoting a Master's-level project aimed to provide a unified development framework that brings together frontend and backend logic in a single Kotlin-based project. The goal would be to integrate HtmlFlow and DataStar to provide type-safe routing and frontend behavior.
I'm not sure what related work exists in this area or have you or others already explored something similar?
BTW is there any video of your presentation in Kotlin Conf?
Hi, Miguel,
The presentation was done by our friends at http4k, and I think Jetbrains will be publishing them in the next couple of weeks.
It would be great to get in touch on Zoom or Teams - I think there is tremendous synergy between Datastar, http4k and HtmlFlow and it would be great to see the three working together: people and technology.
My company (SDX) is just a user of these technologies, but I can see something "game changing" coming out of a collaboration between the three.
For your Master's level project, I can see how you could bring all three together into something very special!
Hey, Datastar author here. Happy to get on a vidchat anytime if it helps. Datastar is 💯 HTML spec compliant so if you support the normal HTML, you support Datastar. Though we do push the spec in ways that some would consider... unnatural.
As the duly sober representative of http4k, we're also happy to be involved - the video should be up in a few weeks. Happy to jump on a call in the meantime if that works or to wait and see if it's all a good fit once the Full Stream Ahead video is out. 🙃
Thank you for the enthusiastic replies — it’s exciting to see such alignment. At the moment, I’m a bit overwhelmed with other responsibilities. I’d like to take a little time to experiment with data-* attributes and explore how an integration between HtmlFlow and backend logic might work before jumping into a call. In the meantime, would it be possible for someone from the DataStar side to share an XSD or schema — or any resource — that indicates which HTML elements your data-* attributes are typically applied to?
Hi, Miguel,
Just a couple of updates:
- the presentation Ivan gave on the main stage at KotlinConf is now available on Youtube https://www.youtube.com/watch?v=vewgb-vyJME
- Datastar is rapidly approaching public Release Candidate and the website is being completely revamped by the Datastar team
Both http4k and Datastar teams are doing some wonderful work, which we're looking forward to using in anger this summer.
PS: Ivan used Handlebars in his presentation, but it would be great to get HtmlFlow on the list of templating engines supported in http4k's project wizard/the http4k ecosystem:
After reviewing the Datastar documentation, I believe we can integrate Datastar into HtmlFlow at two distinct levels of complexity and usability:
-
Basic integration to provide
data-*attributes through Kotlin extension properties: Extend the HtmlFlow idiomatic Kotlin API to support Datastar by exposingdata-*attributes asString-typed properties. Given HtmlFlow’s strongly typed and HTML-safe model, this requires identifying which HTML elements support whichdata-*attributes. As an alternative, we could define these attributes as Kotlin extension properties on the commonElementbase type, making them available uniformly across all HTML elements. -
Advanced integration with strongly typed Datastar constructs: Building upon the basic support in 1, we could introduce compile-time integration with Datastar’s core abstractions—such as signals—by modeling them as strongly typed Kotlin constructs. These could be referenced directly via HtmlFlow's DSL (e.g., through specialized extension properties), ensuring type safety and better developer ergonomics when working with reactive or declarative bindings.
We can schedule a Zoom meeting to discuss these topics in more detail. Feel free to connect with me on LinkedIn so we can share contact information and arrange the meeting.
Hi @andy-barlow,
Regarding the inclusion of HtmlFlow in the list of templating engines supported by http4k’s project wizard, it doesn’t appear to be a fundamental requirement for HtmlFlow to put it working with http4k.
If I understand correctly, templating engines based on external DSLs—like Handlebars, Thymeleaf, and others—typically require a ViewModel to bridge the handler logic with the resource-based template. In contrast, internal DSLs such as HtmlFlow or j2html define templates as functions in code, which can be invoked directly within the handler without the need for an intermediate model.
That said, we’re open to exploring an integration through the ViewModel if you believe it's important for consistency or interoperability within the ecosystem.
I am not finding the repository with demo code of the presentation of @s4nchez in KotlinConf. Is it available?
As you say @fmcarvalho - I'm not sure if the existing Templates in http4k will be appropriate for DSL-style systems, but I think we would want to reuse the TemplateRenderer and ViewModel abstractions to maintain consistency:
typealias TemplateRenderer = (ViewModel) -> String
The repo for the KotlinConf talk can be found here: https://github.com/http4k/full-stream-ahead - although it's not using the latest Datastar changes which have been made to signals/fragments for pre-v1. We'll be implementing those when available in D* is released.
Hi @fmcarvalho, just a quick message to let you know that Datastar has been released https://data-star.dev, see https://data-star.dev/essays/v1_and_beyond.
If you do split HtmlFlow into three libraries #126 I think support for Datastar "standard" and pro attributes would fit nicely with the Kotlin library.
Hi @daviddenton!
We have recently started working on HtmlFlow's integration with http4k. We’ve put together a draft implementation here, and I’d like to highlight an aspect that makes this integration different from others currently supported by http4k:
Since we use reflection to scan for views, we don’t support directory scanning via Caching or HotReload. Instead, we provide:
CachingClasspath()HotReloadingClasspath()
We would like to get your thoughts on this.
Also related to unit testing and compliance with the currently defined TemplatesContract and ViewModelContract:
- Since HtmlFlow doesn’t allow directory scanning, the tests that scan
src/test/resourceswill fail.
We can create adapted versions of these two contracts for HtmlFlow. Would that be acceptable for inclusion in the PR to http4k?
PS: Example usage of the integration below:
data class Person(val name: String, val age: Int) : ViewModel
val personView: HtmlView<Person> =
HtmlFlow.view {
it.html {
body {
div {
attrClass("person-view")
h2 { text("Person Details") }
dyn { model: Person -> p { text("${model.name} is ${model.age} years old") } }
}
}
}
}
fun main() {
// first, create a Renderer - this can be a Caching instance or a HotReload for development
val renderer = HtmlFlowTemplates().CachingClasspath()
// first example uses a renderer to create a string
val app: HttpHandler = {
val viewModel = Person("Bob", 45)
val renderedView = renderer(viewModel)
Response(OK).body(renderedView)
}
println(app(Request(Method.GET, "/someUrl")))
// the lens example uses the Body.viewModel to also set the content type, and avoid using Strings
val viewLens = Body.viewModel(renderer, TEXT_HTML).toLens()
val appUsingLens: HttpHandler = { Response(OK).with(viewLens of Person("Bob", 45)) }
println(appUsingLens(Request(Method.GET, "/someUrl")))
}
Awesome y'all, if you need anything from me just holler
Hi @andy-barlow , just a quick message to let you know that we made a PR to integrate HtmlFlow on http4k.
That's great news - and good timing, we have just started a major project to upgrade to http4k in all our software!
Thanks you @fmcarvalho .
Hi @andy-barlow, starting with version 5.0.1, HtmlFlow is split into four modules: htmlflow, htmlflow-kotlin, flowifier, and htmlflow-view-loader. This new architecture has resolved several issues.
The HTTP4 integration is also in progress, and we’re currently addressing their requirements.
Next, we’re planning a new module to support Datastar.
Sounds good; we're looking forward to pulling everything together over the coming weeks!
@delaneyj We’ve implemented a first prototype of an idiomatic Kotlin DSL that currently supports just a few Datastar attributes. There are some implementation decisions that influence how this DSL is used in Kotlin, and I’d like to share our ideas and hear your thoughts on them. How can we arrange a video chat? I’m in the GMT time zone. Everyone here is very welcome to join as well.
@delaneyj We’ve implemented a first prototype of an idiomatic Kotlin DSL that currently supports just a few Datastar attributes. There are some implementation decisions that influence how this DSL is used in Kotlin, and I’d like to share our ideas and hear your thoughts on them. How can we arrange a video chat? I’m in the GMT time zone. Everyone here is very welcome to join as well.
i'm PST timezone but around 5am to 10pm most days. Find a time that works for y'all. Since this might be a bit of back and forth... please join the Discord or reach out in a DM. Very interested in helping y'all and doing what I can!
Just FYI, the http4k integrations for both D* (v1) and HtmlFlow are available in the latest version (v6.19.0.0), 🙃
@daviddenton What is needed to generate a usage example of an HtmlFlow view in the http4k Project Wizard when HtmlFlow is selected as the templating library?