[HN Gopher] Show HN: HyTags - HTML as a Programming Language
___________________________________________________________________
Show HN: HyTags - HTML as a Programming Language
This is hyTags, a programming language embedded in HTML for
building interactive web UIs. 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.
Author : lassejansen
Score : 51 points
Date : 2026-01-13 10:57 UTC (1 days ago)
(HTM) web link (hytags.org)
(TXT) w3m dump (hytags.org)
| scatbot wrote:
| 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.
| lassejansen wrote:
| 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.
| catapart wrote:
| 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.
| akhil08agrawal wrote:
| 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.
| lassejansen wrote:
| 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.
| velcrovan wrote:
| 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]
| lassejansen wrote:
| Exactly, code is data ;)
| publicdebates wrote:
| 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.
| lassejansen wrote:
| 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.
| scatbot wrote:
| >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.
| TeMPOraL wrote:
| > _Not sure how homoiconicity is related to this at all.
| Macros don 't seem involved._
|
| "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.
| dragonwriter wrote:
| > 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.
| embedding-shape wrote:
| > 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"))
| SkiFire13 wrote:
| 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!
| css_apologist wrote:
| 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
| lassejansen wrote:
| 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.
| dhamidi wrote:
| Maybe useful inspiration from TCL: there are many commands
| that define new variables, which makes modeling the stack
| unnecessary.
|
| For example: lappend responses [dict status
| 200 body ...]
|
| Appends a new dict to the list held in the variable
| responses, creating the variable if necessary.
|
| I can see that being an attribute: <request-
| send url="..." as="greeting" /> <response-text
| response="greeting" as="text" /> <selection-set-text
| text="text" />
| lassejansen wrote:
| 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:
| <response-get-text $="varname">
| antomal wrote:
| 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?
| lassejansen wrote:
| 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, ...).
| bdcravens wrote:
| I remember when one of the primary criticisms of ColdFusion was
| programming logic in the form of tags.
| givan wrote:
| 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
| radarsat1 wrote:
| 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.
| sedatk wrote:
| CF was the first thing I thought of when I read the title too.
___________________________________________________________________
(page generated 2026-01-14 23:01 UTC)