Sanity’s response below is a worthwhile read for devs and product folks working in this space. CMS platforms were solutions to real publishing workflow challenges; those still exist when you try to move away from a CMS. The fix is flexible structure + better separation of content from presentation.
When I wrote the post below, I had not yet experienced the paradigm shift from chatbots to coding agents. Now I can say: it's not only more efficient to direct the agent to compose software for an analytical task—this is actually the more adaptive, forward-leaning way of using the technology.
Browser/OS behavior may vary with unquoted font family names. Try MDN’s recommended formatting to rule this out: developer.mozilla.org/en-US/docs/W...
This is why, even with the state of the art, we’re not ready for uncontrolled deployment of AI agents in business operations.
The script I can debug once I have a starting point, but if the chatbot’s analysis goes off sideways, there no getting it back on track.
I would definitely say that GPT-5 is showing improvement in reasoning tasks over previous models, but for now it is still more efficient for me to ask chat to help me write a script to do an analysis than to just ask chat to do the analysis.
I’m curious about “Data in JS, so no Alpine.js” With Alpine, data does not need to be included in markup; you can inject data into Alpine’s scope from external JS. This makes your template reactive without mutating data in the global scope. Does your use case require the global scope to be reactive?
(One way to get at what’s missing here would be to point out that the AI system is not “conversing” in the same sense that humans converse: human conversation is embedded in and derives its meanings from “forms of life” — W’s term for the shared, intersubjective background of language games.)
I would classify the above thesis as the “linguistic pragmatist” framing, with reference to later Wittgenstein and a footnote to the Turing test (“imitation game”) and its parallels to W’s “language games.”
That’s ChatGPT 5 (model: auto) btw
Against: “If ‘knowing’ is tied to having intentional states, embodied experience, or cultural participation, the thesis fails because AI’s ‘pragmatic knowledge’ is a simulation, not a lived competence.”
For: “If ‘knowing’ pragmatics is defined purely behaviorally — as successful, contextually appropriate use of language in interaction — the thesis holds.”
I asked ChatGPT to discuss this thesis, and it made a few good points:
Thesis: An AI system can be said to know the pragmatics of a language in which it is conversing in the same sense that its human interlocutors can be said to know the pragmatics of a language in which they are conversing.
One way out of the “AI is an evolutionary leap” vs. “AI is dumb/bad” dichotomy is to start to collect various possible rhetorical framings and think through their implications and motivations. Here’s a helpful starter on what I’d call the semiotic/postmodernist framing:
I came across a thread stating “a chatbot does not and cannot know anything” - Intuitively correct, but I would follow up with: Would we ever say that a system can know things? Do we only speak of knowledge as something in the mind of a single human being?
AI as supercharged echo chamber = late-stage social media dystopia
Seems like we're in for a real shift in the economics of the web and the value of content creation: techcrunch.com/2025/07/01/c...
This thread raises an interesting and important point about how industry best practices diverge from what is common in the social media wilds with regard to the use of images as text. Just one example of why context matters in web accessibility and one set of universal guidelines will not suffice.
(5/5) Imagine Figma can be the visual editor for your CMS, and now suppose it's generating JSX that can also be manipulated as code; then on top of that you have the content layer integrated into the same platform – now you have your whole team working in the same integrated environment. Powerful!
(4/5) And a big YES to this: "Figma and Payload together can and will solve a problem that’s been bugging me (and probably all of you) for years ... Designers create in Figma, then devs recreate in code, then content teams struggle to maintain it all. It’s inefficient and frustrating."
(3/5) The announcement of Payload's acquisition by Figma gives Payload (or whatever it is to become) a much greater shot at relevance. I would love to see the future of CMS be something that is not WordPress – but also something that is just enough like WordPress to convert the masses.
(2/5) I have seen a number of alternative CMS products come and go over the last few years. While Payload looked impressive, I was concerned that it might be too niche and might not win enough of a following to gain traction in this product space.
(1/5) In researching next-gen CMS platforms last year, I was very interested in Payload as a product that was trying to incorporate all of the out-of-the-box capabilities you get with WordPress, but with an attractive UI and a modern TypeScript/React/Next.js stack under the hood.
Headless WordPress?
Turso's decision to build their platform on an open-source fork of SQLite, called libSQL, is somewhat reassuring. Supposing that other services build off of libSQL in the future, the existence of standard drivers in JS/TS and another languages should remove barriers to switching providers.
One concern I've had about choosing any cloud database provider has been vendor lock and the effort required to migrate data to another service if the provider exists the market or becomes too expensive.
The dream of every frontend dev is not to have to think too much about infrastructure. I've been trying out AstroDB + Turso as a database solution for basic content management, and experience has been great so far: astro.build/blog/astro-d...
Not a book, but I'd say MDN's JavaScript resources are the most comprehensive and up-to-date. Includes introductory tutorials and an expansive section on JS frameworks and libraries: developer.mozilla.org/en-US/docs/W...
