HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise. A tag can be viewed as function application, with the attributes as named arguments and the elements as variadic arguments.
The example from the link's main page is equivalent to:
(button "Say something")
(on_click
(selection-insert-after
(div "Hello, World ")))
[apparently HN strips all emoji but you get the idea]
> HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise
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.
I'm not sure I see your point. Yes, you can describe the same meaning/structure with S-expressions and HTML/XML syntax, but that's the complete opposite of having the same syntax, in fact syntax is the difference!
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.
This seems similar to _hyperscript, except it uses custom tags instead of the "_" attribute. I'm not sure which approach is better, but personally, I prefer keeping the same document structure and varying behavior through attributes. Easier to rewrite on the fly. Custom tags can be clearer in some cases, but attributes tend to work better with existing HTML and tooling.
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.
Interesting idea. As a product person I'm immediately thinking about security. how does this handle auth, data validation, etc when backend logic is embedded in HTML?
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.
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.
HTML can be so powerful when used as DOM instead of plain string as is sadly used in most html templating engines on the backend, one example of DOM template engine built by myself https://github.com/givanz/vtpl
This looks very interesting! It reminds me of the approach taken by HTMX or Alpine.js, but with deeper control flow logic. In your opinion, what is the main advantage of hyTags over HTMX for developers managing complex UI states?
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, ...).
first let me say i applaud you for experimenting and doing something unconventional
- 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
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:
Neat! Looks like a pretty straightforward way to develop.
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.
HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise. A tag can be viewed as function application, with the attributes as named arguments and the elements as variadic arguments.
The example from the link's main page is equivalent to:
[apparently HN strips all emoji but you get the idea]> HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise
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.
> 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
I'm not sure I see your point. Yes, you can describe the same meaning/structure with S-expressions and HTML/XML syntax, but that's the complete opposite of having the same syntax, in fact syntax is the difference!
Exactly, code is data ;)
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.
Reminds me of ColdFusion. Don't recall having a great time using it, though I was very young at the time so maybe my memory is distorted on this.
CF was the first thing I thought of when I read the title too.
I remember when one of the primary criticisms of ColdFusion was programming logic in the form of tags.
This seems similar to _hyperscript, except it uses custom tags instead of the "_" attribute. I'm not sure which approach is better, but personally, I prefer keeping the same document structure and varying behavior through attributes. Easier to rewrite on the fly. Custom tags can be clearer in some cases, but attributes tend to work better with existing HTML and tooling.
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.
Interesting idea. As a product person I'm immediately thinking about security. how does this handle auth, data validation, etc when backend logic is embedded in HTML?
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.
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.
HTML can be so powerful when used as DOM instead of plain string as is sadly used in most html templating engines on the backend, one example of DOM template engine built by myself https://github.com/givanz/vtpl
This looks very interesting! It reminds me of the approach taken by HTMX or Alpine.js, but with deeper control flow logic. In your opinion, what is the main advantage of hyTags over HTMX for developers managing complex UI states?
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, ...).
first let me say i applaud you for experimenting and doing something unconventional
- 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
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.
Maybe useful inspiration from TCL: there are many commands that define new variables, which makes modeling the stack unnecessary.
For example:
Appends a new dict to the list held in the variable responses, creating the variable if necessary.I can see that being an attribute:
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:
Keeping the dollar syntax, setting the return value to a named variable could look like this:Neat! Looks like a pretty straightforward way to develop.
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.