What are the pros and cons of kotlinx HTML vs Thym...

# kotlinx-html

[Mario Andhika]

What are the pros and cons of kotlinx HTML vs Thymeleaf?

[Mario Andhika]

I’m thinking that while kotlinx html is more concise, but thymeleaf is closer to actual html, so while it’s nicer to type in kotlinx html, thymeleaf might be easier to visually debug

[Cies]

kxhtml is "just Kotlin". You can put break points, you need to compile it (thus makes your builds slower), but you can work with it in Kotlin so not mental overhead of another language. Loops are just Kotlin-loops, function calls are just Kotlin... kxhtml is an eDSL. https://en.wikipedia.org/wiki/Domain-specific_language#eDSL

Thymeleaf is "mostly HTML": there is some additional "language" and attributes you need to learn. It does not need to be compiled so a lot of templates will not slow down compilation. This results in some errors being only visible at runtime, i.e. less typesafety.

kxhtml is not the fastest for rendering, but for us that was a non issue (if you have really high traffic, it may be an issue for you). Here a benchmark: https://dzone.com/articles/modern-type-safe-template-engines-part-2

[Mikael Ståldal]

It's actually quite disappointing that kotinx.html is significantly slower at runtime than Thymeleaf, I would have expected it to be faster (or at least as fast).

[Mario Palka]

how much is "significantly"?

[Cies]

Oh, I did expect it. With Thymeleaf you essential have a big string with some interpolated values/ loops/ conditionals in it. But for the most part the HTML is already in string form. In case of kxhtml the string is built on each render.

[Cies]

@Mario Palka We had looked into it, and found that at our level of traffic on our total response times for HTML pages the <0.5msec render time for kxhtml was a small price to pay for the increased productivity of: 1) doing all with one tool, 2) having full Kotlin type safety in templates, 3) having great editor support (e.g. code completion on element and attributes names).

[Cies]

We found most problems with the increased compile time once we had many templates ported.

[Mikael Ståldal]

Something is wrong if you get increased compile time and increased run time. You are supposed to pay the compile time to get faster runtime.

[Cies]

It's not only two parameters IMHO it is three (that are important to me). compile time, runtime, developer (or "human") time. sure we could add more (memory usage, disk usage, etc.) but lets focus on these three.

For us, developer/human time is the most expensive. Having code that leverages type safety to make sure whole categories of bugs cannot be expressed as runtime bugs, but will always show as compile time bugs saves us: developer time, support time and brand damage.

The overhead of runtime (say from 0.01ms to 0.1ms) is no big deal for us (at our level of traffic and performance). Compare this to the variance in latency, or the total request time and see that it may not make a difference for you.

The increase in compile time is more painful for us (as it somewhat translate to developer time "wasted" waiting on the compiler). We're are 10mins cold start compile time, 3-5min when switching from branches, and 10sec-1min for recompiles. Let's say that 30% of this is due to our large amount of kxhtml templates. We as a team are still MUCH happier to take this occasional wait over having to deal with "HTML as a string" with all the implications that has.

In case anyone is interested, if we did not go for kxhtml we'd have gone with KTE https://jte.gg/kotlin

[Mikael Ståldal]

3) having great editor support (e.g. code completion on element and attributes names).

In IntelliJ IDEA Ultimate, you can have great editor support for Thymeleaf (there is a plugin) also.

[Mikael Ståldal]

Which advantages would JTE have over Thymeleaf (assuming kotlinx.html is not an option)?

[Cies]

@Mikael Ståldal As I understand it, Thymeleaf leaves the door open for runtime errors that KTE would catch at compile time. We came from GroovyTemplates, which is not too far off from Thymeleaf in term of how it works (Thymeleaf is MUCH bigger in community). Se we wanted smth with compile time type checking. KTE has a goos story for that.

[Mikael Ståldal]

Right, yes that's a clear disadvantage with Thymeleaf.

[Mikael Ståldal]

I guess you need to make sure to have automated tests covering all templates.

[Cies]

where type-safety can replace tests, i always prefer type-safety

[Mikael Ståldal]

Yes, so do I, unless the type-safety comes with other significant costs.

[Mikael Ståldal]

I just discovered that you can get sort-of type-safety with Thymeleaf through Jetbrain's plugin, if you add a variable declaration to the template like this:

<!--/*@thymesVar id="model" type="my.package.MyClass"*/-->

Then you will get an inspection warning in the IDE if you get it wrong, and you can even navigate from the template to the Kotlin code. Kotlin data classes works fine.

This feature seems quite undocumented though, but the IDE will suggest you to add this.

[Cies]

That's cool. We do kotlinxhtml though 🙂 Our templates are simply Kotlin code.