Also, not immediately relevant to your current issue but something that might be worth considering for the future: using the htmx websocket extension, you can basically implement a streaming HTML approach (example using Kitten: https://ar.al/2024/03/08/streaming-html/) where you can just stream errors to the page as they happen.
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 :)
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.
Teste seit heute die #UnifiedPush Version von #Molly (Signal Fork). Benachrichtigung über neue Nachrichten erfolgt via #ntfy. Bereits nach einem Tag Test lässt sich sagen: Akku-Verbrauch ist geringer als mit #WebSocket bei Signal.
Right, #idiomorph¹ is now integrated into #Kitten² and enjoys first-class support via the <page> tag like #htmx itself, the htmx #WebSocket extension, Alpine.js, and Water semantic #CSS library.
It’s auto-loaded for you if you expose onConnect() handlers in your pages when using the new #StreamingHTML workflow.
(You must still manually add htmx-swap-oob='morph' to elements you want to morph. I might add syntactic sugar for this later.)
🧵 …is the above based on the #WebSocket here? If so, it would certainly be something cool (pardon my ignorance). Do any of you know this and already use it?
Very excited about the latest feature/workflow I’m adding to Kitten. I call it… 🥁
✨ Streaming HTML ✨
Implement back-end functionality and stream HTML updates to the client without writing any front-end JavaScript.
Just give your forms names and listen for them in an onConnect() handler you export from your page. Kitten handles everything else – setting up a WebSocket route for you, mapping triggers to events, etc. – thanks to Kitten + #htmx magic 🪄
Weird. Trying to connect a Javascript websocket client to a Python-Tornado websocket server. The websocket is closed as soon as the connection is established, but I can't tell which side is the culprit or why it's happening.
I want to build something and I need to say my plans out loud, but I don't have any friends let alone any that use #Mastodon or #JavaScript so I'm just gonna info dump here:
In 2023 the state of the #websocket api in browsers is silly af, you can't set headers on the initial connection but you can kind of set one so of course it's abused.
K8s is basically using the subprotocol header to smuggle auth tokens and I love it.
Of course people say "just send auth in a web socket frame" ignoring the prior art of everything else being request/response including preexisting auth solutions.
Most people seem to embed auth tokens in a path param.
@sos#Boost is the worst piece of library I have ever seen.
I once wanted to make a teeny tiny tool that interfaced with a remote #WebSocket#API. And since I'm familiar with it, I decided to write it in C++. When looking for a library that can do #WebSockets and #JSON everyone recommended Boost.
Yeah, I had to download 180 MB of source code(!) and spend several minutes building the damn thing just to integrate it into my single file program. It was so convoluted and complicated to use that I just gave up.
On top of that the only promising part of Boost that I was actually interested in, Boost.UI, was removed from it years ago. Thanks for nothing.
The load time for the timelines bothers me; it's still occasionally timing out just loading 20 toots from two servers. I feel like introducing a #webSocket is my only choice, but I don't like the idea of adding client-side rendering.
Right now, when you visit schizo.social/timelines/home the server fetches from the API before rendering the page using @enhance_dev
I like that the page comes down populated with content so there's no further delay, but there's still a significant delay from waiting on mastodon, so it kinda defeats the purpose.
I could use enhance-element to render the toots on the client instead; either by making an #async#API request, or with a #WebSocket.
B) send the user an empty shell. have the client establish a #webSocket connection. build a #backend#queue of #API calls to make. process the queue retrying as necessary. insert results into a backend #database. Update the client with the socket connection.
I've already hit #AWS#Lambda's default 5s timeout fetching just two #mastodon timelines with https://schizo.social. I'm going to need a more clever solution for making multiple API requests to build a single page. Maybe prefetching, maybe spawning a background process and updating the UI via a #webSocket when they complete? I'm trying to keep it as client-side #javaScript free as I can, but waiting on multiple masto servers just isn't going to work...