bradtraversy/50projects50days: 50+ Mini Web Projects in Plain HTML, CSS and JavaScript

What 50projects50days actually contains

The README describes the repository as "the main repository for all of the projects in the course" and links to a paid course page at traversymedia.com. The repository itself is the code side of that course: a flat list of numbered folders, each named after the thing it demonstrates. The top-level entries run from 3d-boxes-background and animated-countdown through pokedex, quiz-app and sound-board to verify-account-ui, plus a _project_starter_ folder that appears to be the blank template the course uses for new work.

Each folder is a small, finished page. The README pairs every entry with a live demo host at 50projects50days.com, so you can see the intended behaviour before reading any code. The projects are deliberately narrow in scope: one interaction, one layout trick or one small API call per folder. Expanding Cards, Progress Steps, Hidden Search Widget, Scroll Animation, Split Landing Page and Sticky Navbar are pure HTML and CSS with a few lines of JavaScript to toggle a class. Dad Jokes, Movie App, Github Profiles and Pokedex fetch data from public endpoints. Drawing App, Notes App, Todo List and Quiz App keep state in the page while it is open.

That narrowness is the point. There is no shared stylesheet, no shared utility module and no package.json at the root. Copying one project out of the repository gives you a working page and nothing else to untangle.

How the projects are structured and how data moves

The architecture is the browser's default one, repeated fifty-odd times. A folder holds an index.html that links a style.css and a script.js. The HTML carries the markup and any static text, the CSS holds all presentation including keyframe animations, and the JavaScript attaches listeners to the elements the HTML declares and mutates classes, text content or inline styles in response.

For the interactive-only projects the data flow is a closed loop inside one page: a click, a scroll or a keypress fires a handler, the handler changes a class or a style property, and CSS transitions do the visible work. The scroll-animation and incrementing-counter folders are the clearest examples, since the JavaScript there does little more than add a class when an element enters the viewport or advance a number on a timer.

A smaller group adds one outbound request. Dad Jokes, Movie App, Github Profiles and Pokedex call third-party HTTP endpoints and render the response into the DOM. That means those folders depend on services outside the repository staying available and on their response shapes staying stable. The README does not document which endpoints are used, what rate limits apply, or whether an API key is required, so you have to read the JavaScript in each folder to find out. Nothing here uses a bundler, a module loader, a framework or a state container, and there is no build step to run.

Running a project locally: clone, open, edit

The README gives no installation section. It points to the course link and to per-project live demos, and the repository layout suggests the intended workflow is to clone the repository and open a project folder directly. Because every project is plain HTML, CSS and JavaScript with no dependencies, no package manager entry and no server requirement, opening the HTML file in a browser is enough for the projects that do not fetch remote data.

The README links each project folder on GitHub, for example the expanding-cards directory at https://github.com/bradtraversy/50projects50days/tree/master/expanding-cards. Open that folder and you find index.html, style.css and script.js. Open index.html in a browser and you should see the expanding cards panel: clicking a card widens it and dims the others. For the projects that call an external API, such as movie-app, github-profiles and pokedex, a browser may restrict requests made from a file:// page, so serving the folder over HTTP is the safer route. The README does not state this, but it follows from the fact that those scripts issue network requests. If you want to start a new exercise from scratch, _project_starter_ is the folder to copy.

What this repository is not good for

The projects are teaching artefacts, not a codebase. There is no shared runtime, so a fix or a convention you apply in one folder does not reach the other fifty. There is no test suite, no lint configuration at the root and no continuous integration described in the README, which means nothing catches a regression when you edit a project. The README documents no versioning scheme and no upgrade path, so there is no supported way to pull in improvements to an individual project after you have copied it.

The external-API projects are the fragile ones. Movie App, Github Profiles and Pokedex depend on endpoints the README does not name, and the repository does not document keys, quotas or fallback behaviour. If an endpoint changes shape or starts requiring authentication, the page breaks and the fix lives entirely in that folder's script.js. The GitHub Profiles project also fetches user data by username, which is fine for a demo and unsuitable as a pattern for anything that handles real accounts.

Accessibility is largely unaddressed. The README makes no claim about keyboard support, focus management or ARIA attributes, and the projects are built around pointer and scroll interactions. If you need a component that passes an audit, take the visual idea and rebuild the interaction yourself rather than lifting the folder.

Compared with a component library or a tutorial series

The obvious alternative is a component library such as Bootstrap or a CSS framework, and the difference is one of intent. A component library gives you finished, documented, versioned widgets that you drop into an application and upgrade on a release schedule. 50projects50days gives you unfinished, undocumented, unversioned examples that you read to understand how an effect is built. Bootstrap answers "what should this button look like"; this repository answers "how does a button ripple effect work".

A second alternative is a structured tutorial series or a course with exercises and grading. That gives you a sequence, a difficulty curve and feedback. This repository gives you the artefacts without the sequence: the README lists projects in a numbered table, but it does not state prerequisites, order of difficulty or which project builds on which. The course link suggests the sequencing lives behind the paywall, and the repository is the code appendix to it.

If your goal is to ship a feature this week, use a library. If your goal is to be able to write the effect yourself next month, read these folders and retype them.

Maintenance, licence and the cost of keeping a copy

The repository is not archived. The README gives no release history and the material retrieved shows no releases, so there is no versioned artefact to pin and no changelog to read. If you fork it or copy folders into your own work, you are taking a snapshot with no upstream upgrade channel, and any later fix has to be merged by hand.

The licence is MIT. That permits use, copying, modification and redistribution, including in commercial work, provided the copyright notice and permission notice are kept with the copy. It also means the projects come with no warranty. The LICENSE file sits at the repository root, so keep it alongside any folder you redistribute rather than deleting it when you copy a single project out. This is a description of what MIT states, not legal advice; if the licence matters to your organisation, have someone qualified read it.

The practical maintenance cost is low per project and high across the set. Each folder is small enough to audit in a few minutes. Fifty of them, with no shared conventions and no tests, is a different proposition. Treat any folder you adopt as code you now own.

Editorial conclusion

Adopt this if you are learning front-end fundamentals and want small, complete examples you can open in a browser without a build step, or if you teach and need a ready set of exercises. Do not adopt it as a production codebase or a component library: the projects share no runtime, no module system and no test suite, and the README documents no versioning or upgrade path. Before you rely on any single project, open its folder, read that project's own index.html, style.css and script.js, and check whether it calls an external API (the Movie App and Github Profiles entries do) or ships assets you would have to replace. The licence is MIT, so reuse inside your own work is permitted; keep the LICENSE file with any copy you redistribute.

Frequently asked questions

Official sources

1. Official README
2. Project repository