tjansen

Didn't have much time to try it this morning, but so far the Herdr app looks fantastic. I am already using herdr on the console to control Claude on my Mac Mini, but having to log in again after closing my Macbook was always annoying. And I missed seeing the code diffs and being able to commit changes in VSCode, which is still my preferred development environment today (with the Claude VSCode extension).

But Herdr app addresses both issues. I don't need to reconnect, and it has a diff tool that allows me to review and commit. Looking forward to work with it!

I would recommend Downread.com, but that’s because I am the author. Fully on the web, no self-hosting, forever free for everyone who signs up as long as the current servers can handle it. Works well as PWA (apps coming soon).

The most common browser-based readers are Inoreader and Feedly. Inoreader has more features, but I prefer Feedly’s UI.

I don't read Phrack, but I tested your feed.xml feed. I think there are some challenges: - posting lots of posts all with the same pubDate can confuse readers. Not sure all will handle that.

- wrapping the text in <pre> is probably the only way to handle that fixed-width-font magazine, but I am having trouble reading it with my default feed settings. I need to scroll horizontally to read it.

- Please add a square feed icon to the feed. Makes it look nicer and easier to recognize in a long list of feeds.

> is it really me that is producing?

You can ask the same question when you lead a team of developers. To me, it doesn't really matter what or who is producing. Using whatever tools, I create something that did not exist before.

> you will be at the exact same spot you are right now

I don't think so. I am getting more efficient at delegating things.

> may be easily outraced by someone else who just as well prompts an ai

True. But there is no way to prevent that.

> what is your metric for "productivity" exactly?

Releasing a major project in about a year (downread.com) while having several ones in the pipeline. Far more than I was able to do in previous years with similar time commitment.

> that vaguely understands the problem

This is not my experience at all (mostly with Opus). It can understand and explain to me even complex programs. And then edit them. Usually it solves tasks on the first attempt, if the instructions were precise enough (and with every new release, Opus needs less and less handholding / context).

> do you get your llm to bring a novel solution to a problem > that hasnt been explored before?

No. But if I explain a novel solution to the LLM, it can create a complete implementation far faster than I ever could.

> do you even learn anything new

Usually not, unless I work in an area I have no experience in (like setting up an iOS app). But that's not even the point. I don't do it to learn; I do it to build products that either don't exist yet, or are better than the existing ones. These projects are no rocket science, but they are very labour-intensive.

Interesting idea (on a web site that is hard to use).

AI taught me that I don't really like programming per se. I was very good at it, I believe, but it's never been what I really wanted. I want to build stuff. AI let's me do it faster than ever before. But more important: it takes care of the boring, tedious stuff that caused me to abandon far more projects than I completed.

So far, 2026 has been my most productive year, by great margin. Things that I wouldn't have even dreamed of starting became possible. And the pace keeps accelerating.

Oh, wow, the Falcon was so cool when it came out, especially the 56k DSP. Back then computer magazines were quite technical, and there were articles about the 56k and how to program it. I remember seeing the Falcon at some local Atari trade fair and desperately wanted to have it. Unfortunately it was way way too expensive for me as a teenager. And even then, Atari fans dreamed that the Falcon would take off, and the announced MultiTOS would bring people back. But deep down everybody knew that it didn’t have a chance against PCs.

Damn. I've loved Bob and his writings ever since I read Accidental Empires as a kid. He went through some crazy shit over the last few years (lost his house, almost blind). And when he started blogging again this year (https://www.cringely.com/2026/05/27/where-the-heck-have-i-be...), the stories got even worse (lost his son, heart attack, stroke). RIP.

There are services that do this, like OpenRSS, but I don't think they are intended for websites offering a RSS feed. You should do that with whatever software you use to create the HTML.

Typically only with whitelisted URLs/hosts.

Well, it's downread.com, still in beta, but very usable and nearly feature-complete. Not sure what else to say. I strive to make it better than the competition :) HTML/Styles is one aspect. I am not aware of any other RSS reader that supports styles in articles as well. Downread even supports CSS, CMS-specific CSS classes, Tailwind, and custom styling for difficult, popular feeds.

Regarding the habit... I don't know, doing it forever. Whenever I have a moment to read, I open it. Before Downread, it was Feedly, and before Feedly, Google Reader, and before Google Reader, I don't know, some desktop app. It's pretty much the only way I read, and I read a lot.

As the author of an RSS reader, I would agree with most of that article, except the HTML / Styling section. It is full of misleading information.

1. You can use CSS, but expect that most readers will completely ignore it. Even widespread ones, like Feedly. Those that do support it will only offer a small subset, like text styles. No layout styles (positioning or flex-layouts), often not even colors. If you want to try the capabilities of your reader, this is a test feed: https://test-rss.downread.com/styles.rss.xml

2. Don't just prefer inline CSS, use it, because any sane RSS reader will filter <style>.

3. Yes, semantic elements will generally work. And not only those listed: also things like <table>, <figure>, and sometimes <aside>.

4. Agree about JavaScript. Don't use it.

5. Decent readers will support <video> and <audio>. But <iframes> are even better, as long as you use common providers, especially YouTube. Embeds from X, Instagram, and Facebook are also relatively widely supported.

6. Agree about forms. At best, they will be used as rendering hints, but forms won't work.

I don't get it. You don't declare any RSS feed on your site. Do you mean you consume RSS feeds to create the HTML?

I had a similar experience with my landing page for downread.com. I don't know whether the design looks vibe-coded, but I don't think anyone would put that much effort into a hand-coded homepage: the landing page (as well as the feature page) uses interactive, partially animated 'screenshots' that simulate aspects of the app. All buttons either do something or open a pop-up explaining what the button does.

Thanks for the feedback. I’m already working on an interactive landing page but it’s not ready yet.

I’ve always used RSS readers for this. It’s just the most efficient way to read. [shameless plug coming] In the last year I have developed an RSS reader optimised for people like me who read MANY feeds, which supports things like auto-expiration of old posts if you can’t keep up. And it’s free. https://feeds.downread.com/signup?i=hn-c-32513232

It looks like it solves a problem I have, but how does it do that? Just disable sleep? Or does it actually detect activity (and if yes, how and which apps are supported)?

Interesting. I tried it with two real-life tasks that I usually would use Claude Code for (I prefer using it with the VSCode extension, not CLI).

1. First thing I noticed was the lack of autocompletion when entering @<filename> (or #<filename> with Github Copilot). Makes it really difficult to talk about files, since I don't always remember the full name. Had to go to VSCode to find it.

2. I assume, even though I selected Claude, it doesn't read CLAUDE.md? Does it have an equivalent? It had trouble navigating my repository. Pointing it to CLAUDE.md in the prompt fixed it, though.

3. For the second task, it created a plan (without me asking for one) and let me approve it. But then it marked the whole plan completed in the first few seconds, except the last item, before it wrote a single line of code. Or execute anything (the plan included what to edit, and what to test/run).

4. The generated code was fine for both tasks. The first one had about 20 changed lines, and the second ~100 lines + 300 lines of tests. It was very thorough in testing its changes, like the latest versions of Claude Code.

5. The bad part: implementing the plan for the 100 LOC change took about 13 minutes (unfortunately it doesn't show the exact duration when finished; it was at >100 tasks and over 770s). To compare, I stashed the changes, tried it on Claude Code with the same prompt, default model (Opus 5), auto mode. It did not create a plan and finished the task in 12 minutes. Claude's code was a bit simpler, and I prefer it over Bullet's by a small margin.

I agree that it makes sense on that page. But only because the rendering of the page is completely under the control of the author, and the page shows only that one page. It's different if the text is rendered by an RSS reader in a different context. You don't know the font, color, or text weight it is rendered with in an RSS reader (which also depends on the context, like unread posts being bold). Imagine the same title in a list of post titles. I think it would stick out and make the list much harder to read.

> We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles?

1. Because there are things you can obviously not put in a headline. Like a large image, a YouTube video, or a paragraph. Defining an HTML subset would make it somewhat usable. But letting each consumer of the Atom feed decide which subset they support will make such a title look bad on at least those renderers that don't support the same subset. No renderer can allow it completely (<script>...). HTML sanitation/injection becomes a much bigger problem when it's not limited to a text body that can be relatively easily sandboxed.

2. If you allow every feed to define its own font style or even color, that makes a list of posts look like a 2005 MySpace page. :)

It is producing bad UIs. Renderers can't really render it as plain text, as they might lose a part of the meaning. But they also can't really allow it because it might make their output look like trash. In the end, that would force renderers to develop complex heuristics of which elements and styles to allow, which to modify (do your HTML titles support dark mode? accessibility?), and which to filter out.

3. I don't see the practical value of having <code> in a headline. If it shouldn't be rendered in a different way for obvious reasons, and XML is not designed for human consumption, what is it good for? Who is the consumer of the <code> tag? AI?

I guess it's like you can't transform XML with JSON-T :)

Seriously, yes, the really old XSLT does not support JSON. But these days it is much easier to find tools that read or write JSON than to find decent XML support.

I agree that Atom is easier to use and better defined in some ways. But why on earth would you want to put unrestricted HTML in the title in the first place? How is a reader supposed to handle that? It's just a weird thing to allow.

In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt away.

In my humble opinion, JSON feed (https://www.jsonfeed.org/version/1.1/) is the most practical format. By a small margin, but still...

- it's really simple and doesn't use XML

- it doesn't allow stupid things like HTML in titles (which I guarantee >50% of all implementations can't handle correctly)

- JSON Feed allows feeds to have a <favicon> and a (square!) <icon>, which is a very practical thing for readers. You can use the <favicon> in lists of feeds, and the <icon> to present a single feed. Atom has a small square icon and a <logo> which is supposed to use a 2:1 aspect ratio. 2:1 is completely useless. No site has a logo in 2:1. It's also useless for most full-name logos, like 'New York Times'. (RSS is, of course, even worse; it doesn't even recommend an aspect ratio, practically guaranteeing that RSS readers can look bad)

You can see that JSON feed has been designed from a feed consumer's point of view: what does an RSS reader need to make a feed look good? While Atom and RSS have been written from an abstract publisher's point of view, making everything possible and allowing maximum flexibility. Especially RSS, which has shown its flexibility in becoming the de facto format for podcasts. And both Atom and RSS are really old, written at a time when it probably wasn't clear how RSS would eventually be used.

In the end, no matter which format a feed uses, users won't notice any difference (as long as publishers are smart enough to use square images!). So any feed is a win, no matter whether RSS, Atom, or JSON feed.

As far as I know, only Downread (disclaimer: my beta app) has that: https://feeds.downread.com/signup?i=hn-47845011

You can select a max number of posts per feed, max age and enable/disable tracking of unread posts on a per-feed basis.

This looks great. Installed it because I may need something like this soon. And at that price, I wouldn't think twice about buying it if it does what I need (record iPhone apps and show screen recordings of desktop apps in vertical videos). A few things I noticed:

- the iPhone mode confuses me. It seems to use the iPhone's camera. So this is not screen-recording?

- in view mode, I can't position the blue 'cursor' by clicking on the timeline. The only way to jump to a position seems to be to drag the handle of the blue 'cursor' line? I would expect to position it with a single click. Or at least modifier+click.

- how does it decide when and where to zoom? I found that unintuitive and not sure if needed. If I was showing a desktop app on TikTok, zooming would make sense to me. But when the original screen resolution is used, I think that's a feature I would rarely use.

- speaking of Tiktok, is there a way to set the target resolution? I have seen the 'stage' feature, but I am not really sure what it is for and whether it may help me.

- Live studio looks fun. But what does that magnifier button on the bottom right do?

(for background: I have only limited video editing experience, mostly TikTok-style with CapCut - so if I don't understand parts, it's quite possible I just don't know the usual conventions of video editing and jargon)

I have also thought about things like that. I'm currently working on a mainstream-focused RSS reader that comes with a large feed catalog and a feed-spider mechanism: when a site like Hacker News posts a link to a yet-unknown site, it automatically searches the website for an RSS feed, and if it finds one, it automatically adds it.

While my main project is the RSS reader itself, I think the ever-growing feed catalog is something that would be interesting as a stand-alone project: a reader-neutral catalog of RSS feeds.

An interesting observation is how people are currently discovering podcasts vs how they discover news feeds. Most podcasts are found on podcast directories, usually embedded in the podcast listener's platform. While discovering an RSS feed is more like i-found-an-interesting-site-does-it-have-an-rss-feed, which works ok for enthusiasts, but is far too complicated for mainstream users.

From a publisher's perspective, the main issue with RSS feeds is that if they contain the full text instead of a summary, they are currently hard to monetize. And a summary-only feed is just not that great.

A solution may be a YouTube-like model, where feed readers either insert ads or charge their users monthly fees that are redistributed to feeds.

I keep hearing that "the web is broken". But how exactly? What parts are broken in a way that makes it worse than it used to be at some point? I think people who write this just glorify the past. I don't want to go back. Not to the age of Flash ads that crashed the browser. Not to the age where people overused HTML frames and basic stuff like opening in a new window didn't work. Not to the age when every site used tables for layout, and they didn't work half of the time. Not to the time when every non-trivial application required Java and the whole computer froze even if you were one of the lucky ones who got it working. Not to IE-specific hacks and ActiveX. Not to image maps...

And content-wise, there is more content than at any point in time. So what's the issue?

I have recently begun starting emails with "human here"...

You can use a more nuanced approach.

What I did in the last systems I created:

1. The JWT expiration depends on the user. Admins get only 1 minute or so, but regular users 1 hour. If I had an SaaS for enterprise customers, I would use very short expiration times for paying enterprise users, but long for non-paying users.

2. When 95% of all requests are reads, and it's not sensitive data, only validate the JWT. For dangerous operations, always require validation of the user status.

3. I prefer to let the server control the JWT lifetime. So the server can respond to any request with a 'token too old' error, and the client knows it must renew it and retry. That allows you to configure the expiration date of the token depending on the operation and how critical it is.

I wouldn't be here if I hadn't somehow obtained and read Accidental Empires as a kid. Still no empire of my own though :(