# hackertab.dev: a new tab page that aggregates developer news > hackertab.dev is a Chrome and Firefox extension that turns the new tab page into a dashboard of developer news, tools, jobs, and events, drawn from a list of sources including GitHub Trendings, Hacker News, DevTo, Lobsters, Product Hunt, Reddit, and custom RSS feeds. It is a React and Vite project with three build targets, an optional account, and a settings model based on languages and topics. **medyo/hackertab.dev** — A Chrome 🌐 & Firefox 🦊 extension to discover the latest developer news and tools in one tab! - Repository: https://github.com/medyo/hackertab.dev - Website: https://hackertab.dev - Stars: 774 · Forks: 93 - Language: TypeScript - License: Apache-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/medyo-hackertab-dev ## The new tab, filled with developer news Hackertab makes it easy to stay up to date with the latest developer news, tools, jobs, and events, and the project description says it plainly: it is a Chrome and Firefox extension to discover the latest developer news and tools in one tab. The premise is simple enough that it is worth asking why it works. As a developer, it can be difficult to stay on top of everything happening in the field, and the answer is to customise the default tab page to include news, tools, and events from top sources such as GitHub Trendings, Hacker News, DevTo, Medium, and Product Hunt. The pitch is that whatever type of developer you are, you will find relevant information there. The usage instructions are four steps. Install the extension from the Chrome store or from Mozilla add-ons, open a new tab, and the extension is running and visible, then select your preferred programming languages and sources. That last step is the design. The settings are organised by programming language, framework, and topic, so the dashboard is filtered by what you work in rather than by what a general news site decides. The feature list adds daily updated content, curated content from the best sources, bookmark and read it later, a dark mode, and AI-powered recommendations tailored to your preferences. The product is not only a browser extension. There is a live demo at now.hackertab.dev, which is the same experience without the install, and a hosted API that the extension and the site share, which the development setup points at. The project is Apache 2.0 licensed, written in TypeScript, and the last push was on 2026-08-24. The published extension versions are v1.26.13 from 2026-06-01, v1.26.10 from 2026-03-23, and v1.26.8 from 2026-03-08, so the store releases come roughly every two to three months, which is a sensible cadence for something that has to keep up with a dozen source APIs. ## The source list, and how to add one The data source list is the substance of the extension, and it is longer than most people expect. The sources are GitHub Trendings, Hacker News, DevTo, Hashnode, Lobsters, Confs.tech, Product Hunt, Reddit, Freecodecamp, Medium, Indiehackers, and Hackernoon. On top of that there is a custom RSS feed, so you can add a feed that is not on the list. The choice of sources is deliberate in a way that is visible. The list mixes three different kinds of thing. There are the link aggregators and news sites for developers, which is the Hacker News, DevTo, Hashnode, and Lobsters cluster. There are the product discovery sites, Product Hunt and Indiehackers, which are about tools rather than articles. There are the community sites, Reddit and Freecodecamp, which are forums. And there is Conf, which is Confs.tech, the conference listing, which is the one that carries the events half of the promise. GitHub Trendings is the odd one and the most valuable, because it is a moving target rather than a fixed feed, and a dashboard that shows what is trending in the repositories you follow is a different signal from a blog roll. The list is extensible in two ways, and the README names both. You can point it at a custom RSS feed for a source that is not built in, and you can create an issue asking for a new data source, which is the route for a source that needs a specific parser rather than a feed. That distinction matters for anyone considering contributing. A new RSS source is a configuration change, while a new site means writing a parser for it, and the extension has the parsing dependencies for that: htmlparser2, dompurify for sanitising the HTML it scrapes, jsonpath for reading structured data out of a page, and the country-emoji package for flagging sources by country. ## One codebase, three build targets The development setup is documented in a way that is common for a project that ships a web app and two browser extensions from one source tree. Contributors are asked to work on the develop branch, and to create an env file in the root directory with the variables the build needs. ```bash VITE_API_URL=https://api.hackertab.dev/ VITE_BUILD_TARGET=web # or extension VITE_BUILD_PLATFORM=chrome # optional, used for extension builds (chrome or firefox) VITE_FIREBASE_API_KEY= # optional for local dev, required for auth features VITE_AMPLITUDE_URL= # optional VITE_AMPLITUDE_KEY= # optional VITE_SENTRY_DSN= # optional ``` The first three are the ones that change what you get. The API URL is where the content comes from, and the default points at the production API, which is worth noticing: a local development build talks to the live service unless you change it. The build target selects the web build or the extension build, and the build platform selects Chrome or Firefox. The remaining four are optional, and the comments say which are for which purpose. The Firebase key is optional for local development and required for the auth features, which is the honest way to describe a feature that needs a backend. The Amplitude URL and key are the analytics configuration, and the Sentry DSN is the error reporting configuration. The setup itself is a standard Vite start, on Node.js 18. ```bash $ git clone https://github.com/medyo/hackertab.dev.git $ cd hackertab.dev $ yarn $ yarn start ``` And then you open the local port, which is 5173 unless the terminal says otherwise. The build commands are three, one per target. ```bash # Web build $ yarn build:web # Chrome extension $ yarn build:chrome # Firefox extension $ yarn build:firefox ``` Looking at the scripts, each one sets an environment variable and calls a shell script in the script directory, so the three builds differ by a target and a platform rather than by a separate codebase. That is the right shape for a project that has to publish to two extension stores and a website from the same React application. ## The dependency list is a description of the product The package manifest is long, and reading it tells you more about the application than the README does. The foundation is React 19 with React DOM, Vite for the build, and react-router-dom 6 for routing, which is what a web app and an extension with several pages need. State is zustand, and data fetching is React Query with the persist client and the async storage persister, so the cache survives a browser restart. Then there is a long tail of interface components, and this is the part that makes the product what it is. There is react-select for the language and source pickers, react-modal for the settings dialog, react-toggle, react-tooltip, react-simple-toasts for notifications, react-contextify for context menus, react-icons, react-spinners for the loading states, react-responsive for the layout, react-infinite-scroll-hook for the feed, react-share for the sharing buttons, and timeago.js for the relative timestamps. A dashboard that shows a stream of items from a dozen sources needs exactly this set of parts, and the list is a good map of the feature work. Reading content is handled by react-markdown with dompurify alongside it, which is the correct pairing, since the sources are third party HTML and rendering it as Markdown without sanitising it would be a script injection hole. The rest of the list is infrastructure. Axios with the cache adapter handles the requests, Firebase 11 handles the optional account, the Amplitude browser SDK handles the analytics, the Sentry React SDK handles the error reporting, and dnd-kit core and sortable provide the drag and drop reordering. One dependency is worth calling out because it explains a feature: htmlparser2 with jsonpath, which is the scraping layer for the sources that have no feed. The eslint configuration in the manifest extends the react-app preset, the package is not private, so it is published, and the engines field pins Node 18. ## What a new tab extension asks of you A new tab override is a small thing with a large surface, and it is worth being explicit about what this one asks of a user. It takes over the most visible page in the browser. Every new tab becomes a dashboard, which means the extension is running on every navigation you make into a blank page, and that the extension's permissions are effectively always on for that surface. Users who install it for the news are also accepting a page that fetches from a dozen third party origins every time they open a tab. Some of that fetching is unavoidable, because the whole product is an aggregation. Some of it is the account and the analytics, and the optional variables in the env file are the place where that is configured. The second thing to notice is that the content is aggregated rather than owned. The extension renders posts, links, and titles from GitHub, Hacker News, DevTo, and the rest, and the parsing of that third party content is where the engineering effort is, which is why a new source is an issue rather than a configuration change. The third is the release model. The extension is distributed through the Chrome Web Store and Mozilla add-ons, and the store versions in the README move in the 1.26 range with a dated cadence. That is a different delivery model from a self hosted dashboard, and it has a real consequence: a user is running code that the store updates, and the store is the gate. ## A client of a hosted API, not a self hosted reader The last is the hosted API. The local development setup points at the production API endpoint, so the extension is a client of a service rather than a self contained aggregator. That is the right design for keeping thirteen sources working, and it is also the reason the extension needs network access and the reason a self hosted version is not something the repository offers. For a reader evaluating it, the honest summary is that this is a well built aggregation dashboard with a large, curated source list, published as a browser extension, whose value is entirely in the sources and the filters rather than in any novel rendering. That last point deserves to be separated out, because it decides what you can and cannot do with the project. The extension is a client of a service. The content is fetched from the hosted API, and the development env file points at the production endpoint of that API by default, so even a local build is talking to the live service unless you change that variable. The repository is the client, not the aggregator. The reason is straightforward and reasonable. Thirteen sources, several of which have no feed and need a parser, need a server side component that keeps up with their changes, and the person who maintains that component is the person who ships the extension. It is the same trade every reader mode and every dashboard service makes. What it means for you is that there is no self hosted version to run, and the extension needs network access to do its job. If you are offline, the tab is empty, and if the service is down, the tab is empty. The store distribution adds the other half of the picture, since the extension is installed from the Chrome Web Store or from Mozilla add-ons and is updated through those channels. For a user who wants a personal dashboard, the trade is a good one. For a team that wants the same view on a server it controls, this repository is not the way to get it, and the data source list is the only part of it that is reusable. ## Conclusion hackertab.dev fits a developer who wants one place to scan what happened overnight across the sources they already read, and who is happy to accept that a new tab page is a third party service rendering other people's content. It does not fit a browser profile on a locked down machine where a new tab override is unwelcome, and it does not suit a team that needs the aggregation to be self hosted, since the data comes from the hosted API rather than from your own feeds. Verify first that the sources you care about are on the list, that the data actually reaches you from the hosted API endpoint, since the local development setup points at the production API, and that you understand what the optional account and analytics variables are for before you enable them in a local build. ## FAQ ### What is hackertab.dev? It is a Chrome and Firefox extension that turns the new tab page into a dashboard of developer news, tools, jobs, and events, filtered by the programming languages, frameworks, and topics you select. There is also a live demo at now.hackertab.dev that works without installing anything. ### Which data sources does hackertab.dev aggregate? GitHub Trendings, Hacker News, DevTo, Hashnode, Lobsters, Confs.tech, Product Hunt, Reddit, Freecodecamp, Medium, Indiehackers, and Hackernoon, plus a custom RSS feed for anything else. The README says you can also create an issue asking for a new source. ### How do I build hackertab.dev locally? Work on the develop branch, create an env file in the root with the API URL, the build target, and the build platform, then clone, install with yarn, and run yarn start, which serves the app on port 5173. The README asks for Node.js version 18. ### What are the build targets for hackertab.dev? Three scripts in the package manifest: yarn build:web for the web build, yarn build:chrome for the Chrome extension, and yarn build:firefox for the Firefox extension. Each sets a target or platform environment variable and calls a shell script in the script directory. ### Is the hackertab.dev extension self hosted? No. The content comes from a hosted API, and the development env file points VITE_API_URL at the production endpoint of that API by default. The optional Firebase key is for the auth features, and the Amplitude and Sentry variables are for analytics and error reporting. ## Sources - [License: Apache-2.0](https://github.com/medyo/hackertab.dev/blob/master/LICENSE) - [medyo/hackertab.dev on GitHub](https://github.com/medyo/hackertab.dev) - [Project website](https://hackertab.dev) - [README](https://github.com/medyo/hackertab.dev/blob/master/README.md) - [Releases](https://github.com/medyo/hackertab.dev/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/medyo-hackertab-dev