1–10 of 34 posts
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.
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.
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.
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.
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.
The example from the link's main page is equivalent to:
(button "Say something")
(on_click
(selection-insert-after
(div "Hello, World ")))
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. 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]
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.
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]
Exactly, code is data ;)
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.