Does anyone use Temple instead of Heex in their Live View projects?

I do, but I am the author of the library .

Can you note any major shocks someone coming from heex should expect when using Temple? How do the Javascript blocks work with %JS{} functions?

Nothing that I can think of.

One note tho is the attr and slot dsl do not work (the functions you put above a component).

These actually do work.

I don’t know if they’ve always worked or if something changed that made them work, but I’m pretty sure they work as of now.

Looks really nice!

Is there more info on the script macro? Does it have any knowledge of the component it’s in or is it just JS?

Any plans for adding a style macro for scoped css?

The tags are not actually macros, the temple macro traverses the ast inside it and compiles it using whatever EEx engine you have configured.

The script and style tags are just plain html tags, no special behavior.

I don’t have any plans regarding that, but you could probably define your own macro to do special compile time things if you wanted.

I didn’t know of this library. Just tried it out and it seems to work really nice! Thank you @mhanberg.

I’m all in for using an embedded language for these things, and implemented one for F# a looooong time ago: https://codeplexarchive.org/codeplex/project/wingbeats.

Whats the upside of this over html templating? If someone has a sales pitch

1. Vibes. You like how it looks and it’s easier to type. So, subjective DX I suppose.
2. In an earlier iteration, Temple had components but EEx did not. As LiveView matured, HEEx was introduced with components, so not a huge selling point now anymore. But Temple uses the same component model, so components can be used in either markup regardless how they were authored.
3. You can use temple and its components without LiveView, and with any EEx engine.

In a language like Elixir where everything is expressions, it works really well to embed a little language that can easily be translated to HTML. One upside is that you can use Elixir’s control flows directly without escaping the template or relying on the template’s control flows.

I listened to an interview with Chris Lattner (the father of Swift), in which he said he regrets adding statements to Swift. Because of this, they had to add a lot of extra complexity on top of Swift to support Swift UI, where you can write view hierarchies directly in Swift.

I just tried Temple and I liked how easily it could co-work with existing HEEX templates. If you are curious you could try it out, perhaps in a messy view with logic, to see if you like it. Remember, Apple put a lot of effort into supporting something similar, so if it’s a new idea for you, it’s at least worth trying.