I made an update to the #clue app that allows you to see the description rendered as markdown.
(I've been using markdown the whole time intending to do this.)
There's a button "View Markdown" that swap the textarea with rendered markdown (html).
And then I just re-use the "Reset Post" button to go back.
I did this with #htmx which I haven't used before. I don't love it.
I don't hate it. I definitely could have just used axios (or fetch) and some javascript glue.
I've spent a few days playing around with #HTMX, and I'd like some insights from people who are using it in production. Doesn't need to be a paid project, but more than just "my pet experiment".
What are you using it for?
Like, to me it feels as if either the backend needs to be really tailored to HTMX, with HTML fragments and custom headers and stuff, or you need to start writing non-trivial amounts of JS in the frontend for anything but the most basic tasks.
We discuss all things DjangoCon US 2023, our new favorite Southern delicacy, tech conference tips, and just how much coffee is too much (hint: the limit does not exist 😉)!
Subscribe wherever you get your podcasts, check out https://djangobrew.com for show notes, and follow us here for updates.
Tired of JavaScript bloat? Don't miss Chris Tankersley's talk on unlocking the power of minimalistic and efficient web development with htmx and Alpine.js. 🏔️ php[tek] tickets are still available! https://tek.phparch.com/#phptek#webdev#javascript#htmx#AlpineJS
I’ve also updated the readme with instructions on how to run Draw Together yourself (you could have it up and running locally in under a minute by installing Kitten, cloning the repository, and running the kitten command) and links to where you can learn more about the Streaming HTML magic in Kitten that means that the whole app is ~60 lines of code :)
Minor Kitten¹ update: Even if your page routes now return nothing (e.g., null, undefined, empty string), a proper page will be rendered that includes the development-time WebSocket that powers hot reloads.
A fifteen-second demo of how you can create a toast message in 42 lines of code¹ without writing any client-side JavaScript using Streaming HTML² in Kitten³.
Update: I forgot to make the toast message div into an aria-live region so toast messages are read out when they arrive for people who use screen readers.
You can now add settle, swap, etc., attributes to Kitten morphs using Kitten’s morph syntactic sugar¹
e.g.,
<div morph='settle:2s'>
Is syntactic sugar for:
<div hx-swap-oob='morph settle:2s'>
Morphs are an important part of Kitten’s Streaming HTML workflow which you can learn more about in the attached video (https://vimeo.com/920601063) and this blog post:
So many fun things to learn. Obviously working with audio data, speech to text, but also LLMs from AssemblyAI, #FastAPI, Beanie, #MongoDB, #HTMX, #Python, and plenty more. cc @mkennedy
htmx 2 is pre-release but so is Kitten¹ so what better time than the present to upgrade?
As of today, Kitten runs my fork of htmx 2 & htmx-ws which, thanks to Denis and Jeff², include features/fixes that aren’t in htmx 2 yet. Once they are, I’ll move to the official version.
Been slowly tinkering on a Litestar app I'm building just for the hell of it. My local amateur soccer league could really use a website, and I could also stand to learn a new web framework. (I mean, why not?)
While I've been plugging away at it (over-engineering and all), I decided to continue building in public.
Lots of fun stuff in here, but a pretty good "real world" use case for the PyHAT stack (htmx/Tailwind).
Kitten update: session IDs now available in the request.session objects you get in your routes.
Kitten lets you persist arbitrary data in session objects to make it easy to work with sessions but you cannot store custom objects (instances of custom classes) as Kitten’s default database is not aware of custom classes in your application. Now, keyed to the session id, you can store custom objects in your app’s own database.
(The use case for this is pretty neat: keep your interface state in custom state class instances persisted in session objects and, using the Streaming HTML workflow*, send back pieces of the interface that take those state objects as their only prop. Quite a neat separation of concerns and state is maintained only on the server in those objects.)