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 ")))
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")) (parrot (@ (type "African Grey")) (name "Alfie"))
<parrot type="African Grey"><name>Alfie</name></parrot>
For example, in elixir parsing html is this syntax: `{html_tag, attributes, children}`.
You indeed can include attributes in s expression
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.
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" />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.