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 would be nice if you could put some screenshots, a demo video, or even an actual demo on the page. There's a lot of news readers out there so I'd like to see what I'd potentially be getting if I do actually use Downread.
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)?
TLDR - Just disables sleep, it gives a simple toggle to disable and re-enable sleep fast which survives the closed lid, or to prevent your screen from dimming
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.
Thanks for the detailed feedback, this was really valuable.
We fixed file autocomplete, automatic CLAUDE.md loading for Claude subscription sessions, and the plan issues. Plans now only appear when requested, and progress only updates after the related work has actually been done.
Your comparison with Claude Code is fair. Speed remains something we're trying to optimize outside of benchmarks, and long running tasks with plans seems to be something we need to improve. We're actively working on more optimization to latency and unnecessary model calls.
Thanks again for the comment and if you could try the latest build when you have time, would love to hear your thoughts again!
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.
- 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.
Consider the title of my article: “Atom is better than RSS, in ways that matter”. That emphasis belongs there, and it’s mildly bad to lose it. (For presentation on my own site, I also control the line break position on larger screens; but that wouldn’t be appropriate for feeds, where you can’t control the presentation.)
We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles? When you look at titles that get used on platforms like YouTube, there’s obviously a desire for formatting. People use Unicode shenanigans to work around the deficit frequently. (And they do so in ways that are mostly only available for the English script, quite inequitable for other scripts.) Even if you were to restrict it to ASCII, people GLEEFULLY abuse capital letters FOR EMPHASIS!!!!1!
Especially once you get to coding topics, titles need to support <code>, which is important semantics.
(My biggest disappointment with Atom is that text constructs are single-type-only. I wish you could provide distinct text and HTML representations, like email does with the multipart/alternative MIME type. In some places where I use <code> in titles, I’d just drop the <code>…</code> wrapping, in other places I’d turn it into `…`.)
I will write a proper article about all this some time soonish, encouraging people to use markup in titles.
> 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?
Inferior plain text: Using make and git diff for a simple and powerful test harness
Better plain text: Using `make` and `git diff` for a simple and powerful test harness
Better HTML: Using <code>make</code> and <code>git diff</code> for a simple and powerful test harness
I use the second for the <title> and og:title on my site, and the third in the <h1> and feeds. It will unfortunately be turned into the first by some feed readers, but that’s their problem. (Some feed readers do accept a subset of HTML phrasing content.)
> If it shouldn't be rendered in a different way for obvious reasons
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.
> Imagine the same title in a list of post titles.
Sounds wonderful. I think you aren’t realising that it’s already easy to abuse this stuff, with uppercase and exotic Unicode letters <https://yaytext.com/> and such. But people don’t abuse it in feeds.
I’m not talking about allowing <font face=Impact style=color:red>, just some relevant semantic HTML elements like <code>, <em> and <kbd>, which are pretty harmless to add, and useful.
Perhaps I should have gone with the MATHEMATICAL MONOSPACE characters for my plain text title. Alas, HN strips them. Demo in https://temp.chrismorgan.info/2026-08-02-titles.html. Doesn’t look any good for me with my specific fonts, would look better for some people.
I would really strongly prefer titles to work the same way they do in html, which means plain text. Why should feed titles need a different standard than html titles?
There is precedent. The HTML title element cannot contain markup. Titles may be cited in many places and formatting may not be available. If a title requires formatting to convey its meaning it's a bad title.
(Not that I want to defend RSS. In early versions valid RSS wasn't necessarily even valid XML. It is very poor.)
You haven’t engaged with my second paragraph, or my responses to other responses in this thread. Meaningful inconsistency is already easy with just Unicode, nor does limited HTML make things materially inconsistent.
While it’s true Unicode pushes the boundaries of “plain text” having a consistent font face, font size, font weight, letter spacing, font color, text wrapping, etc is good.
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?
Nobody thinks HTML tables need a comeback. They think the days where individual people hosted individual sites with their own content, and formed communities around them through BBS or mailing list, was preferable to the one where Meta's algorithm decides 99% of what 99% of people see, optimized for "engagement," and applying their own censorship.
I'm not saying whether or not that's better I'm just explaining the point. Obviously nobody expects a Flash comeback. They miss the smaller-scale, more human-centric (or at least less corporate-dictated) web. Maybe they're nostalgic for something that didn't really exist, but obviously it has nothing to do with browser tech of the era
