ndyg

if you like bash web apps, you'll love https://github.com/cablehead/http-sh

Something I find myself saying a lot, Nushell is a better `jq` than `jq`

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.

I'm using fjall v2 in the Rust event streaming store, cross.stream (`xs`) https://github.com/cablehead/xs

`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.

Fjall

https://github.com/fjall-rs/fjall

If you like lo-fi ways to attach cli commands to http end-points, you may also like:

- https://github.com/cablehead/http-nu or for POSIX - https://github.com/cablehead/http-sh

astroturf campaign?

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.

I've a tutorial that demonstrates this with Nushell as the backend: https://datastar-todomvc.cross.stream

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'm curious, what do you think is missing from Caddy that has you looking for something new?

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:

http-nu :3021 '{|req| .static "www" $req.path}'

https://github.com/cablehead/http-nu

The approach you describe requires host to have an open ssh port you can access. quic + nat hole punching works around 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

A basic use case, to tie it back to the topic :)

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.

```

# remote

xs serve ./store --expose :3001 ; dumbpipe listen-tcp --host 127.0.0.1:3001

# local

dumbpipe connect-tcp --addr 127.0.0.1:3001 <ticket>

$env.XS_ADDR ":3001" ; .cat

```

I can then do things like:

```

# local

cat local.file | .append local.file

# remote

.head local.file | .cas

```

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

Noting Codebuff is manicode renamed.

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.

https://gist.github.com/cablehead/f235d61d3b646f2ec1794f656e...

Notice how it can run tests, see the compile error, and then iterate until the task is done? Really impressive.

For reference, this task used ~100 credits

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!

For anyone else immediately caught out by the separation of http1 and http2 builders in Hyper v1: auto negotiation is still available via hyper-utils:

https://github.com/hyperium/hyper-util/blob/v0.1.0/src/serve...

This is great. Thank you for all your hard work Sean!

I'm not sure if it's still the case since we moved away a few years ago, but the 24th St BART escalator used to be in a constant repair loop. It would get fixed for a short period, operate for about a month, and then go back to being out of service. Made me question if a similar scheme was in operation.

Gosh, thanks for this explanation. This will help as my eyes protest the assault of '&'s.

Cars are traveling at 'freeway speeds' in the video, but they are breaking the law. The Bay Bridge is signed for 50 MPH. This issue is endemic. When I lived in the Bay area, I'd set cruise control to 60MPH on the Bay Bridge, and would be practically run off the road by traffic speeding by.

I just checked in on this and noticed that it seemed like the FAQ language changed as well. I can't find the old wording anymore, and the new wording has done a 180

Subjectively, this seems like a big deal. I was fortunate to buy a small condo before the last round of rocketing housing costs. My low property tax bill definitely influences the calculus whether to sell. If the intent for current CA property tax rules were to reduce inequality, I think they have the opposite effect.

This is something I hacked together over the last 2 months to try a articulate a bunch of pretty orthogonal ideas I've been bouncing around over the years.

* The command line is amazing for fluidly exploring a data set or an automation task but an adhoc session can quickly spiral to the point it's no longer discernible or reusable. Is there a way you can keep that fluidity and instant feedback but introduce some structure to make things reusable? Also, to be able to return to an adhoc session and pick up where you left off?

* 'Use small tools' gets a lot of lip service, but systems are almost exclusively composed in monolithic ecosystems (for example, Golang, Python, Node). What would it look like to actually build a system using small tools? In my experiments it quickly gets unruly. Does it look better if we have a better way to compose shell scripts?

* Have you ever produced an interesting result in a shell session and thought, 'I just want this to run forever now' Is there a way to seamlessly take these adhoc sessions and then run them redundantly and robustly?

You’re quoting the marketing copy of Telsa’s unreleased full selling driving capability.

Tesla have sold people that the hardware they buy now will be capable of this in the future, but not now.

What does libswarm offer over unix sockets?

Is the idea for the project to be a rallying point to normalize protocols for different services that already talk over unix sockets?