This is completely different story especially that the DSL would in fact render on the server-side. Hologram is supposed to work on everything it could on the client-side. This minimises server usage like in classic SPA with WebSocket connection.
Eiji
0
KP123
The whole point is to write elixir on the client side no? This syntax reminds me very much of what Lustre is doing in the Gleam community and they managed to get that to compile to js. If elixir works then do end blocks also work, also I said a syntax “like” Temple anyway, not exactly Temple.
Finding a way of composing the UI in some way that’s native to your underlying language (in this case macros and functions) pays dividends and should be prioritized if it’s possible. It makes picking up UI building as simple as learning the language itself, provides autocomplete and ide support, is easy to extend with new features….
I guess if Elixir works on the client why wouldn’t composing your UI out of Elixir functions work?
0
Eiji
It does not matter since the DSL is a macro call and the macros are evaluated in compile-time. In theory you can store DSL as String and evaluate it on the client-side, but this is exactly what templates do - just in different format.
As author mentioned he don’t have plans on supporting other formats as he want to focus on just one.
Also do … end block in practice looks very bad as you can’t tell what specific end is doing. It’s also not like that every DSL in Elixir needs to have many nested DSL calls, but in case of templates it’s a completely different story …
The point is you want to replace HTML when the library aims to replace most of the JavaScript with Elixir. That’s also a completely different topic. At first I also liked Temple, but I can’t say a word for multiple end argument and I agree with the overall decision to move to templates. Maybe we could talk about HAML-like proposals, but unfortunately HTML templates could be way too nested and real world examples are not really readable.
0
KP123
This I’ll concede and I agree. But it’s something that can potentially be designed around if the overall feeling of how it’s used is something OP likes. That’s why I asked if something like it would be preferable.
This is a much more constructive response as instead of just dismissing a question for being asked it provides a path forward for more discussion. Like I stated above I’m not saying adopt Temple wholesale.
It’s hard to tell as the docs especially around templates and layouts are incomplete but just looking at the few examples listed the existing template language looks like heex. I’m not sure if EEx.SmartEngine is used in this project for templates but if it is Temple might just work already (haven’t tested it. I read this thread then immediately asked my question). And if it just works already then I think it’s a valid path to consider going forward
0
Eiji
It’s not something we can “design”. We cannot change do … end syntax and without it we don’t have a nested DSL. Therefore the only solution left for nested document structure are templates. No matter if we like them or not.
The point is you are mixing solutions. HAML is much more closer to HEEX and Hologram as all of them are templates (String). You have proposed using parts of language and it’s rather only possible to be done in DSL. DSL and templates are completely different topics.
This does not work as you think. As said DSL → macros → compile time. There is no other way to pass compile-time code to the client than storing said code as a String and evaluate it on the client. Compiling such String to JavaScript is also not an option:
- First of all it’s template
- Secondly unless we would not validate
Stringwe can’t even say if it’s validElixircode - This makes it just another template - template with lots of
endthat we agreed are bad
However compiling said code on client means implement complete Elixir parser and evaluator on the client side. The consequences of your proposal are unfortunately overcomplicated. I really like meta-programming, but there is no way it would be considered even in mid-term plans and everything after it is not clear most probably even for the author.
For sure I have suggested Phoenix template support, but only as a workaround to speed up adoption considering existing hex packages. Even in my suggestion this would be a partial support solution, so for real Live-like features the templates would have to be rewritten anyway - just a bit later.
What you propose would be something similar to what I asked for adoption purposes - there would be a raw HTML string send to the client and added to the existing element i.e. the code would not be send to the client and the evaluation would happen on server side. I don’t think temple have lots of hex packages we would like to support and rewrite letter when Hologram-specific features are needed.
0
KP123
Would a syntax LIKE Temple work. Not would Temples EXACT syntax work. I’m not proposing we change how do end work or that we use do end at all. In fact I’ve already agreed with you that I’d also like to get rid of end and by extension do. But would a syntax that looks like html-element keyword-list: “of-attributes”, similar to HAML and Temple, be preferable if possible?
0
Eiji
Wait, I’m lost 
That’s a description for the DSL - especially when you mention macros and functions.
That’s a description for the template.
Trust me there’s a huge difference here. The Elixir code is translated to AST (abstract syntax tree) then to beam files. On the other hand HAML-like templates would only imitate language - it would not be evaluated or verified as an Elixir code. Therefore as any other templates it would not provide autocomplete or IDE support out of the box.
Ok, so it’s not gonna be DSL like in Temple then we have one template vs another one. As said author does not plan to support multiple template formats and changing template format now is not likely to happen.
It would not give any benefit and only cost a lot of time to implement. You said that it would look like Elixir, but that’s impossible in HAML as we don’t write do … end and if we choose other format as said many end would look bad. So again in best case even if author would agree it would only imitate Elixir code.
I like HAML idea, but I’m not sure we can make it better than HOLO or HEEX template and keep Elixir-like syntax at the same time. If you say “Why we can’t just remove do … end” blocks then I would ask what with id? It’s common to use a hash for it, right? But in Elixir syntax it starts a comment. So we would also drop hash … Is it still Elixir-like syntax after such few changes? In my opinion there is no good solution here, but of course I may be wrong …
0
KP123
This is basically what I wanted to get too. I would say that to my original question your answer would be yes you would like a syntax like temple if one were possible. Perhaps we have different aesthetic perspectives but to me haml is a syntax like temple, which is why I was confused when you suggested that, that one is a dsl and one a dumb template language are implementation details. They’re details that support my asking the question as they prove that there are different fundamental implementations for providing such a syntax.
So if you like the direction temple is heading in you could then say “I like these aspects of this temple. They help facilitate X,y,z. I have these constraints given the context, what can I build that gets me closest to X,y,z within my constraints?” It won’t be haml or temple. It will be whatever that solution is.
0
KP123
Another thought about syntax but a different perspective. You might not want to directly tie UI building to HTML at all. I’m unsure as to the scope of your project but if your goal is apps written in Elixir running anywhere you may want to take a leaf out of this weeks Javascript framework, Lynx, by ByteDance. Have a simplified set of tags that can be remapped to platform specific UI at runtime. It’s similar to how LiveView Native’s views works. If you come up with a good solution for marking accessibility you should be able to figure out how to map a generic <text> to <h1>, <p>, etc (perhaps Apple’s accessibility modifiers can be of inspiration)
1
bartblast
Creator of Hologram
I meant that it would be confusing if we supported multiple syntaxes (e.g., Holo and HEEx), especially in such early stages ot the project. This could potentially confuse users.
The action may be handled by some parent component, and as a result, props to some of its nested children may change. I prefer a more declarative approach versus an imperative one. The approach you suggested (if I understand it correctly) requires parent components to know something about their children - we want the actual component to react to its props changes independently.
Unfortunately, that’s a much more complex situation.
2