The idea
I keep five tabs open to stay current: GitHub, Hacker News, DEV.to, Hugging Face, and whatever release notes I'm tracking that week. So I built DEV·TV: a single-page app that presents all of it as a TV broadcast instead of a browsing session. Channels instead of tabs. Auto-cycling stories instead of infinite scroll. A power button, a channel dial, real static when you switch channels. You don't browse developer news. You watch it.
Repo: github.com/shouvik12/devtv
Live demo: shouvik12.github.io/devtv
The build itself was mostly straightforward. What I actually want to write about is the discipline underneath it: testing every source claim against a real request instead of documentation, diagnosing a real production issue down to the exact number instead of guessing, and catching a security gap with a proof, not just a patch.
The constraint: no backend, ever
One self-contained HTML file. No build step, no server, no database, no accounts. Every channel fetches directly from its source's public API, in the browser, at the moment you open the page.
This constraint turned "can I add channel X" into a real technical question with a testable answer, rather than something I could hand-wave from a docs page.
Testing every source instead of trusting the docs
I evaluated Reddit, Product Hunt, X, LinkedIn, Discord, Medium, and arXiv as channels. Seven sources tested, seven documented outcomes, each one backed by an actual result rather than an assumption.
Reddit turned out to have a real, legitimate path: an "installed app" OAuth client type built for exactly this, no client secret required. I traced it all the way to the token exchange step and confirmed against a reported real-world error that ssl.reddit.com/api/v1/access_token has no CORS support. The authorization step works fine client-side; the step right after it doesn't. That's a precise finding, not a vague "Reddit didn't work."
Product Hunt requires an OAuth token with nowhere safe to live in public client-side code, so I ruled it out rather than shipping a security compromise.
X/Twitter, as of a 2026 pricing change, has no free read tier at all, confirmed before I spent any more time on it.
LinkedIn's API access is partner-gated with a slow, uncertain approval process, documented once I confirmed there was no individual-developer path.
Medium's API is confirmed discontinued via their own developer community, not just "hard to find."
Discord was ruled out on three independent, confirmed grounds at once: bot-token requirement, no global trending concept even with one, and explicit lack of CORS support.
arXiv looked like the strongest candidate of the seven, a stable, keyless, well-documented public API. I built it, shipped it, and live-tested it in an actual browser session where four other channels succeeded and this one returned a plain Failed to fetch. Confirmed, then removed, rather than left in as a maybe.
What passed testing and made it in: GitHub (Search API, since Trending has no official endpoint), Hacker News (Firebase, fully public), DEV.to (whose team explicitly ships CORS support for exactly this use case), Hugging Face (trending models, later paired with a daily-papers channel), and GitHub Releases (real version drops for React, Vue, TypeScript, Node, Python, and Rust).
Diagnosing a real rate limit with the exact number, not a guess
Weeks into running my own app, a channel started showing SIGNAL LOST. Rather than assume and patch blindly, I queried GitHub's own /rate_limit endpoint directly and got the precise state:
{"resources":{"core":{"limit":60,"remaining":0,"reset":1789925743,"used":60}}}
60 used out of 60, converted straight from the Unix timestamp into an exact reset time. My Releases channel's 6-requests-per-refresh, combined with the GitHub channel's own polling and interactive README reads, added up to real, quantifiable pressure on GitHub's 60/hour unauthenticated limit. The README originally claimed the app stayed "comfortably under" that limit. Once I had the real math, I corrected it to state the actual number instead of a reassuring approximation.
Finding and proving a security fix, not just applying one
A code review flagged that Hacker News's API documents its text field as containing raw HTML, and my in-app reader was inserting that field directly into innerHTML, unescaped, while every other source went through a proper escape-then-format pipeline first.
I didn't want to just apply the obvious fix and move on. I wanted evidence it actually worked. So I ran an actual malicious payload through the corrected code:
Input: <p>Check this out</p><img src=x onerror=alert(document.cookie)><script>alert(1)</script>
Output: <p>Check this outalert(1)</p>
Contains onerror: false
Contains <script>: false
Contains <img: false
No tag structure, no event handlers, nothing executable survives. That's the standard I held every fix to: not "I believe this works," but "here's the output that proves it."
What this process actually looked like
The part I'd underestimated going in was how much of this build was verification rather than generation. Every claim about an external API got checked against something real: a live request, a browser test, an actual error message, a rate-limit endpoint queried directly. Screenshots for the documentation came from an actual headless browser running the actual app against actual live data, including one that happened to catch a real rate-limit error mid-capture, kept in the docs deliberately because it demonstrated the error handling honestly rather than staging a success state.
That's the standard I'd want applied to anything I ship: not "this should work," but "here's proof it does, and here's exactly where it doesn't."
Try it
It's one HTML file. No install, no signup.
Live demo: shouvik12.github.io/devtv
Source, plus the full testing record for every evaluated channel: github.com/shouvik12/devtv
If you leave it running on a second monitor for an afternoon, I'd genuinely like to know whether you glanced at it.
Top comments (0)