Yea.
Any particular thing you’d say is beyond terrible - in matter of concepts not just the visuals?
Actual library is fairly cool if you asked me - concept wise to learn a thing or two about how web works
I wonder if people will start writing like this over time. “Order the fries with the burger. They go well together” becoming “the fries amplify the burger. One order. Together. Not separate — united ”. Haha man. The kids will think it’s normal and we’ll sit here like crotchety old men.
"This man took a burger, and then added some fries to it. He tasted it, and realised that this was what was missing from his life. He took a fry, and dunk it into the sauce, and then took a bite from the burger. People around him started looking. They couldn't believe it looked so tasty."
"If you take a fry, dunk it into a sauce container, add a burger, take a bite, chew it all together, and then take a big gulp, you will enjoy a solid meal!"
I hate whoever's come up with that shit. It's so annoying and it's friggin everywhere now.
I think this page is communicating something, but it's doing it in a very confusing and elliptical way. The page seems to assume the reader is highly familiar with both "Htmx" and "Datastar SSE", and understands implicitly that this project is (I gather) some kind of complement to using them.
This is a great example of one of the current failure modes of coding agents (which were almost certainly used here): the creator of this project probably described the project in these terms to the agent. Something like:
> I want to make a Javascript library that works like Htmx or Datastar SSE, enabling a web developer to add well-known behaviors to a page just by adding HTML attributes. This library will be for the cases those libraries don't cover: triggering purely-local state changes in the state of [elements? web components? not sure]; where because these state changes get persisted to the DOM in some way or another, they are visible to, the state these behavior-attributes mutate can be referenced by Htmx/Datastar/etc in their behavior-attribute DSLs.
Then, either because the agent is already briefed in these terms — or because the agent has then gone on to write all the code for this library in the same conversation, and so has that code in its context — the result is that the agent, when it moves on to the "generate docs and README" step, treats all this as assumed shared context for those docs, since (from the agent's perspective) the docs and README exist "in" the conversation "downstream" of the project brief and code; and, from its original base-model training, the model knows that things introduced early in a conversation shouldn't be re-introduced later on in the same conversation, but rather should be succinctly referenced.
(My hypothesis, that I haven't yet tested, is that you can work around this flaw by starting a fresh conversation before asking the model to write docs. The model should see info that enters the context through e.g. "read a file" tool-call responses differently than it sees things you or it "say", not treating that info as "real" conversation turns but more like e.g. source-code excerpts in a blog post, where the learned base-model expectation would be that everything that appears in the excerpted figure will be re-explained in plain language in following prose.)
But, of course, this is still a flaw in current models, and the "right" solution is still for the model providers to train models to be able to conceptualize of multiple "conversational reference graphs" co-occurring within the context, and compartmentalize linguistic/semantic referencing on a per-graph basis; such that top-level prose and inline code excerpted for explanation both exist in the default "internal" reference graph, while code and docs generated to be written into a codebase through tool-calls exist in a separate "external" reference graph.
I use datastar daily so yes there’s a lot of this contexts in my reasoning and conversations.
It’s also a project that kind of focuses on how they do things and how they work internally.
Maybe I should try to approach docs in non-htmx / Datastar user context - will think about it
10 comments
[ 0.21 ms ] story [ 6.0 ms ] thread"If you take a fry, dunk it into a sauce container, add a burger, take a bite, chew it all together, and then take a big gulp, you will enjoy a solid meal!"
I hate whoever's come up with that shit. It's so annoying and it's friggin everywhere now.
This is a great example of one of the current failure modes of coding agents (which were almost certainly used here): the creator of this project probably described the project in these terms to the agent. Something like:
> I want to make a Javascript library that works like Htmx or Datastar SSE, enabling a web developer to add well-known behaviors to a page just by adding HTML attributes. This library will be for the cases those libraries don't cover: triggering purely-local state changes in the state of [elements? web components? not sure]; where because these state changes get persisted to the DOM in some way or another, they are visible to, the state these behavior-attributes mutate can be referenced by Htmx/Datastar/etc in their behavior-attribute DSLs.
Then, either because the agent is already briefed in these terms — or because the agent has then gone on to write all the code for this library in the same conversation, and so has that code in its context — the result is that the agent, when it moves on to the "generate docs and README" step, treats all this as assumed shared context for those docs, since (from the agent's perspective) the docs and README exist "in" the conversation "downstream" of the project brief and code; and, from its original base-model training, the model knows that things introduced early in a conversation shouldn't be re-introduced later on in the same conversation, but rather should be succinctly referenced.
(My hypothesis, that I haven't yet tested, is that you can work around this flaw by starting a fresh conversation before asking the model to write docs. The model should see info that enters the context through e.g. "read a file" tool-call responses differently than it sees things you or it "say", not treating that info as "real" conversation turns but more like e.g. source-code excerpts in a blog post, where the learned base-model expectation would be that everything that appears in the excerpted figure will be re-explained in plain language in following prose.)
But, of course, this is still a flaw in current models, and the "right" solution is still for the model providers to train models to be able to conceptualize of multiple "conversational reference graphs" co-occurring within the context, and compartmentalize linguistic/semantic referencing on a per-graph basis; such that top-level prose and inline code excerpted for explanation both exist in the default "internal" reference graph, while code and docs generated to be written into a codebase through tool-calls exist in a separate "external" reference graph.
Maybe I should try to approach docs in non-htmx / Datastar user context - will think about it