# TheAlgorithms/website: a static Next.js site that scrapes its own algorithm library from git

> The Algorithms website is a static Next.js front end for the community algorithm repositories, and the data comes from a fetch step that pulls the algorithm files out of the git repositories before the build. It is MIT licensed for the site itself, with per algorithm licences living in the source repositories, and it is deployed on Vercel with Weblate handling the translations.

**TheAlgorithms/website** — The Algorithms website providing GitHub's largest open-source algorithm library.

- Repository: https://github.com/TheAlgorithms/website
- Website: https://the-algorithms.com
- Stars: 1,057 · Forks: 223
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/thealgorithms-website

## A static site whose content is scraped at build time

The repository is a static Next.js site providing a searchable library of all the algorithms in The Algorithms, and the key sentence is that all the data about the algorithms gets scraped directly from the git repositories.

That single design decision explains the shape of everything else. There is no database in this project and no CMS. The algorithms live as source files in separate git repositories, one per language, and the website reads them and renders them.

The consequence is a two step build. A fetch script populates the site from the upstream repositories, and then Next.js renders it. The package.json scripts make that explicit, with fetch-algorithms running ts-node against scripts/fetch-algorithms.ts, and the build script defined as fetch-algorithms followed by build:next, which is next build.

The scripts also cover the modes a static site needs. There is dev for next dev, debug which sets NODE_OPTIONS to --inspect, start for next start, and export, which runs the build and then next export. That last one is the pure static path, and its presence alongside the vercel deployment configuration is a hint about the deployment story.

For a contributor this matters concretely. If you fork the repository and run the site without fetching, you have an application with no content, and the difference between a working local site and an empty one is one command.

The repository layout matches the shape of a Next.js application of that era. There are pages/ for the routes, components/ for the React pieces, layouts/, hooks/, lib/, styles/, public/ for static assets, and scripts/ for the fetch and build tooling, with next.config.js and next-i18next.config.js at the root for configuration.

## The three commands that turn a fresh clone into a running site

The getting started section is short, and it assumes two things are already installed, Node.js and yarn.

The first command installs the dependencies.

```bash
yarn
```

The second runs the script that fetches all the algorithms from GitHub.

```bash
yarn fetch-algorithms
```

The third starts the development server.

```bash
yarn dev
```

And then you open http://localhost:3000 in your browser to see the website.

That is the whole loop, and the fact that fetching sits between install and serve is the thing to internalise. The content is not in the repository, so the site cannot be run without network access to the algorithm repositories. That is a deliberate choice rather than an oversight, because it is what allows the site to track the algorithm repositories without anyone doing a merge.

The README also offers a way to skip the local setup entirely. There is a Ready-to-Code Gitpod environment, and it will automatically run the commands mentioned above on run, which means you can check how your deployment looks without installing anything locally.

The dependency list in package.json shows what the rendering side is built from, and it is a familiar stack for a documentation site of this kind. Markdown is parsed with marked and processed with remark and rehype, with remark-gfm for GitHub flavoured Markdown, rehype-highlight and highlight.js for code colouring, katex for the math, and sanitize-html for cleaning the HTML that comes from the scraped files.

That last dependency is worth noting. The site renders content that it did not write, fetched from many repositories by many contributors, and it puts that through a sanitiser before display. A static site that renders scraped HTML has to think about what that HTML can do, and the presence of sanitize-html says it does.

## Translations through Weblate, and a Discord and a Matrix room

The site is translated, and the mechanism is worth understanding because it shapes how a contribution reaches a non English page.

You can help translate the website using Weblate, where you can complete the translations for the current languages or suggest something if you are unsure, and you can also add a new language. The repository carries a next-i18next.config.js and the topic list names i18next, and there is a Weblate badge showing translation status by language.

The community channels are listed in the header. There is a Discord, a Matrix room, a Gitter chat, and a LiberaPay donation link, and the README notes that the project is Gitpod ready.

The important design point is that translation is decoupled from the algorithm content. A translator works on the site's own strings through Weblate, and the algorithm bodies come from the repositories. So a new algorithm appears in every language at once, because it is scraped, while the interface around it is translated by people who know the site but may not know the algorithm.

That split has a cost. The scraped algorithm content includes its own explanations and comments, which are translated separately, in the algorithm repositories themselves, if at all. A page can therefore have a translated interface around untranslated prose, and the page has to handle both, which is visible in the dependency list with next-i18next and next-query-params for locale handling and the AWS SDK dependency for what appears to be serving the source files.

The aws-sdk dependency is a good clue to the overall architecture. The site does not commit the algorithm code. It fetches it at build time, from GitHub through octokit with a throttling plugin, and it needs somewhere to put the fetched assets, which is what the AWS SDK is for.

## Contributing, and the two checks Vercel runs for you

The contributing section is short and practical. If you want to add a new feature or fix a bug, create a new branch or fork and commit there. Before opening a pull request you should run yarn lint and fix potential errors, and run yarn build to check that everything still builds successfully.

Those two commands are the pre submission gate, and they map onto the two scripts in package.json. lint is tsc followed by eslint on the project, and lint-fix is eslint with the fix flag. The build command is the fetch followed by the Next build, so a full build also verifies that the scrape still works against the upstream repositories, which is a real integration check rather than a formality.

Then the pull request goes against main. Vercel will automatically create a preview deployment, and the pull request will be squash merged after being reviewed by a member.

The automatic preview is the part that makes the workflow pleasant. A change to a page, a styling fix, a new layout, all of it produces a live URL to look at before anyone reviews it, and the same mechanism works for a fork through the Gitpod route.

The repository also carries the supporting files such a project usually has. There is an .eslintrc and an .eslintignore, a .prettierrc, a .gitpod.yml, a .vercelignore, a CODE_OF_CONDUCT.md, and a .github/ directory. The vercelignore and the presence of a vercel deployment configuration are consistent with a static site hosted on Vercel, and the export script exists for people who want the output elsewhere.

## MIT for the site, and per repository licences for the algorithms

The licensing is split in two, and the split is the correct one.

The source code of the website itself, this repository, is licensed under MIT. All the licences for the code and explanations on the website can be found in the respective repositories.

So the site machinery, the React components, the fetch script, the build configuration, all of that is MIT and you can fork it freely. The algorithm implementations are licensed by the community repositories that hold them, and those licences vary, which is why the site points you at the source repository rather than claiming a single licence for the whole corpus.

For a reader, that means the algorithm you are about to copy out of the browser has its own terms and its own attribution requirement, and the site is careful not to paper over that.

The repository is also where a large amount of that source lives. The project description calls it GitHub's largest open-source algorithm library, and the website exists to make that library browsable in one place with search, categories and translations, which a pile of separate per-language repositories cannot do on their own.

The limits follow from that positioning. This is a reading and demonstration environment. The code is community contributed, the explanations are community written, and the site applies no editorial filter beyond what the upstream repositories enforce. There is no benchmark, no correctness verification and no versioning of the algorithm code itself, because the site does not own the code. If you need a vetted implementation with a published complexity guarantee, this is the wrong place to look, and the site is not claiming otherwise.

## Conclusion

TheAlgorithms/website fits a contributor who wants their algorithm implementation to appear in a browsable, searchable, translated site without maintaining a page, and it fits a reader who wants to read an algorithm in several languages and run it in the browser. It does not fit a team looking for a production algorithm library, because the code shown is community contributed and the site is a reading environment rather than a package. Check three things before you rely on it. Check where the data comes from, because all the data about the algorithms gets scraped directly from the git repositories, so the site reflects those repositories at build time rather than curating anything itself. Check the licence per algorithm, because the site source is MIT while all the licences for the code and explanations on the website can be found in the respective repositories, and they are not uniform. And check the build step, because the site will not render without running the fetch script first, so a plain yarn build on an unpopulated checkout produces an empty site. The last push was on 2026-10-06, the repository has no GitHub releases, and the site is deployed at the-algorithms.com.

## FAQ

### How do I run TheAlgorithms website locally?

Install Node.js and yarn, run yarn to install dependencies, run yarn fetch-algorithms to pull the algorithms from the GitHub repositories, then run yarn dev and open http://localhost:3000. A Ready-to-Code Gitpod environment can run the same commands automatically.

### Where does the algorithm content on TheAlgorithms website come from?

All the data about the algorithms gets scraped directly from the git repositories, via a script run by yarn fetch-algorithms. The site itself is a static Next.js application with no database and no CMS.

### How is TheAlgorithms website translated?

Through Weblate, where contributors complete the translations for the current languages or suggest a new one. The site uses next-i18next for locale handling, and the scraped algorithm content is translated separately in the algorithm repositories themselves.

### What licence applies to TheAlgorithms website and its content?

The source code of the website itself is licensed under MIT, while all the licences for the code and explanations on the website can be found in the respective repositories, so each algorithm carries its own terms.

### What should I run before opening a pull request to TheAlgorithms website?

Run yarn lint and fix any errors, then run yarn build to check that everything still builds successfully. The build script runs the algorithm fetch first, so it also verifies the scrape against the upstream repositories. Pull requests go against main, and Vercel creates a preview deployment automatically.

### How is TheAlgorithms website deployed?

Through Vercel, which the README credits and which hosts the live site at the-algorithms.com. The package.json also exposes an export script that runs the build and then next export, for a plain static output.

## Sources

- [Issues](https://github.com/TheAlgorithms/website/issues)
- [License: MIT](https://github.com/TheAlgorithms/website/blob/main/LICENSE)
- [Project website](https://the-algorithms.com)
- [README](https://github.com/TheAlgorithms/website/blob/main/README.md)
- [TheAlgorithms/website on GitHub](https://github.com/TheAlgorithms/website)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/thealgorithms-website