AwesomeSites: an offline archive of 133 front-end website snapshots

How 133 sites sit across an index repo and 6 numbered packs

The main AwesomeSites repository is an index, not a file store. Its 9 top-level entries are .github, .gitignore, .obsidian, LICENSE, README.md, README_cn.md, autoreadme, screenshot and title.gif. Cloning this repository gives a catalogue and nothing to serve in a browser. The LICENSE file at the index root is MIT and covers the repository structure only, not the site files in the packs.

The actual site files live in 6 numbered pack repositories under the same GitHub account: AwesomeSites-Pack01 through AwesomeSites-Pack06. Each pack is a directory tree sorted by category, with each site in its own subfolder. Some sites have individual repositories rather than a slot in a numbered pack, including AwesomeSites-iconicmints.wsjbarrons.com and AwesomeSites-tjdi-exhibition. The choochooworld.com game, for instance, sits at game/choochooworld.com/ inside Pack01. The most recent commit to the index repository was on 2026-09-10.

The repository's site count is shown as 133 in a badge near the top of the index. That figure is in the badge image rather than the prose, so it can drift from the actual pack contents as new sites are added without a corresponding badge update. Any developer who needs the exact total should check the pack directories.

Files sourced from browser caches: what each pack contains and what it omits

Every site in the packs consists of the files a browser downloaded to render that page: HTML documents, JavaScript bundles, CSS, image assets and web fonts. Server-side code, database queries and build scripts never reach a browser cache, so they are absent from every pack folder.

Each site has been tested and had fixes applied to run in localhost. What those fixes changed is not documented in the index repository or in the packs. Whether fix means adjusting asset paths for a local file system, removing references to external APIs, or patching attributes that caused CORS errors is not described anywhere in the repository.

The collection method also shapes what is missing from any given site. A page whose main content was generated by a server at request time, rather than sent as static HTML, is represented only by what arrived in one browser session. For sites that loaded content through JavaScript calls to a back-end, only the rendered output from that single session is in the pack. No fixture files, no mock data and no server stubs are provided alongside the HTML.

Cloning a pack and the git prefix missing from the README's one code example

To serve the choochooworld.com game from Pack01:

clone [email protected]:ezshine/AwesomeSites-Pack01.git
cd ./AwesomeSites-Pack01/game/choochooworld.com/
live-server

The first line of this block reads clone rather than git clone. No standard shell or Git installation provides a bare clone command, so this line fails with a command-not-found error on any system without a separately installed program of that name. The code block gives no HTTPS alternative for users without an SSH key configured, and it is the only code the index repository provides for getting started.

live-server is not bundled in the packs, and the code block does not show how to install it. Any static file server that serves HTML and assets from a directory works in its place. Once running, the site opens at a localhost address in the default browser.

A developer who wants only a single pack does not need the index repository at all. Each numbered pack is independent and can be cloned directly by its URL. Site folders inside each pack follow the same 9 category names used in the README index.

8 Car entries, 6 Exhibition entries and the rest of the 9-category index

The index names 9 categories: Metaverse, Game, Room, Car, Exhibition, Portfolio, E-Commerce, Space and Other. Car and Portfolio are the most populated in the visible README. Car holds 8 entries from brand campaign sites: Lamborghini, Toyota Gazoo Racing, Volkswagen Mexico, Lusion's exp-gemini, a Renault Twingo launch page, the Xiaomi Mi SU7 page, classics-garage.com and labs.otherlife.xyz.

Exhibition has 6 visible entries: iconicmints.wsjbarrons.com, the tjdi-exhibition 2022, exp-infinite-passerella.lusion.co, vrshow-oss.dt-space.cn, af1hotel.koikreative.com and anumberfromtheghost.com. 2 of those 6 are in individual repositories rather than a numbered pack. Portfolio has at least 16 entries visible before the README text cuts off, covering individual designers and studios such as Bruno Simon, David Hckh, Wearezizo and Brettwilliams.

The full entry count for the remaining 5 categories (Metaverse, Game, Room, E-Commerce and Space) is not stated in the README index. No per-category totals appear anywhere in the index, and the 9 category names are the only grouping system the project uses.

What offline means in practice: CDN dependencies, API calls and session data

Serving a site from a pack means serving it from a local file system. Any reference to an external host in the JavaScript or CSS is not removed by the pack process unless a fix specifically changed it. Modern brand campaign pages commonly load animation libraries, video assets and tracking scripts from CDN hosts by absolute URL. When that URL is no longer live or the provider requires authentication, the script fails silently and the affected section of the page renders as if the script was never there.

Product-launch pages in the Car and Exhibition categories are especially dependent on API calls that populate content at page load. If those endpoints have gone offline, the relevant content areas load empty. The packs do not include static fixtures that substitute for live API responses.

Session state is a separate problem. A page captured from an authenticated browser session shows the content visible during that session. Opening the same HTML files without a matching session cookie produces a different render or a blank content area. The pack contains no documentation on which sites were captured from an authenticated session or which ones load fully from static files alone.

4 contact channels and no written process for adding new sites

The Contact section in the index lists 4 channels for reaching the author: Twitter at @ezshine, YouTube, Bilibili and WeChat. The section says to reach out if you have an interesting site to back up, and offers to crawl it. No criteria for site selection, no expected turnaround and no rule for which pack a site joins are written down anywhere in the repository.

Some entries have dedicated repositories while others are subfolders in numbered packs. The Exhibition category shows both arrangements: iconicmints.wsjbarrons.com and AwesomeSites-tjdi-exhibition each have their own repository, while exp-infinite-passerella.lusion.co and vrshow-oss.dt-space.cn are subfolders in Pack01 and Pack02. What determines which arrangement a site receives is not explained.

Contribution instructions are absent from the repository. A .github directory exists at the index root alongside an autoreadme directory. Among the 9 top-level entries, neither autoreadme nor .obsidian is explained in the README text. A developer forking the collection to add sites has only the existing pack folder structure as a guide, and the process for updating the 133-site badge count after adding new entries is not documented.

Browser DevTools on live sites and the three.js examples as alternatives

When a site still exists on the web, opening it in a browser and using the DevTools Sources panel exposes the same file types a pack contains: HTML, JavaScript, CSS and assets. No clone is required, and the files reflect how the live server currently serves them. The limitation is that sites disappear over time, which is the problem the collection is built to address.

For three-dimensional and WebGL scenes specifically, the three.js repository on GitHub has an official examples directory with dozens of complete multi-file scenes. Those cover three.js only, while the Car and Exhibition packs in AwesomeSites include brand campaign pages built on other stacks and with production design work that the examples directory does not contain.

CodePen's Trending section surfaces community-shared interactive demos. Individual entries there are almost always a single self-contained file, not a directory with separate HTML, JavaScript and asset folders. Studying how a full production site organises its files across those types is not something a CodePen embed provides. For that kind of structural study, the pack folder layout is what distinguishes AwesomeSites from both alternatives.

Editorial conclusion

AwesomeSites suits front-end developers who want to study visually ambitious commercial sites, such as WebGL scenes, scroll animations and product-launch layouts, by serving the pack files and reading the source directly. It is the wrong tool when you need files to incorporate into a published project, because the Notice bars commercial use and places all legal responsibility on the user. Before settling on a specific site, clone the pack, serve the folder, and check the browser console for network errors, since sites with external CDN dependencies or live API calls load partially or silently incomplete.

Frequently asked questions

Official sources

1. ezshine/AwesomeSites on GitHub
2. Issues
3. License: MIT
4. README