HTML templating

1

This is related to my previous topic, but it’s much more broad, so it probably makes more sense as a new topic.

In JS land, html templating (both client and server side) these days is mostly done with JSX and tagged template literals. React and similar libs are extremely popular, so the tooling is pretty good.

What do you guys use/recommend for html templating in Haxe these days (in terms of tooling support, least amount of headaches) - hxx, haxe.Template, tink_template, haxe-react, custom macros, …?

2

There is coconut.ui, which is a React alternative for Haxe. Unfortunately there is not super much documentation yet (and its bit spread in the readme’s on github), but nevertheless I did create websites/tools with it. And I found it super nice, everything is typed and works (once you get the hang of it) quite straightforward.

I wrote a small how-to-get-started document here

2 Likes
3

For simple static sites I really like Mustache. It is easy to learn and just works.

1 Like
4

@mark.knol coconut looks very nice as React alternative, but I’m looking for something more lightweight. VDOM in general has a lot of overhead - with something like tagged template literals, you know which parts are static and which are dynamic (which is very useful for optimizing both server and client side rendering). Things like lit-html, lighterhtml, hyperhtml, svelte, etc. are much more efficient than React because of that.

@parallax yes, Mustache is really nice for simple stuff, but it becomes painful to use on more complex templates. Something like jinja2/twig would be better, but AFAIK there’s no Haxe implementation of something like that.

5

Hej !

Tink_Template is also cool, I don’t know if it answers your question…

6

@filt3rek Sure, any suggestion is very welcome. Tink_Template does look very interesting. How was your experience with it (tooling support, potential problems / gotchas, etc.)?

7

Thanks to its synthax, I write code in my template almost as I would do in a regular class. All is accessible as if you were in a regular class and in fact the generated code ends in the class where the template is called.
The only problem with nightly builds of Haxe and I think with Haxe 4 is that it doesn’t target the line where a compilation error occurs. You have to deal with the caracter offset, but I hope it will be fixed soon (@back2dos any news from that please ?)

8

@filt3rek since the templates are in separate files, how’s IDE support (syntax highlighting, autocomplete, refactoring, etc.)?

9

Good point, I didn’t hought about that while answering. I use VSCode and there is no support for syntax highlighting, autocomplete and refactoring) for tink_template. The compiler only tells where an compilation error occurs (and even as I mentionned, not very well these days, only with offset position…)

10

This is a haxe issue. In macros, one can only specify file, start and end offset and it is the compiler that turns the character range into line/column. You’ll have to report an issue in the Haxe repo :wink:

11

Thanks Juraj for your answer.
But how is it that before it worked ? There was a change about that in the compiler ?
Or maybe we have to do the conversion by ourselves counting the \r\n something like that ?

12

There must have been a change in the compiler. Macros have no control over how positions are reported.

13

Juraj,

I want report that issue but I’m not sure I’ll be good to explain that. Maybe could you do it, you know better how ? (Or tell me what to write them :rofl: )