Podfox; Functional HTML; httpok

Whether you’re chasing containers, remixing HTML, or debugging APIs, this web-themed Drop’s got the tools you need to make quick work of your tasks at hand.

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop using Ollama + Qwen 3 and a custom prompt.)

• Podfox enables browsing into containerized environments without port forwarding by leveraging rootless Podman and a SOCKS proxy (https://val.packett.cool/blog/podfox/)
• Dan Abramov’s “Functional HTML” reimagines HTML with modern programming concepts, proposing a JSON-based markup that supports custom tags, async functions, and client-server references (https://overreacted.io/functional-html/)
• httpok is a lightweight HTTP client built with Tauri and SvelteKit that lets users test requests in a code editor with formatted responses and easy setup (https://github.com/iondodon/httpok)

Podfox: Browse Containers Directly, No Ports Needed

Podfox (CB) calls itself the “world’s first container-aware browser” with a bit of a wink. It’s not actually a modified browser. Instead, it’s clever tooling that lets you browse into containerized environments without hassle.

The problem it solves? That annoying moment when you’re running multiple containerized projects locally and they fight over the same ports. Imagine two projects both wanting to show RabbitMQ’s (that’s their example; for me this is a recurring Redpanda situation) web interface on the same port—only one wins unless you manually juggle port settings. Podfox’s mission is to eliminate port forwarding altogether.

The magic happens through modern container networking, especially with rootless Podman. Unlike old-school Docker setups, rootless Podman uses Linux namespaces to keep networking isolated. It creates a single network namespace called “rootless-netns” where containers connect through virtual ethernet pairs. You can join this namespace using podman unshare --rootless-netns, which moves your process into the container’s network world, letting you talk directly to containers without port forwarding.

Podfox itself is a SOCKS proxy written in Rust. It sits on your host machine but can step into Podman’s network namespace to chat with containers. It understands addresses like <container>.<network>.podman, finds the right gateway, and resolves container addresses through DNS queries inside the namespace. This gives you access to any container’s web services through a virtual .podman domain—no port exposure needed.

Setting up Firefox to work with Podfox is straightforward using a Proxy Auto-Configuration (PAC) file. This simple JavaScript function tells Firefox to send all .podman traffic through the Podfox proxy while letting everything else go directly. No browser extension required—just a few clicks in Firefox’s network settings.

The article also touches on broader container development trends, mentioning tools like Tilt and Microsoft’s Development Container Specification. The author prefers bringing their entire command-line environment (shell, editor, tools) into each container by mounting Homebrew and adjusting PATH variables. This lets them use all their tools inside any container regardless of its base image—creating a flexible, throw-away development setup without installing things multiple times.

To make container launching easier, the author created a script called Podchamp that reads project configs to run or connect to containers consistently. It even works with terminal emulators like Ptyxis to maintain container awareness when opening new tabs.

This is a really clever solution to a true annoyance, and I feel a bit daft for not stumbling into it myself.

Functional HTML: Reimagining HTML for Modern Web Development

Dan Abramov’s “Functional HTML” explores what HTML might look like if redesigned today with modern programming concepts in mind. Taking inspiration from React Server Components (RSC), the essay walks through a thought experiment about evolving HTML’s capabilities.

Starting with a simple paragraph tag, Abramov asks what would come next if we were building HTML from scratch. His answer? The ability to create custom tags using JavaScript functions. For instance, you could make a <Greeting> tag backed by a function that returns a paragraph. When preparing the page, the server would run these functions and convert them to standard HTML.

The essay then considers how attributes could work. Rather than just strings, what if you could pass complex objects to your tags? During processing, these objects could be preserved as structured JSON data instead of being flattened to strings, making your markup more powerful.

For data fetching, Abramov suggests allowing async function tags that can pull information from databases or files. The server would wait for these results before sending the final output, maintaining the clean abstraction of components that fetch their own data.

When it comes to events, the traditional approach of string-based handlers (like onClick="addLike()") isn’t ideal. Instead, Abramov proposes “references” as a solution. These are client references pointing to browser code and server references directing to API endpoints. These references become first-class citizens in the JSON-based markup.

The concept of “Client Tags” comes next. They’re components meant to run in the browser rather than on the server. This enables hybrid rendering: prerender as much as possible on the server for speed, while keeping interactive elements that activate in the browser.

To handle multiple async components without blocking the entire page, Abramov suggests streaming the markup “outside-in” with placeholders for content that’s still loading. As data arrives, the server fills in these gaps. A <Suspense> primitive would provide a built-in way to show loading states while waiting for data.

The essay concludes by discussing how this JSON-based markup supports better caching, component reuse, and separation of static and dynamic content. The result is a vision of HTML as a truly programmable language where tags can represent both server and client logic, with clear boundaries between markup and code.

The “rug pull” at the end (that this was really just a big “ad” for RSC) was unexpected, especially since I found the thought experiment super interesting. React is still DOA for me, and I remain unconvinced that server-side rendering has generic merit, but I do believe we’d be in a much better place if the concept of web compoments had come along sooner than it did.

httpok: A Code-Friendly HTTP Client

httpok is a spiffy desktop tool for testing HTTP requests right in a code editor. Think of it as Postman’s lighter, faster cousin that won’t consume all your system resources.

Built with Tauri and SvelteKit, this open-source app lets us write requests in a simple language that looks just like the HTTP requests you’re already familiar with. You can even run multiple requests at once and see all your responses neatly formatted side by side.

Want to check out a JSON response? httpok shows it with fancy formatting and color highlighting.

Getting started is easy. Just grab the download release for your system or build it yourself. Note: you’ll need Node.js and Rust if you’re building from source.

Here’s what a basic request looks like:

GET https://jsonplaceholder.typicode.com/posts/1
Accept: application/json
Authorization: Bearer token123

If you’re tired of heavy API tools and just want something that gets out of your way, httpok might be worth a look.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️