StarTrack-js: GitHub star history in the browser, with no server behind it

No backend, and that is the design

StarTrack-js is a GitHub star history and stats tool based on JavaScript only, with no server side. The technical details section says it plainly: it is built on React and deployed on GitHub Pages, it does not have a backend, so all of the data is stored locally in the browser and nothing is passed to any server other than the GitHub API to fetch the stargazer data.

That single architectural decision shapes everything else about the tool. There is nothing to install, no API key for the site itself, no account, and no server to pay for. The hosted instance is a static site, and anyone who wants their own copy can fork the repository and publish it the same way.

The features are focused on that premise. You can view the star history of a repository, see stargazer statistics such as the average number of stars per day and the maximum stars in a single day, compare several repositories at once, and look at a stargazer forecast computed from the existing data. There is also a preload mechanism, so a URL can name the repositories to fetch before the page has even loaded, and the stargazer data can be downloaded as a JSON or CSV file for analysis elsewhere.

The access token never leaves the browser

GitHub authentication exists here for one reason, and the reason is stated in the feature list: it is there to overcome the GitHub API rate limiter, which limits the number of API calls without authentication. Nothing more.

The handling of the token is the part worth examining. The authentication details are stored locally and are not sent to any server. By default they are kept in the browser's session storage, so they disappear when the tab is closed, and the user can choose to store them in the browser's local storage for longer persistence. The interface tells you which of the two is in use, through a tooltip that appears when you are logged in, and the token input was converted to a password field so it is not visible on screen.

The earlier user and password authentication was removed in version 2.0.0, and the reason given is that it is no longer supported by GitHub, with a link to the announcement. That is a good example of the tool following the platform rather than the other way round.

The forecast is a trend line, not a prediction

The stargazer forecast was added in version 2.4.0, and the method is named: the forecast is calculated using linear least squares regression over the existing stargazer data. Version 3.0.0 then improved the forecast selection process so it is easier to choose a desired forecast, and version 3.1.0 improved the error handling for forecast calculations when recent data is unavailable.

That last change is the one to know about, because it is the difference between a tool that handles a quiet repository and one that shows an error. A repository that has stopped receiving stars has no recent data to fit against, and the forecast is exactly the thing that breaks in that case.

Alongside the forecast there are the stargazer statistics, which include the average number of stars per day and the maximum stars in one day, and there is a checkbox to sync the statistics with the current chart view, so you can read the numbers for a specific date range rather than for the whole history. Since version 3.0.0 the interface also displays the date range of the chart when syncing the stats with it.

The API rate limit shapes what you can load

The GitHub API is the constraint, and the project has handled it in several ways over the releases.

Version 2.3.0 added a parallel load of the stargazer data, which the notes say significantly improves the overall loading time, and the same release added a log scale option for the chart data, which is how you make a long tail of daily stars visible next to a spike. Version 3.1.0 introduced a warning notification for repositories with an excessive number of stars, indicating the limitations imposed by the GitHub API when loading them all, and the same version fixed an issue with pasting repository URLs in mobile browsers.

The token is the other half of the answer, since an authenticated request gets a higher rate limit than an anonymous one. So the two features work together: the token raises the ceiling, and the warning tells you when you are approaching it. If you are analysing a repository with a long star history, the honest workflow is to use the token, and to download the stargazer data rather than repeatedly re-fetching it.

Three rebuilds in the project's history

The version history is a list of rewrites, which tells you a lot about where the code is now.

Version 2.0.0 was a complete rewrite using React and modern frontend technologies, with the chart component replaced, a dedicated preloading screen that shows a progress bar for each repository separately and errors for the ones that failed to load, and a dedicated colour per repository across the chart, the statistics and the close button. Version 3.0.0 was another complete rewrite, this time in TypeScript with modern React, moving from React Bootstrap to the MUI component library for a more consistent look, upgrading the chart component to Plotly.js for better rendering of large datasets, and adding complete test coverage of all components.

Version 3.4.0 was a tooling migration: from create-react-app to Vite, from jest to vitest, and an upgrade to ESLint v9, with two bug fixes, one for the copy URL not working and one for the repository statistics calculation with different timeline types. The chart library change in 3.0.0 was a deliberate one, since the tool's job is drawing a lot of points.

There is also a smaller but useful feature from 3.3.0, a relative time axis so the graph starts from the first star rather than an absolute date, and one from 2.4.0, the slash key to switch between the username and repository name text boxes, which is the kind of detail you only notice after using it every day.

The tests mock GitHub itself

The most interesting piece of engineering in the recent releases is the test setup. Version 3.2.0 added Playwright integration tests, and version 3.5.0 added a GitHub mock server to the Playwright tests and configured Playwright to run against it.

That is a significant piece of infrastructure for a project whose entire data source is a third party API. A test suite that hit the real GitHub API would be slow, would be rate limited, and would fail for reasons that have nothing to do with the code. With a mock server, the tests exercise the full path, the request, the parsing and the chart, against predictable data.

The mock server has its own script in the manifest:

  "scripts": {
    "dev": "vite",
    "start": "vite",
    "build": "vite build",

and later in the same block there is a dedicated command that starts it, which means the tests and the development server can be pointed at the mock instead of the live API. Alongside that there is a unit test suite on vitest with the React Testing Library, a coverage command, a lint step over the source directory, a formatting check with prettier, and a spell check with cspell, which is why the repository carries a custom dictionary file.

A familiar stack, and a defined browser range

The dependency list is the standard modern React application, and the manifest pins it precisely. The user interface is the MUI library with its icon set and the emotion styling packages, there is a data grid package for tabular views, Popper for the positioning behaviour the component library needs, and the chart is Plotly.js with its React wrapper. Data fetching is Axios, routing is React Router, forms are Formik with the yup schema validator, dates are handled with Moment.js, and the screen size handling is react-responsive, which is how the layout adapts between desktop and mobile.

Two dependencies are worth calling out. There is a zip library, which is how the download of stargazer data as JSON or CSV is packaged in the browser. And there is the Google Analytics module, which is the one thing this project sends to a server other than GitHub, and it is worth noting that the page view data goes to Google while the stargazer data does not go anywhere.

The manifest also defines the browser range explicitly, with a production list that excludes browsers with no meaningful market share, dead browsers and Opera Mini, and a development list pinned to the last version of Chrome, Firefox and Safari. The project is deployed on GitHub Pages as a static site, and the version is 3.5.0 with the package marked private, since it is an application rather than a library.

Editorial conclusion

StarTrack-js suits someone who wants a quick look at how a repository's popularity has moved, or a comparison of two projects, without installing anything or giving a third party a token, since the whole thing runs in the browser on GitHub Pages and the token never leaves it. It is the wrong choice if you need reliable data for a large repository, because the GitHub API rate limit is the binding constraint and the project warns about it explicitly, and it is the wrong choice if you want a long term record, since the data is fetched on demand rather than collected. Before you rely on the forecast numbers, read how they are produced, because a linear least squares fit over historical stargazers is a trend line and not a prediction, and download the stargazer data as JSON or CSV if you intend to analyse it yourself. The licence is MIT, the current release is v3.5.0 from 2026-07-09, and the last push was on 2026-10-16.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. seladb/StarTrack-js on GitHub