hytags.org
It started as a way to write full-stack web apps in Swift without a separate frontend, but grew into a small language with control flow, functions, and async handling via HTML tags. The result is backend language-agnostic and can be generated from any server that can produce HTML via templates or DSLs.
The example from the link's main page is equivalent to:
(button "Say something")
(on_click
(selection-insert-after
(div "Hello, World ")))
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.
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.
"Code is data" is more general and fundamental idea; it's a fact of nature. Homoiconicity is a way to try and embrace it instead of fighting it.
No, its not. If it was, the attribute vs. child element distinction would not exist. HTML (and HTML-inspired XML) syntax is not a trivial alternative to S-expression syntax, it is more complex with additional distinctions.
A simplified subset of (HT|X)ML that uses only elements and no attributes is pretty much directyl equivalent to S-expressions, sure.
Add one more type, like a map, now you have attributes
(fn btn ()
(div
{onClick (fn ())}
"Click me"))For example, in elixir parsing html is this syntax: `{html_tag, attributes, children}`.
You indeed can include attributes in s expression
(parrot (@ (type "African Grey")) (name "Alfie"))
<parrot type="African Grey"><name>Alfie</name></parrot>
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, ...).
But that said, this could unlock some interesting use cases where security isn't the primary concern. Like few internal tools, prototypes, small side projects where the tradeoff might be worth it.
- thoughts as i was reading this -
ok, so we're programming via an AST vs syntax
I think this is interesting, however there's notable downsides - verbosity, dom bloat & debugging
A potential upside to this is very odd but interesting meta programming capabilities, since the code should be able to inspect & modify itself fairly easily by inspecting the dom
I am inclined to distrust the claim that this reduces complexity as most of the actions are mutation heavy directly to the dom, and the stack based programming is something i struggle to practical examples where it is a significant improvement to mainstream strategies
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.For example:
lappend responses [dict status 200 body ...]
I can see that being an attribute:
<request-send url="..." as="greeting" />
<response-text response="greeting" as="text" />
<selection-set-text text="text" />Accessing a variables works like this at the moment:
<selection-set-text $text="varname">
<response-get-text $="varname">I'm a little too enamored with web components to give it more consideration/testing, but it looks like it could be great for blue sky/green field projects.