Yeti 7 replaces Foundation 6 rather than upgrading it
Yeti 7 is a new framework, while Foundation for Sites 6 remains on its own branch. The maintainers describe Yeti as a reimagining rather than a port. The old Sass and JavaScript architecture stays on the v6 branch, with the foundation-sites npm package continuing there. Yeti starts over around current browser features: container queries, cascade layers, native nesting, dialog, popover, light-dark(), and scroll snap. That split matters because an existing Foundation site cannot treat version 7 as a routine dependency update.
The new surface is smaller and more opinionated. The README lists 17 layout primitives, 3 composed recipes, 22 components, 7 utilities, and 2 example themes. Most of it arrives as one stylesheet. Optional JavaScript modules add behavior such as dialog focus return, tab keyboard movement, carousel dots, validation messages, and table-of-contents tracking. A site may load individual modules or the combined file, which the installation guide describes as about 9 KB compressed.
Seventeen layouts respond to their containers
Yeti's 17 layouts respond to their own boxes instead of treating viewport width as available space. A sidebar, grid, or columns block can therefore adapt inside different page regions. The layouts guide puts intrinsic layout first, container queries second, and media queries last. That choice suits cards and sidebars that move around a page, where a conventional viewport breakpoint can fire while the component itself still has too little room.
The markup uses named classes plus a limited vocabulary of data-* values. Tokens control type, spacing, color, corners, and widths, while cascade layers let a site's unlayered CSS win without specificity tricks. Yeti also generates editor completion data, TypeScript declarations, llms.txt, and a machine-readable manifest from the same source. The stability guide says 49 manifest names, public token names, module filenames, event names, and package exports are frozen from 7.0.0-beta.0.
Three files give Yeti three different release states
Three files disagree about the snapshot's release state. The README calls Yeti 7.0.0-beta, the package manifest at commit 4577f24 says 7.0.0-alpha.0, and the installation guide says Yeti is not released, has no npm package, and offers nothing to download. The guide tells early testers to clone the repository and build dist/ themselves. That is enough for an experiment, but a production team should not have to decide which of 3 status descriptions governs support.
The public surface may be frozen, yet defaults, generated files, fixtures, browser minimums, and private tokens may still move before 7.0.0. The package manifest also requires Node 24 or newer for repository work. None of that affects a finished stylesheet loaded by a browser. It does affect anyone pinning a commit, contributing a fix, or building an internal package before the official artifact exists.
What happened when we ran it
Our measurement setup used a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. It cloned commit 4577f24 with 640 files, about 14,219 lines of source, and an 8.4 MB checkout. npm installed 14 packages in 7 seconds and occupied 44 MB on disk. The build then succeeded in 6 seconds. The npm audit reported 0 known vulnerabilities. These results cover repository setup and compilation, not rendering speed or behavior in production browsers.
The supplied tests failed with exit code 1 after 9 seconds. The final error was ENOENT: a test attempted to open /work/repo/docs/guides/markup.md, but that path was absent. The log tail then reported failing tests without giving a different root error. We cannot tell from that output whether the missing file should have been generated, committed, or referenced elsewhere. The useful finding is narrower: this exact commit built, while its test command did not finish green in our fresh Debian container.
Baseline 2025 and FSL exclude two common buyers
Baseline 2025 is Yeti's browser floor, and features available by the end of 2025 may be used without guards. Newer features get @supports fallbacks, but older browser support and polyfills are outside the job. That is a clean rule for a new internal tool or publication. It is a poor fit for a customer product carrying older managed browsers, since the framework intentionally declines that compatibility work.
The other boundary is commercial reuse. Yeti uses FSL-1.1-MIT, which permits normal site and product use but forbids offering the software as a competing product or service. Each release changes to MIT on its second anniversary. Foundation for Sites 6 stays MIT. Most teams building websites will never approach the restriction; a theme platform, framework vendor, or hosted page-builder company should have counsel map its product against the license before adoption.
An October 3 push matters more than the 2024 release page
The repository was pushed on October 3, 2026, the date of the commit we measured, and recent commits include documentation, token, navigation, and browser-test work. GitHub reported 29,800 stars and 81 combined issues and pull requests. Those stars and much of the issue history came with the renamed Foundation repository, so they show the project's lineage rather than 29,800 Yeti adopters.
GitHub's latest release endpoint still returns Foundation v6.9.0 from September 27, 2024. That stale tag does not mean current development stopped: the October 3 push and September Yeti announcement show the opposite. It does mean Yeti lacks a release artifact that matches the new default branch. Run a pinned evaluation if its layout model appeals to you, but keep the trial separate from a production design-system commitment until the package status, documentation, and test result agree.