What about the individuals that are not strong at elixir, but HTML and CSS, we’re alienating them by not being able to have multiple approaches. It’s way easier to learn that some of the templates contain elixir code than learning elixir.
Schultzer
Eiji
Only helper functions that accepts data from assigns and changing them to HTML attribute values (or part of said value).
If we talk about framework then yes, but Phoenix is not a framework. 
The point in both the language and Phoenix is flexibility. It does not exists for a bad practices, but for extending it easily without any magic and it works fine. I don’t see it as a failure, but you have to learn it as same when you are changing from OOP to FP.
Both function calls for createElement and LiveView way ends with a string, so I don’t see a difference here. Basically HEEx template is doing everything you said except that it returns a struct (for dynamic data) that is then parsed and called recursively to generate a String.
It would make only sense in Hologram, but LiveView would never do this, because the entire concept of it is that the rendering happens on the server side and then the diff is generated and applied. Even Hologram does some rendering on server side which makes sense, because of SEO (bots does not have to listen to your JavaScript).
Because of SEO, because it’s all based on decades old standards that are only updated (with new elements, syntax and methods) we can’t do much here no matter how how much money, people and resources we would put into it. This could be true for GUI apps, but not for the web apps. Losing SEO is just too much and nobody would use such a framework.
If you agree with that then see that supporting 2 different template compilations does not makes sense as it’s not practical. It’s simpler (which means safer, more stable and more updates) the way it is now. Unfortunately we can’t do that for the above reasons.
That would not happen at least before 2.0.0 of Elixir as it means a breaking changes in the language syntax. This involves AST an so on. I guess that such example would never be accepted for 2 reasons:
- It would be against
Elixireasy of extend - it does not makes sense from language perspective to supportHTMLsnippets in the source code. - It would be a true nightmare for syntax highlight. With
sigilswe simply do highligh on everything that’s inside thetextliteral (or interpolated text expression for some sigils), but here I don’t know if it’s even compatible especially with arithmetic operations. - What if people would ask for
XMLsupport? If there is aHTMLone then why we don’t support forXML? Then we would have questions forJSON,Yaml, configuration files, markdown and so on …
Sorry, it would not work without sigils in my opinion. Maybe I’m not enough experienced as I’m not an Elixir core developer, but I don’t see it to happen at all - not in near nor far future. The language would be completely different.
I have no idea how JSX works. If it works like in way you show it would mean at best that Phoenix would bring it’s own version compiler. I really don’t see it happen, but maybe … someone … may create an alternative … However it would not happen soon. It would require many years, testing, adoption and so on … Again you would need a lot of money, time and resources for that and especially people - a very skilled ones.
Hint: Looks like you are not familiar with metaprogramming. Please look for AST and then describe to yourself your idea. Again, you would have lots of conflicts with existing operators. From a plain metaprogramming perspective your idea looks impossible.
0
garrison
I am reminded of the following quote:
Every templating language inevitably turns into a very poor programming language over time. It will grow to add conditionals, loops, scopes, macros, and other things that are much nicer in actual code.
A templating language is mainly an inner platform effect. It targets a weird imagined archetype of someone who isn’t allergic to code, but somehow isn’t smart enough to work in a genuine programming language. In my experience, this archetype doesn’t actually exist. Designers don’t want to code at all, while coders want native expressiveness.
Taken from one of my favorite articles.
Fundamentally, programming is for programmers. There seems to be an idea that we should weaken the power of programming languages to make them more accessible, but this does nothing of the sort. Non-programmers don’t look at a HEEx template and say “aha! this I can do!”. It just doesn’t work that way.
The beauty of the JSX approach is that it essentially degrades into looking like HTML if the component is simple, and therefore naturally expresses the “why can we not have both” that I think you’re looking for.
I am not against accessibility or in favor of gatekeeping, but I draw the line at taking power away from programmers in some sort of misguided attempt to appeal to novices. This approach helps no-one.
If I might offer an analogy: templating languages are like a dull knife. Worthless to a chef, and yet also perilous to a novice.
2
garrison
No, createElement in React (and in my hypothetical Elixir thing) does not return a string. It returns data: in JS something like {tag: 'div', children: [{tag: 'span', ...}]}.
You can think of this like the difference between something like Ecto and something which builds SQL queries by concatenating strings ("SELECT * FROM" <> " my_table" <> "WHERE" ...). The benefits are similar.
There is no reason the diffing needs to be done on the level of strings, that’s just how it happens to be done. React diffs at the element level, logically.
Actually morphdom on the client does this too because just setting innerHTML would nuke the implicit DOM state. So you’re actually going from template -> strings -> elements -> DOM when you could instead be going from code -> elements -> dom.
And this is all made much messier by the fact that HEEx parses the elements! There are several generations of tech debt stacked up on each other here.
I can write a compiler to do whatever I want! JSX did not require breaking changes to JS, they just transpile it back into JS. I demonstrated what that looks like.
As a middle-ground you could use a sigil but there’s no reason a compiler can’t just consume an entire “Elixir+HTML” file and output an “Elixir” file!
I want to emphasize one more time that I’m not saying Phoenix should necessarily do this (though I would like that very much). Honestly at this point I may as well just be sketching a framework I want to write. And maybe I should!
(Note the complete lack of any mention of metaprogramming in my comments.)
0
Schultzer
Are there people out there that was born programming, or did they start out learning it little by little. I don’t disagree with any of your arguments. But I do believe that you shouldn’t be able to cut yourself no matter how you hold a tool, if that happens something fundamental has gone wrong in the design process. Thats how I approach anything. The computer is literally in front of us, lets make it work for us and not the other way around.
0
derek-zhou
JSX offers slightly better ergonomics than a template language with a frigging compiler. It took off only because it came from a heavy weight player. I do not think that a model for small players to follow.
EDIT: If I reuse your example:
def my_component(%{error_message: error_message, count: count}) do
zero_message = {:div, "No count!"}
if error_message do
{:div, error_message}
else
count = (count * 2) - 1
case count do
0 -> zero_message
n -> {:ol, Enum.map(1..n, &({:li, &1}))}
end
end
end
Compared to your original JSX-ish code, this is pure elixir, as legible as yours, and the returned data is trivial to convert into html or to post-process.
1
Eiji
ecto works similar to HEEx. First a struct is returned an then it’s transformed into HTML string (Hee) and SQL string (ecto), see: type t/0 in Phoenix.LiveView.Rendered @ phoenix_live_view hex documentation.
Not sure how it works inside JS side, but Phoenix is sending data in JSON format. You can even debug the diffs - it’s all in the official documentation.
You can’t execute code without parsing it. At some level there is always parser involved. No matter if we do that in the language itself or within Phoenix. If we would not parse then we would not have all generators and conditions in the templates. We only could use a plain strings which would be a nightmare.
If you write a custom compiler yes, I mention it later after text you have quoted. Still it’s not gonna be easy and would be very messy because of mentioned conflicts. Look that it would not be a .ex files any more as we would not be able to turn the source code into AST without using your compiler. It’s like you saying you are fine to clone and modify language internals. Even if you do that lots of tooling would stop work, because all of editors plugins would have to implement your custom syntax.
No, no - I’m just telling the “Phoenix story” explaining why it can’t go that way in my opinion.
How you see it working for credo and all other tools? They work on Elixir AST. What your compiler would do is your trouble, but credo works on the source file. Same goes for syntax highligh. You are basically asking community to support your clone of Elixir with “enhanced syntax” by adding HTML code support. Look that support for every editor is different which means that for a real support people would need to wait a lot!
Look, there are just too many consequences. Even if you are fine with it then everything build so far does not have to be like that. Again nobody would be motivated to support something just to support it. Bringing HTML into Elixir is not so easy. You may write your own compiler and then what? You would maintain your own LSP, syntax highlight, credo, dialyzer and literally every other tool and plugin for all existing editors?
Look Elixir is amazing and I’m not saying your idea is bad or good, but just look how long way Elixir made for it’s adoption and support. It’s not like that it have awesome support in literally every code editor with plugin support. Some editors are supported better and some worse. You are not going to release your own language, but your own file format. This means much less people involved even if you succeed. It just does not look like a realistic plan unless you plan for many, many years or don’t care about everyone else and “make it work” in your favourite editor, but if that’s so why people would support it if it’s just for your specific case?
Again, perspective - it could be an “interesting idea” or a huge waste of time in context of years of adoption. In my opinion “just adding HTML” support is not enough and once again people would ask about other formats like XML. What would you do? Would you maintain literally every popular format? For every editor? Sigils are huge winners here as they “just work” already and all we have to do is to add a syntax highlight for it and later enhance support in let’s say LSP. It’s faster, easier to read and maintain. You really need to have a very solid arguments for your idea completely regardless if it’s good or not.
0
jdiago
I’m going to approach this from a different perspective.
I had an opportunity to jump on a small-ish project a little while ago where the og author did have separate heex files. Since that’s how the project was when I got there, I just followed that convention. Although, I usually started my own LiveView code without the extracted heex files.
What caught my attention from the OP was the mention of the friction of having to jump between files so I’m looking at this with tools in mind. The reason the original question doesn’t bother me either way is because I’m used to doing this:
In the first screenshot, I have the same big file open in 2 splits so I can see 2 different regions at the same time. In the second, I have the heex file in the top split and the LiveView module in the bottom.
This is just an example but I usually try to have a max of 3(maybe 4) splits in various layouts. The splits could share the same file or not, the way I interact with them is the same.
The example I show is my nvim setup. I also do the same in vscode and zed (and JetBrains stuff back when I used those).
4
garrison
I went out of my way to take a stand against gatekeeping in my reply.
People who learn to program do it by programming. Templates are not pedagogically useful; in fact, they’re probably the opposite.
Just in case my analogy got lost: dull knives are understood to be extremely dangerous because they encourage the wielder to use excessive force and therefore risk causing serious harm to themselves.
Honestly I thought it was a pretty good analogy!
1
garrison
The fundamental distinction is between using templates, which use string handling and (generally) a degenerate sublanguage, and using code to build up the UI representation (DOM, here).
Your example is pretty much exactly the compilation target of the imaginary Elixir-JSX code that I showed. Except that I would point out for is actually a language construct 
The only added value of JSX is that it makes the code look prettier. Which is entirely arbitrary! But most people seem to agree it looks prettier.
Whether something takes off and whether it’s good are often poorly correlated. I get the impression that many assume React is bad because it is popular, which is not true. Assuming something is bad because it’s popular is just as wrong as assuming something is good because it’s popular.
I hope it is not lost on you that HEEx templates are also compiled, Elixir is compiled, and JS is also often compiled from TS even without JSX anyway! Not that I would ever hate on source distribution; I am a big fan.
0