100_days_100_web_project: a catalogue of 218 small web projects to read and copy

A reading list rather than a codebase

The repository description says it plainly: this repository contains 100+ web projects from basic to advanced using html css and js and other web development tech stacks. The README puts a number on it, calling it a comprehensive collection of 218+ web development projects built using HTML, CSS, JavaScript, React, Node.js and more.

The name is a challenge structure rather than a code organisation. The hundred days framing comes from the 100daysofcode habit, and the topics list confirms the lineage with 100daysofcode, gssoc and gssoc26 alongside hacktoberfest and web-development.

So the unit of value here is a project, not a module. There is no package to import, no API to call, no build step to wire into your application. What there is, is a large set of small complete implementations that someone wrote and left for others to read. The homepage at dhairyagothi.github.io/100_days_100_web_project/ and a live site at 100-days-100-web-project.vercel.app/ present them as a browsable catalogue.

For someone who has been through the tutorial stage of web development and can write HTML and JavaScript but has not yet seen a real project from start to finish, that is a genuinely useful gap to fill. Each project shows how a small feature is actually assembled, including the parts a tutorial skips.

The README also asks readers to star the repository before starting work on it, which is an indicator of the project's shape: it is organised around attention and visibility rather than around consumption.

The catalogue structure and how the categories break down

The Projects Catalog section organises everything by category, and the README notes that the full list is also available as a raw projects.json file and explorable on the live site.

The What You'll Find list names six groupings: frontend projects in HTML, CSS, JavaScript, React and Vue.js, backend projects in Node.js, Express.js, Flask and the MERN stack, full-stack applications with both halves, interactive games, utility tools and calculators, and reusable UI components and design patterns.

The category browser in the README breaks this down further with collapsible sections, and the Tool category is marked as holding 87 projects. The featured projects table gives a sense of the range and of the numbering convention, since each project carries a number in the 100-day sequence. The To-Do List is number 1 and rated beginner. The QR Code Generator is number 10 and intermediate. Flappy-bird-game is number 30, Recipe Genie is number 50 and an API project, Resume Studio is number 80, Text Saver Extension is number 100, the App Privacy Policy Generator is number 150, and the Dual-Genre Movie Matcher is number 200 and rated advanced.

The type column in the featured table uses the same vocabulary as the category list, with entries like Tool, Game, API and Web Application.

The difficulty rating is the field with the most teaching value. It tells you what to expect before you open the file, and the progression from a beginner to-do list to an advanced movie matcher with two genres and a matching algorithm is a curriculum in miniature if you work through them in number order.

projects.json, the schema and the validation script

The repository has a data layer, and that is the most reusable part of it.

There is a projects.json file at the root, described in the README as the raw file you can browse, and the README mentions a schema/ directory at the top level. Combined with the validation scripts in package.json, this is a small content pipeline: a manifest of projects, a schema describing what a valid entry looks like, and a script that checks one against the other.

The scripts make the shape clear:

  "scripts": {
    "generate-previews": "node scripts/generate-previews.js",
    "dev": "npx -y serve . -p 3000",
    "validate:projects": "node .github/scripts/validate-projects.js",
    "validate:projects": "node scripts/validate-projects.js",
    "validate:projects-fixture": "node scripts/validate-projects-fixture.js",

Two things stand out. There is a validate:projects-fixture script, which means the validator itself has a fixture, so there is a test for the test rather than a script that only ever runs against the real data and silently stops catching anything. And the generate-previews script is the bridge to the live site, which needs a thumbnail for every project.

The lint-staged configuration ties the validation to the commit, with projects.json wired to the validate:projects script, so a malformed entry fails the commit rather than the site build. The dependency list explains the validator's mechanism: ajv is a JSON Schema validator, which is how the schema directory is applied to the manifest.

If you want to build a similar catalogue, this part is the transferable design: keep the catalogue as data, keep the data separate from the presentation, and validate the data on every change.

Running the site locally

The site is a static bundle at the repository root, with index.html, style.css, theme.js, navbar.js, cursor.js, recommendations.js, hero-terminal.js, a sitemap.xml, a robots.txt, a 404.html, a manifest.json, a stats.html and an ads.txt. The public/ directory holds the individual project demos that the catalogue links to, so a single deployment serves both the index page and the hundred-odd demos it links to.

Because it is plain static files, the dev server is one command:

    "dev": "npx -y serve . -p 3000",

There is a Docker path as well, with build, run, up and down targets:

    "docker:build": "docker build -t 100days-web .",
    "docker:run": "docker run --rm -p 8080:80 100days-web",
    "docker:up": "docker compose up --build -d",
    "docker:down": "docker compose down",

The run target publishes port 8080 to port 80 in the container, and the compose targets manage a longer-lived deployment.

The remaining scripts are for quality. The lint script runs ESLint with an explicit configuration lookup, and lint:all runs htmlhint across every HTML file in the repository with node_modules ignored, which matters in a catalogue made mostly of HTML. The format script is Prettier with the repository's own config. The prepare script installs husky, so the lint-staged hooks are wired up on install.

The site's own interface, and the supporting files

The site itself is one of the more interesting projects in the repository, and reading its JavaScript is arguably as instructive as any of the listed demos.

The README describes the site as having an interactive project index, search functionality to find specific projects, direct links to all project demos, a dark and light theme toggle, and a responsive design for all devices. The files match that description: theme.js for the toggle, navbar.js for navigation, cursor.js for the cursor behaviour, hero-terminal.js for the animated hero, and recommendations.js for suggesting related projects.

The Recommendations directory and the learning/ directory are the parts that turn the repository from a list into a course. The Table of Contents includes a Learning Path section and a Technologies Used section, and a Reading_Tracker directory at the root suggests the workflow is trackable, with tracker.html and tracker.css at the root for a reading tracker and a scripts/ directory behind it.

There is also a stats.html and a contributors/ directory, and the schema/ directory referenced by the validation script. The scripts/ directory holds the generators, and .github/ holds the automation including the second copy of the validation script.

The theme toggle and the responsive layout are implemented by hand in vanilla JavaScript, which is consistent with the catalogue's premise that you read the code to learn it.

Where this repository is the wrong resource

Three limits are structural. The first is that none of this is a dependency. These are teaching artefacts, and the README's framing is a collection to browse, not a library to install. If you need a QR code generator in your product, taking one from here means copying code you did not write, with no maintenance commitment, no test coverage and no changelog, into a codebase that now depends on an anonymous contributor's decisions. That is a legitimate way to learn from and a poor way to ship.

The second is that the quality bar is uneven by nature. Two hundred and eighteen projects written at different times by different people, with difficulty ratings that are the author's own estimates, means the interesting ones are the exceptions. The catalogue can tell you that the Dual-Genre Movie Matcher is advanced; it cannot tell you whether the code is good.

The third is the metadata itself. The repository description says to star the repo before starting work on it, and the README asks readers to do the same. There is also an ads.txt file, which is the advertising declaration file for a site, and a live site hosted on Vercel. None of that is disqualifying, but it does tell you what the project is optimised for, and it means the artefacts are shaped by attention rather than by long-term usefulness.

On the licensing, there is a discrepancy worth resolving before you reuse anything. GitHub classifies the repository licence as Other, a custom licence the platform cannot map to a known identifier, and the LICENSE file at the root is the authoritative text, while the package manifest declares MIT. Those two statements conflict, and for a repository whose value is that people copy from it, which one applies is the first thing to check.

The alternative resource, and the honest comparison, is a single well-documented project you read end to end with a maintainer answering questions. The catalogue is better for breadth and for matching your current level, and worse for depth, for code quality and for the ability to ask what anything means.

Editorial conclusion

The repository suits a developer who learns by reading complete small implementations, since each project is a self-contained thing you can open, run and understand in one sitting, with a difficulty label and a live demo to compare against. It is the wrong tool if you need a maintained library or a starter template, since nothing here is designed for reuse and the projects exist to be read. Verify first that the catalogue entry you care about is in projects.json, since that manifest is what the validation script checks and what the site reads, and note that the last push was on 2026-09-25 with no GitHub releases and a custom licence classification despite the manifest declaring MIT.

Frequently asked questions

Official sources

1. dhairyagothi/100_days_100_web_project on GitHub
2. Issues
3. Project website
4. README