The original sin wasn't reactivity. It was putting state in the wrong place. Making the client state heavy. It's been downhill since then. Now you need to duplicate state handling between your frontend language and your backend language. Which leads to "isomorphic" backends seeming like a good idea.
`xs` is for personal scale so fjall is fairly overkill performance-wise. marvin_j97's benchmark work and deep dives into different database systems is incredible though. Looking forward to updating to v3.
My understanding is Turbo is more aligned with htmx. Common practice in Turbo are generally patterns of last resort in Datastar.
e.g. Datastar prescribes a single long lived SSE endpoint that owns the state for the currently connected user's view of the world / app, while common practice in Turbo is to have many small endpoints that return a fragment of html when requested by the client.
The preferred pattern addresses your concern about scattered logic: a single long-lived SSE endpoint that "owns" the user's view of the app. That endpoint updates their field of view as appropriate - very much inspired by game dev's immediate mode rendering.
An interesting characteristic of Datastar: it's very opinionated about the shape of your backend but extremely unopinionated about how you implement that shape.
I maintain a Rust-based CLI HTTP server that embeds Nushell. It’s a handy little Swiss-army knife that’s replaced Nginx and Caddy for my personal projects.
You can serve a folder of static assets like this:
The friction Dave describes where changing one param effects all the other params in an animation brought to mind this section of an old Bret Victor talk: https://www.youtube.com/watch?v=a-OyoVcbwWE&t=716s
When I'm working on a remote machine, it's nice to be able to easily pass things back and forth between it and my local laptop. I start a stream on the remote server and use `dumbpipe` to make the stream available on my local laptop.
Or register a local handler for the topic "pasteboard" that puts the contents on my local clipboard. Then, from the remote machine, I can run: `"foo" | .append pasteboard`
Iroh is intriguing. Dumbpipe is magical, and its implementation is easy to understand. I use dumbpipe daily to expose cross-stream (https://github.com/cablehead/xs) stores I run on different servers to my local laptop's `xs` client.
I'm finding I increasingly produce entire changesets without opening an editor: just `claude code`, or my own cobbled-together version of `claude code`, and `git diff` to preview what's happening. For me, the future of these tools isn't "inside" a text editor. If you want to poke around, my “cobbled‑together Claude Code” lives here: https://github.com/cablehead/gpt2099.nu
It's become my go-to tool for handling fiddly refactors. Here’s an example session from a Rust project where I used it to break a single file into a module directory.
> As they should! Building with htmx works a lot better if you play to its strengths. You can send JSON-formatted form bodies, if you really insist. But you shouldn’t!
This excellent essay overlooked a '*':
* unless you are using bash + jq for your backend, in which case, JSON-formatted form bodies are quite reasonable.
This is fantastic. I'd love to live in a world populated by tens of thousands of incredible, practical projects like Atuin, whose maintainers earn a good living. Best of luck, Ellie!
Yeah, I'm finding it difficult to create a prompt which doesn't result in Error: 400 Your request was rejected as a result of our safety system. Your prompt may contain text that is not allowed by our safety system.
Even when I don't think I'm attempting particular weird instructions!