I spend a lot of time on DEV these days. Reading posts, finding interesting projects, participating in challenges, and occasionally writing somethi...
For further actions, you may consider blocking this person and/or reporting abuse
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.
"I got carried away adding features before the first release" is the most honest dev answer I've read today. Every project I've shipped, I had to force myself to stop and release, because there's always one more feature that "would make it complete".
Good call on watching usage first. My experience with side projects: the feature you think people want and the feature they actually use are usually different. Ship, watch, then build the 20% that gets used 80% of the time.
Also — Firefox approval is usually faster than Chrome, so it should be any day now. Good luck!
Oh, I know that feeling all too well! 😂 There's always something else I want to add, and at some point I have to remind myself that it doesn't need to do absolutely everything before I can release it.
And I completely agree about watching what people actually use. It's so easy to get caught up building features that sound great in my head but might not be nearly as useful to everyone else.
I'm hoping you're right about Firefox! It's been sitting in review for a bit now, so I've definitely been checking more often than I probably should lol. Thanks again!
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!
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!
Creating something is one of the most enjoyable things for a human being. To be honest, I myself often lose track of time when I am developing—or creating—something.
May I DM to you, Jessica?
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?
This is a great idea, and the execution sounds really thoughtful. 👏 I like that the public feeds, search, and filters all work without an account, so the API key is a true opt-in for the dashboard and personal feed. The ten-minute cache with offline fallback is a smart detail for something that loads on every new tab. The activity heatmap alongside post stats is a nice touch too, since it makes it easy to see how your writing rhythm connects to what actually performed.
Also appreciated that you were upfront about the API limitations around reacting and commenting. Congrats on the Chrome launch, and good luck with the Firefox review! I'm curious whether you've thought about adding a "reading time" filter to the feed, which could be handy for quick tab-opens versus longer sessions.
cool!
Thanks!
Thats A Good Start
A Good Start
Wow, this is so cool, Jessica! Gonna try it for sure 😀
Thanks so much! 💖