DOM bloat can certainly become a problem when adding lots of code in e.g. table rows. I added functions mainly to be able to move common code into a central place to minimize that problem.
You certainly must get used to the stack based approach. I tried to make it more approachable by making stack lookups type based (automatic search for value with matching type) and by using type-prefixed commands, e.g.
<request-send url="..."> // returns response
<response-get-text> // looks up response on the stack and returns string
<selection-set-text> // looks up string on the stack and writes it as text content to the current DOM element.
The main reason for using a stack was reducing verbosity because for short scripts using variables felt unnecessary when the type-prefix of the command already communicates the variable contents. But it could still be a good idea to have a shorter syntax for assigned variables.
Accessing a variables works like this at the moment:
<selection-set-text $text="varname">
Keeping the dollar syntax, setting the return value to a named variable could look like this:
I think the approach of HTMX is that UI state is primarily managed by delegating DOM updates to the server and then modifying the DOM with the response.
With hyTags one can do a lot of things without server calls and without resorting to javascript (e.g. inserting and deleting new rows, showing a loading indicator, validating input, animations, ...).
Not sure how homoiconicity is related to this at all. Macros don't seem involved.
But I do think s-expressions are an improvement over HTML in certain scenarios.
That said (talking to OP now), why is the control handler outside the button?
In actual HTML, we have [button onclick="codeToBeEvaled()"]
In this thing, you have [button][onclick [sub-expressions]]
With s-expressions, at least you have some semblance of function calls,
which would make control flow operators seem slightly more natural,
but this hybrid of semantic and syntactic choice just seems bizarrely limited.
>But I do think s-expressions are an improvement over HTML in certain scenarios.
I agree. S expressions are a data interchange format. HTML is a markup language. They solve different problems.
S expressions define nested lists of atoms. HTML describes semantic hypertext documents defined by a document tree made of element nodes as subtrees, attribute nodes as subtree metadata, and text nodes. In some scenarios a uniform data structure like s expressions is nicer to work with.
To be honest it boggles my mind that XML was ever used as a universal data format.
For most tags you can also put the event handlers as first children inside the element, but self-closing tags like <input> don't support that. I'm now putting the event handlers always outside (as next siblings) for consistency.
It's only frontend logic. There is a small runtime that is implemented in Javascript interprets html tags. Backend logic needs to be implemented on the server.
The main reason for using tags was for me that they can be generated from a host language and stay readable, even for longer scripts. I'm using Swifts result builders for my projects, which enables autocompletion and partial type safety.
Sure! But I tried to restrict it to threads that got (interesting) comments, and there aren't any yet in that one. So let's put it in the SCP* as well :)
I'm using Swift Result Builders as a statically typed language to generate HtmlScript code (which a similar approach as html, the programming language):
So how does it work if a library owner changes something in his library—do they have to update all projects that depend on it and then push this as a single commit?
Generally it's on the library owner to update all projects that depend on it, i.e. not break their tests, but this need not be done as a single commit. More concretely:
If the change is internal to the library, i.e. does not require the projects that depend on it to change the code, then the library owner simply tests that none of the affected tests break (globally), and updates their library.
If the change requires dependent projects to change their code, then some way is first figured out of having code that would work with both versions of the library, then updating all the callers individually (e.g. in a separate mostly-automated change for each project to review), then we're in the first situation above.
“Old APIs can be removed with confidence, because it can be proven that all callers have been migrated to new APIs.” (from the older article)
Yes. And that is easy because the tooling can find all callers and the test infrastructure can find and run all related tests (even, if need be, literally every test).
You certainly must get used to the stack based approach. I tried to make it more approachable by making stack lookups type based (automatic search for value with matching type) and by using type-prefixed commands, e.g.
reply