Any Cables Monthly #28: of past and presence
April-May, 2025
This is a yet-another bi-monthly issue of Any Cables Monthly. Sorry, April, but our delivery guarantee is at-most once (a month) 😁
Highlights
The long-awaited AnyCable release with presence tracking support is available everywhere: you can quickly spin up a cable at plus.anycable.io, download an OSS version or go Pro w/ presence tracking for clusters support.
Now, when this big release is out, you may ask—what’s next? Our primary focus for the rest of the year is, first, to incrementally enhance presence-related features (WebHooks, HTTP API, etc.) and, secondly, to bring more ready-made components for building real-time applications (e.g., UI kit and stuff). Speaking of components…
Posts
Simple Declarative Presence for Hotwire apps with AnyCable
Learn more about our Hotwire Presence component that can help you add presence tracking features by just using HTML!
Improving WebSocket performance at Clio
The Clio team shared the story of improving the performance of their real-time features (powered by AnyCable):
What could be done to improve WebSocket performance? We identified three solutions:
Decrease the number of WebSocket messages sent from the frontend to the backend
Scale AnyCable’s servers
Make Clio’s code process WebSocket messages faster.
News
Terminalwire allows you to easily create a CLI interface for your web application (a “thin client”—a term from the past) fully defined on the server (commands, options, etc.). It’s like Hotwire but for CLIs. Under the hood, the command-line tool uses a WebSocket connection and a custom protocol to execute commands. The source code can be used as an example of using async-websocket to create WebSocket clients in Ruby.
Releases 🤖
deepwiki.com/anycable/anycable
Say hello to our new documentation website! This is joke, of course; our new documentation website will be much better. Still, such AI-generated source-to-documentation resources could be useful in learning more about the internals of the project you want to hack with. Don’t hesitate to give it a try!
Frame of history: Comet
Yesterday, we (Team AnyCable) visited the Computer History Museum in Mountain View, CA. It was a great time-traveling experience and a demonstration of how quickly the industry evolved over the last (half-)century (and how small the first iPhone was compared to modern models, even my beloved mini). And it also felt a bit strange; another visitor nailed it, saying: “How strange it is to see the things you actively used in the past now being a part of a history museum collection?”
We don’t have a museum of real-time web yet, even a digital one, but there are definitely good candidates to add to its collection. And the first thing that came to my mind with regards this idea is Comet, an umbrella term for push-style/streaming HTTP communication used in the late 90s and early 00s. It was usually contrasted with a request-response-ish Ajax, a super-hot technology back in the day that is still very much alive today (though since the decline of $.ajax and the rise of fetch, we barely use this legacy term).
As an exhibit to represent Comet in our mythical Real-Time Web Museum, I would pick the original blog post by Alex Russel that introduced the term. I leave you the opportunity to read the blog from the past in its entirety yourself. Here I just want to pull out some quotes and add a few remarks.
…Lacking a better term, I've taken to calling this style of event-driven, server-push data streaming "Comet". It doesn't stand for anything, and I'm not sure that it should.
I don’t know if it’s a coincidence or not, but in the context of Ajax, Comet had a clear (clean?) meaning—both names have been used by popular cleansers since mid-20th century:
Common terminology acts not only as a shortcut in discussions between technical folks, but also as a bridge for those who may not be able to give a technical rundown of exactly how it works… We have a hard problem for which solutions are available (and have been for some time) but no way to communicate about them. Terminology is again the missing link.
We all know that naming things is hard; but this post goes further and discusses the problem of having no good name for a common set of problems or solutions.
The term “Comet” hasn’t become The Term. Today, we use the word “real-time” to describe asynchronous/bi-directional/low-latency communication, and most of the times we use a particular transport name along with it (WebSockets, SSE, WebRTC). We still can’t separate the concept (realtime-ness) from technology.
P.S. Can you count the number of times the term “real-time” used in the Comet blog post?