Hacker News: alexpetros

New comment by alexpetros in "XML Is a Cheap DSL"

alexpetros — Sat, 14 Mar 2026 17:09:31 +0000

For what it's worth, I think that an embedded DSL to represent most expressions tersely is a worthwhile idea to explore—it's just a more expensive one. That's a cost-effective choice at a some levels of resourcing, but not every level of resourcing.

New comment by alexpetros in "XML is a cheap DSL"

alexpetros — Sat, 14 Mar 2026 14:29:36 +0000

In the blog I link to a Prolog post I wrote in January because I am very interested in the possibility of using Prolog to prove things about the Fact Graph. I have a personal branch where I try to build some tools for it with DCGs. The nice thing about XML is that I can easily explore it as Prolog terms with committing the entire project to Prolog.

New comment by alexpetros in "XML Is a Cheap DSL"

alexpetros — Sat, 14 Mar 2026 14:16:42 +0000

In the context of the article, "cheap" means "easy to set up" not "computationally efficient." The article is making the argument that there are situations in which you benefit from sacrificing the latter in favor of the former. You're right that it's annoyingly slow to parse though and that does cause issues I'd like to fix.

New comment by alexpetros in "XML is a cheap DSL"

alexpetros — Sat, 14 Mar 2026 14:12:25 +0000

This is a good question! We do it, it works, and it's definitely an advantage of XML over alternatives. I just personally haven't had the time to dig in and learn it well enough to write a blog post about it. In practice I think people update the Fact Dictionary largely based on pattern matching, so that's what I focused on here.

New comment by alexpetros in "XML is a cheap DSL"

alexpetros — Sat, 14 Mar 2026 13:58:04 +0000

Author here. I agree with all this, and I think it's important to note that nothing precludes you from doing a declarative specification that looks like imperative math notation, but it's also somewhat besides the point. Yes, you could make your own custom language, but then you have created the problem that the article is about: You need to port your parser to every single different place you want to use it.

That's to say nothing of all the syntax decisions you have to make now. If you want to do infix math notation, you're going to be making a lot of choices about operator precedence. The article is using a lot of simple functions to explain the domain, but we also have switch statements—how are those going to expressed? Ditto functions that don't have a common math notation, like stepwise multiply. All of these can be solved, but they also make your parser much more complicated and create a situation where you are likely to only have one implementation of it.

If you try to solve that by standardizing on prefix notations and parenthesis, well, now you have s-expressions (an option also discussed in the post).

That's what "cheap" means in this context: There's a library in every environment that can immediately parse it and mature tooling to query the document. Adding new ideas to your XML DSL does not at all increase the complexity of your parsing. That's really helpful on a small team! I agonized over the word "cheap" in the title and considered using something more obviously positive like "cost-effective" but I still think "cheap" is the right one. You're making a cost-cutting choice with the syntax, and that has expressiveness tradeoffs like OP notes, but it's a decision that is absolutely correct in many domains, especially one where you want people to be able to widely (and cheaply) build on the thing you're specifying.

New comment by alexpetros in " Htmx – The Fetch()ening"

alexpetros — Tue, 04 Nov 2025 00:06:37 +0000

So here's the htmx example for click to edit: [0]

New comment by alexpetros in " Htmx – The Fetch()ening"

alexpetros — Mon, 03 Nov 2025 23:56:41 +0000

Yes! I expect that I will mostly be sticking to `hx-target` though, for the reasons stated above.

My interest in htmx is more on the coarse-grained aspects of its interface, not the finer ones, which is a consistent theme in my writings about it [0].

[0] https://alexanderpetros.com/triptych/

New comment by alexpetros in " Htmx – The Fetch()ening"

alexpetros — Mon, 03 Nov 2025 23:16:36 +0000

> Why bother with v4 at all? If it dilutes that simpler interface?

v4 makes almost no changes to the interface, other than to flip inheritance to be off by default.

> I think that even with req/resp morph leads to a simpler majority use case and that's what Turbo and Datastar have both shown. No?

Although you can use the idiomorph extension for htmx, I personally don't think idiomorph is simpler, because there's an algorithm choosing what parts of the page get replaced based on the server response; I prefer to specify exactly what parts of the page get replaced in much simpler terms, a CSS selector, with `hx-target`.

Per [1] above, my style is minimize partial page responses wherever possible, so the ones that I do have are bespoke and replace a specific thing.

New comment by alexpetros in " Htmx – The Fetch()ening"

alexpetros — Mon, 03 Nov 2025 22:18:32 +0000

> why use HTMX when it really seems like (a heavier) Datastar-lite?

The reason to use htmx is that it has a simpler interface optimized for the majority use-case.

With htmx, you are largely tied to a request/reply paradigm. Something happens that triggers a request (e.g. user clicks a button, or some element scrolls into view), htmx sends the request, and then it processes the response. The htmx interface (`hx-get`, hx-trigger`) is optimized to make this paradigm extremely simple and concise to specify.

Datastar's focus (last I checked) is on decoupling these two things. Events may stream to the client at any time, regardless of whether or not they were triggered by a specific action on the client, and they get processed by Datastar and have some effect on the page. htmx has affordances for listening to events (SEE extension, new fetch support) and for placing items arbitrarily on the page (out-of-band swaps) but if your use-case is a video game or a dashboard or something else where the updates are frequently uncorrelated with user actions, Datastar makes a lot of sense. It's a bit like driving a manual transmission.

Delaney is fond of saying that there's no need for htmx when Datastar can technically do everything htmx can [0]. But I think this misses the point of what makes htmx so popular: most people's applications do fit within a largely request/reply paradigm, and using a library that assumes this paradigm is both simpler to implement and simpler to debug. As an htmx maintainer, I often encourage people to even use htmx less than they want to, because the request/reply paradigm is very powerful and the more you can adhere to browser's understanding of it, the more durable and maintainable your website will be [1].

[0] https://data-star.dev/essays/v1_and_beyond

[1] https://unplannedobsolescence.com/blog/less-htmx-is-more/

New comment by alexpetros in "Context engineering is sleeping on the humble hyperlink"

alexpetros — Sat, 25 Oct 2025 05:36:31 +0000

Altering the presentation layer is possible precisely because HTML is a semantic API definition: one broad enough to enable self-description across a variety of domains, but specific enough that those applications can still be re-contextualized according to the user's needs and preferences.

New comment by alexpetros in "Context engineering is sleeping on the humble hyperlink"

alexpetros — Sat, 25 Oct 2025 05:31:33 +0000

> I worked for a company that was all hateoas. In the formal sense, explicitly structured around the concept, not the sense that html has both data and actions via links, it worked, it was a real product, but it was slow and terrible to develop and debug.

The web is also a real product, one that's (when not bloated with adtech) capable of being fast and easy to develop on. That other people have tried to do HATEOAS and failed to make it nice is part of why it's so useful to acknowledge as valid the one implementation that has wildly succeeded.

New comment by alexpetros in "Context engineering is sleeping on the humble hyperlink"

alexpetros — Sat, 25 Oct 2025 05:25:34 +0000

> HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

Browsers can alter a webpage with your chosen CSS, interactively read webpages out loud to you, or, as is the case with all the new AI browsers, provide LLM powered "answers" about a page's contents. These are all recontextualizations made possible by the universal HATEOAS interface of HTML.

New comment by alexpetros in "Context engineering is sleeping on the humble hyperlink"

alexpetros — Sat, 25 Oct 2025 03:44:27 +0000

> Purists have long claimed that a “truly” RESTful API should be fully self-describing, such that a client can explore and interact with it knowing nothing but an entrypoint in advance, with hyperlinks providing all necessary context to discover and consume additional endpoints.

> This never worked in practice. Building hypertext APIs was too cumbersome and to actually consume APIs a human needed to understand the API structure in a useful manner anyway.

Every time I read one of these comments I feel like DiCaprio's character in Inception going "but we did grow old together." HATEOAS worked phenomenally. Every time you go to a webpage with buttons and links in HTML that describe what the webpage is capable of (its API, if you will), you are doing HATEOAS [0]. That this interface can be consumed by both a user (via the browser) and a web scraper (via some other program) is the foundation of modern web infrastructure.

It's a little ironic that the explosion of information made possible by HATEOAS happened while the term it self largely got misunderstood, but such is life. Much like reclaiming the proper usage of its close cousin, "REST," using HATEOAS correctly is helpful for properly identifying what made the world's largest hypermedia system successful—useful if you endeavor to design a new one [1].

[0] https://htmx.org/essays/hateoas/

[1] https://unplannedobsolescence.com/blog/why-insist-on-a-word/

New comment by alexpetros in "What Dynamic Typing Is For"

alexpetros — Sun, 19 Oct 2025 04:21:12 +0000

Bonkers but cool! I really appreciate the inclusion of the tree-sitter grammar; I think we should get more used to doing that.

New comment by alexpetros in "What Dynamic Typing Is For"

alexpetros — Sun, 19 Oct 2025 04:18:39 +0000

> Like, you shouldn't be super happy about walking across a desert because your car can't drive on sand. "Look how simple legs are, and they work on sand".

I didn't say I was happy about it—I just said I needed to get across the desert!

New comment by alexpetros in "What Dynamic Typing Is For"

alexpetros — Sun, 19 Oct 2025 04:10:10 +0000

I have typically understood the "Sufficiently Smart Compiler" to be one that can arrive at the platonic performance ideal of some procedure, regardless of how the steps in that procedure are actually expressed (as long as they are technically correct). This is probably impossible.

What I'm proposing is quite a bit more reasonable—so reasonable that versions of it exist in various ecosystems. I just think they can be better and am essentially thinking out loud about how I'd like that to work.

New comment by alexpetros in "What Dynamic Typing Is For"

alexpetros — Sun, 19 Oct 2025 04:00:22 +0000

Just fixed it. Nice catch, thank you!

Drupal Ajax is now powered by Htmx

alexpetros — Sat, 13 Sep 2025 20:13:45 +0000

Article URL: https://www.drupal.org/node/3539472

Comments URL: https://news.ycombinator.com/item?id=45234969

Points: 4

# Comments: 0

New comment by alexpetros in "Default styles for h1 elements are changing"

alexpetros — Fri, 11 Apr 2025 04:20:43 +0000

I'd love the article to clarify this, because it stuck out to me as well. But as you pointed out, I think that's what they meant: the lighthouse warning is called "H1UserAgentFontSizeInSection"

New comment by alexpetros in "Less Htmx Is More"

alexpetros — Tue, 08 Apr 2025 10:11:12 +0000

Hi, author here. The full quote is: "In my opinion, most websites should be using htmx for either:", and then I list two cases where I think htmx is appropriate.

In context, it's clear that I'm not saying "everyone should use htmx," but rather "if you are using htmx, here is how I recommend you do it."

As for the shiny object concern, I have a talk (which you can also find on this blog) called "Building the Hundred-Year Web Service", that dives into that question.