I spend a lot of time on DEV these days. Reading posts, finding interesting projects, participating in challenges, and occasionally writing something myself.
I also like daily.dev. Having a feed of developer content right there whenever I open a new tab is pretty convenient.
So naturally, I started thinking... what if I had something like that, but just for DEV?
And because apparently I can't have an idea without turning it into another project, I built one.
It's called DEV Tab, and it's a free, open-source browser extension that replaces your new tab page with a feed of posts from DEV.
It's now available on the Chrome Web Store.
Firefox support is built too, and the add-on is currently awaiting review. I'll update this post with the link once it's approved.
A little more than just a feed
The original idea was pretty simple. Open a new tab, see what's happening on DEV, and click through to anything interesting.
But, as usual, I kept thinking of things to add.
You can browse posts from Today, This Week, Rising, and Latest, along with dedicated sections for trends, events, podcasts, and videos.
There are also tag filters, so you can quickly jump between subjects you're interested in. You can save your favorite tags, hide tags you'd rather not see, and follow posts from specific DEV organizations.
A few other things I added:
- Search directly from the new tab page.
- Keyboard navigation using arrow keys and Enter.
- A compact view if you'd rather see more posts and fewer images.
- Reaction counts and previews of the three newest comments.
- A shortcut to create a new DEV post.
- Feed caching, so opening a new tab doesn't mean waiting for everything to load again.
Nothing particularly revolutionary here. I just wanted a convenient way to explore DEV without having to go looking for things.
Then I decided it needed a dashboard
This part wasn't in my original plan, but I spend enough time writing on DEV that I thought having a better overview of my own activity would be useful.
If you add your DEV API key in the extension settings, you unlock some additional features, including a personal dashboard.
The dashboard includes your follower count, views, reactions, comments, and new followers, with options to look at the last 7, 30, or 90 days.
There's also a daily views chart, an activity heatmap that lets you browse previous years, and a list of your published posts and drafts.
You can see recent followers, top supporters, and where your readers are coming from, too.
I particularly like having the activity heatmap and post statistics together. It's interesting to look back and see when I was active and how different posts performed.
The dashboard screenshot above uses fictional example data, by the way.
Connecting your DEV account is completely optional
You don't need an account or API key to use the extension. The public feeds, search, filters, and other browsing features work without one.
But if you do connect your DEV account, you also get access to your personal feed based on the tags you follow, your reading list, and semantic search.
You can generate an API key from your DEV settings.
The extension doesn't have a backend, analytics, or tracking. Your API key stays in your browser's local extension storage and is only sent to DEV for authenticated API requests.
I wanted to keep it simple and avoid introducing a separate service just to display information DEV already makes available.
A few limitations
There are a couple of things I would have liked to include but couldn't because of the DEV API.
For example, you can't directly react to posts, leave comments, or save articles to your reading list from the extension.
You can view reaction counts and preview comments, but interacting with a post opens it on DEV itself.
I'd love to have those actions directly in the feed someday, but for now, that's a limitation of what's available through the API.
Built with WXT, React, and TypeScript
I used WXT for the extension framework, along with React and TypeScript.
This was my first time using WXT, and I really liked being able to build for Chrome and Firefox from the same codebase.
One thing I spent some time on was making sure the feed wouldn't constantly refetch everything whenever a new tab opened. The first page of each feed gets cached for ten minutes, and previously loaded posts can still appear if you're offline.
It's a small thing, but when you're replacing something as frequently used as the new tab page, I think it matters.
Give it a try!
DEV Tab is open source, so you can take a look at the code, report bugs, suggest features, or contribute if you'd like.
The Firefox version is currently awaiting approval, and I'll add the link here when it's published.
This started as one of those little "wouldn't it be nice if..." ideas, and somehow turned into a full browser extension with a personal analytics dashboard.
I guess that's what happens when you keep finding things you want to build.
If you use DEV regularly, I'd love to hear what you think! And if there's something you'd find useful in a future version, let me know.
Top comments (29)
The "follow posts from specific DEV organizations" is the feature I didn't know I wanted. Half my DEV bookmarks are from 3 orgs and the native follow just buries them in the main feed.
Honest question: how are you handling the DEV API rate limits with the caching? Because their
/articlesendpoint is rate-limited to ~10 requests/min per IP, and a dashboard that refreshes on every new tab open is going to hit that fast if someone opens 15 tabs in a minute.Also — is the API key stored locally (browser storage) or sent through a backend? Asking because DEV API keys give write access too (can publish posts), so users might want to know.
I'm glad you like the organizations feature. That was one I really wanted too.
For the rate limits, I cache the first page of each feed for 10 minutes in browser storage. When you open a new tab, it checks for cached data first and displays that immediately rather than fetching everything again. Once the cache expires, it fetches fresh data. Additional pages and search results aren't cached, though, so it's still possible to hit rate limits with heavier use. If that happens, it keeps the cached posts visible and shows a message rather than just leaving you with an empty feed.
And yes, the API key is stored locally using the browser's extension storage. There's no backend involved. Authenticated requests go directly to DEV, and the key is never included in URLs or sent anywhere else. Disconnecting your account also clears the associated cached data.
I definitely understand the concern about API keys with write permissions, so keeping everything local was important to me. Thanks for taking the time to check it out!
That's a solid approach — 10-min cache for the first page + graceful degradation when limits hit is way better than a hard error. Most extensions just break silently.
The local-only API key setup is the right call. Given how many "convenient" extensions proxy everything through a backend, keeping it fully client-side is a huge trust signal. Thanks for clarifying.
What's next on the roadmap?
That's a good question! Honestly, I haven't really figured out what's next yet. 😂 I got a little carried away adding features before the first release, so now I'm mostly just excited to have it out there!
I think for now I'd like to see how people actually use it, gather some feedback, and figure out what would be genuinely useful to add next. I already have a few suggestions from people that are worth exploring.
And of course, I'm still waiting on Firefox approval! Hopefully that won't take too much longer.
Thanks again! I really appreciate it.
This is genuinely a useful feature! Having a DEV feed directly in every new tab makes discovering new articles, trending topics, and interesting projects so much more convenient. I especially like the personalized filters and activity dashboard — practical features that can make a real difference in a developer’s daily workflow. Great work turning a simple idea into something genuinely valuable for the community!
Thank you so much! 😊 It started out as just wanting a convenient way to browse DEV whenever I opened a new tab, but of course I kept finding more things I wanted to add. The dashboard was actually an afterthought, but it's become one of my favorite parts. I'm really glad you like the idea, and I appreciate the kind words!
❤️
❤️
The activity heatmap with year browsing is such a nice touch, I’d actually open new tabs just to check it 😄 Also really appreciate no backend and the API key staying local. Waiting for the Firefox approval so I can install it!
I'm waiting on Firefox approval too! 😅 It seems like their review process takes a bit longer, but hopefully it won't be too long. The activity heatmap is one of my favorite parts of the dashboard, so I'm really glad you like it! And keeping everything local was important to me from the start. Thanks so much for checking it out! I'll definitely update the post as soon as Firefox approves it.
Thanks Jessica!
Cool! Nice work 😸
Thanks!!
Hey Jessica! 😊❤️
First of all, congratulations on DEV Tab! I really like how a simple idea evolved into a useful browser extension with a surprisingly rich set of features.
I had a chance to look through the source code, particularly from an architecture and security perspective, and I wanted to share a few thoughts.
There are several design decisions I appreciate. Keeping the extension backend-free, storing the API key locally rather than syncing it, sending credentials through request headers instead of URLs, and limiting browser permissions to what’s needed are all sensible choices.
I also appreciate the attention you’ve given to caching. When something runs every time a new tab opens, even small performance decisions can make a noticeable difference.
From a security perspective, a few areas might be worth revisiting as the project evolves: validating external URLs before navigation, restricting API key exposure across extension contexts, and ensuring cached account data remains properly isolated during account changes or concurrent requests.
I also looked for common unsafe HTML rendering patterns and didn’t find anything immediately concerning in my initial review. Of course, that doesn’t replace a complete security audit, and I haven’t verified these potential edge cases through runtime testing.
So, no vulnerability claims here, just a few observations from someone who enjoys exploring how things work under the hood. 😄
One thing I particularly respect is that you’ve kept the architecture relatively straightforward instead of adding unnecessary complexity. That’s often harder than it looks.
And I definitely relate to the “I just wanted to build one small thing” experience. Somehow those projects always develop a personality of their own! 😂
Thanks for sharing the source code and putting your work out there, Jessica. It’s always enjoyable to see developers building practical tools for the community.
Looking forward to seeing where you take DEV Tab next. Great work! ❤️🚀
Wow, thank you so much for taking the time to actually look through the code. I genuinely appreciate this kind of feedback, especially when someone takes the time to understand the decisions behind a project.
Keeping things simple and avoiding unnecessary permissions or services was definitely intentional. I didn't see much reason to introduce a backend when the extension could communicate directly with DEV, and keeping API keys local just made sense to me.
I really appreciate the security suggestions, too! Those are all things worth taking a closer look at, particularly as I continue adding features.
And haha, yes, the "I'll just build this one little thing" situation is becoming a recurring theme with my projects. Somehow they always end up being more involved than I originally planned.
You’re very welcome, Jessica! 😊
I really enjoyed exploring the project and understanding the decisions behind it. I think keeping things simple while still paying attention to security and usability is something worth appreciating. And haha, I know that feeling all too well! 😂 Sometimes the smallest ideas turn into the projects we end up enjoying the most. Keep building, experimenting, and having fun with it. Looking forward to seeing where DEV Tab goes next!
Wishing you all the best with the project and the Firefox release!
The detail I liked most is that you thought about how many times a day a new tab gets opened, since that's the one page where any loading delay gets noticed.
One idea for the cache: instead of fetching only after the 10 minutes expire, the background service worker could refresh the first page on a
chrome.alarmstimer. New tabs would then always open instantly with fairly fresh posts, and the API calls move off the critical path.Did WXT handle the Chrome MV3 vs Firefox differences for you, or did you still need per-browser code anywhere?
That's actually a really interesting idea. I hadn't considered refreshing the cache in the background on a timer, but I can definitely see the benefit of keeping the feed fresh without having to wait for a request when opening a new tab. I'll have to experiment with that!
And WXT handled most of the Chrome/Firefox differences really well. I was able to build both from the same codebase without much trouble. There were a few browser-specific details to deal with, particularly Firefox's permission requirements for storing authentication information, but overall it was a pretty smooth experience. It's actually my first project using WXT, and I've been really happy with it so far.
Thanks for the feedback! Really appreciate it!
Cool build — the local-only API key storage is a nice touch, a lot of hobby extensions wouldn't bother. On the chrome.alarms pre-warm suggestion, worth checking the MV3 service worker wake cost — alarms can keep the worker churning on machines where the browser just sits open all day. Also curious what the UX looks like when the rate limit gets hit mid-session: stale feed, error state, or silent fallback?
Amazing New Tab! Thank you for making such valuable extension.
Thank you!
How much time did you put into this work? I would like to acknowledge the hard effort you have invested.
Thank you so much! Honestly, I'm not even sure how many hours I put into it lol. I worked on it on and off for a while, usually whenever I felt like tinkering with it or thought of another feature I wanted to add. It was one of those projects I just kept coming back to whenever inspiration struck. I really enjoyed building it, though!
Thats A Good Start