logo

mdn/fred

MDN's frontend since late 2025, built with Web Components, Lit, and SSR for a fast, clean documentation experience. Fred = /fr(ont)e(n)d/.

Hosted by Mozilla

View on GitHub ↗Jump to charts ↓Open shareable report →

mdn/fred has 200+ stars and 60+ forks on GitHub, is written in JavaScript, and was last pushed on Oct 16, 2026. Data as of . Signed-in members get hourly updates — create a free account.

Summary Information

Updated 24 minutes ago
Type:FrameworkCategory(s):Frontend FrameworksCMS, Static Sites & ForumsWeb Development
Added to GitGenius on October 12th, 2026
Created on March 13th, 2025
Open Issues & Pull Requests: 142 (+0)
GitHub issues: Enabled
Number of forks: 67
Total Stargazers: 237 (+0)
Total Subscribers: 7 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 21.7 hours
Mean response time: 28.5 days
90th percentile: 96.7 days
Tracked items: 361

Most active contributors

Sign in to see contributor activity.
Sign in

Related repositories by overlapping contributors

Maintainer activity

13 people did triage or write work on this repository in the last 12 months.

Counts unlabeled, assigned, unassigned, milestoned, demilestoned, locked, unlocked over the last 12 months. These are issue and pull request events that require triage or write permission. Commits and code review are not counted. labeled and renamed are excluded because GitHub issue forms record the issue author as the actor. Figures from October 18, 2026. This count is not comparable across projects: each project's automation decides which of these events a person emits. How this is counted.

How this project is maintained

About 12% of issues opened in the past year have never received a reply. 68% of open issues come from outside the core team, a mix of external reports and the maintainers' own roadmap. Work labelled "p0" is answered fastest, typically in under an hour, while "a11y" waits about 27 hours. 63% of tracked open issues have had no activity in three months, so the open count overstates what is actively being worked. 68% of issues opened in the past year have been closed, leaving a working backlog.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 106
New in 7 days: 3
Closed in 7 days: 5
Avg open age: 443 days
Stale 30+ days: 89
Stale 90+ days: 77

Recent activity

Opened in 7 days: 1
Closed in 7 days: 4
Comments in 7 days: 1
Events in 7 days: 7

Top labels

  • p1 (214)
  • needs triage (35)
  • a11y (19)
  • p0 (16)
  • blocked (7)
  • needs content decision (7)
  • qa-verified (5)
  • good first issue (3)

Most active issues this week

Sign in to see which issues are moving.
Sign in
Explore full issue details

Detailed Description

Fred is a frontend framework built with Web Components, Lit, and server-side rendering that powers MDN's documentation site.

The project addresses the need for a fast, clean documentation experience by combining Web Components for modular, reusable UI elements with Lit for efficient rendering and server-side rendering for performance. The architecture supports inline JavaScript execution to prevent layout shifts during page load, with automatic Content Security Policy hash generation during production builds. Development relies on a rari server for content serving alongside a live-reloading development environment, with separate commands for local development, production preview testing, and bundling workflows.

Developers should adopt Fred if they are building documentation sites or content-heavy applications where performance and browser compatibility matter. The tool targets the Baseline widely available browser set, supporting Safari, Chrome, Edge, and Firefox releases from the last two and a half years, plus Firefox ESR versions. The project includes localization support through a dedicated l10n system and provides environment configuration for testing across different platforms and devices, including mobile and tablet access via HTTPS with self-signed certificates. Developers working on MDN or similar large-scale documentation platforms will find the established development principles and testing infrastructure most relevant.

The project maintains active development with structured testing practices documented in a dedicated testing README. Development follows clear browser support policies aligned with industry standards rather than arbitrary version cutoffs. The codebase emphasizes graceful degradation for unsupported browsers while prioritizing accessibility issues across all supported platforms. Environment configuration is centralized and documented, reducing friction for contributors setting up local development environments.