frontend-dev-bookmarks: a curated frontend list whose last push was 2024-05-21

The file says it receives ongoing updates; the last commit is dated 2024-05-21

The stalest fact about this repository is also its most quotable. The opening text says this is the current version, which receives ongoing updates, and the project presents itself as a manually curated collection of resources for frontend web developers. The commit record says otherwise. The last push to the default branch master is dated 2024-05-21, and the only release in the history is a tag named v.1.0 carrying the description Version of 2015, dated 2016-05-21. For a document whose entire value is a set of URLs, the commit date is the only freshness signal on offer, and there is no per-entry date, no link checker output, and no record of which pages have since changed. The consequence for a reader is blunt. Treat the sentence about ongoing updates as a statement of intent and 2024-05-21 as the date after which nothing in the file was reviewed.

The v.1.0 tag is offered as the good old bookmarks, and warned about in the same breath

The project keeps a tagged snapshot and points at it explicitly: if you want the good old bookmarks, please use the tag v.1.0, and keep in mind that the old version has many outdated links. Both halves of that instruction matter. The tag is the only release the repository has, it is a decade old, and the project's own warning is to expect dead links inside it. A reader is therefore left with two options and no verified one. Take the tag and accept the rot just described, or take master and accept that nothing has been reviewed since 2024-05-21. The invitation to proceed to the totally gigantic file if that is your kind of thing has the same shape, since volume is offered as the alternative to curation. Nothing in the repository identifies which individual links still resolve, so whichever version you open, the verification is yours to do.

Every resource is written twice, once in a category file and once in the giant file

The browseable version is split by category across many small files, and the root holds README.md, TOTALLY-GIGANTIC-FILE.md, about.md, contributing.md, and one directory per category, among them appearance/, architecture/, compatibility/, ecosystem/, languages-protocols-browser-apis/, user-interface-components/, and workflow/. Inside each, an entry is a linked file with a one line description, for example appearance/animation.md described as the process of creating motion and shape change, or compatibility/keyboard.md described as working with keyboard input in a web browser. The second representation is the single page file holding every resource at once. The cost is duplication with no mechanism to reconcile it. The root contains only markdown and category directories, with no generator or link checker among the top level entries, and the curation is manual. A link corrected in one copy can stay wrong in the other, so searching the giant file and browsing the category pages are not the same search.

Categories are defined in prose, so membership cannot be diffed without reading English

Each section opens with a definition before it lists anything. Compatibility is the ability of a product to work with different input and output devices and rendering software, including printers, email, mobile devices and different browsers. Architecture is high level structure of the frontend code and the discipline of creating such structures. Ecosystem is important developers, companies, organizations and news sources. The entries inherit the same treatment, so Cross Browser is described as the ability of a website, web application, HTML construct or client-side script to function in environments that provide its required features and to bow out or degrade gracefully when features are absent. That phrasing is the curator's rather than a standard's, and it is the closest thing to commentary anywhere in the project. The consequence is structural: a category here is a paragraph plus a file tree, not a table. Nothing in the repository can be queried, sorted, or diffed mechanically, so comparing two versions means reading prose.

Design Patterns and Notable Community Members share a format and decay at different speeds

One bullet format, a linked file name followed by a colon and a line of gloss, is used for a design patterns reference and for a list of people. Under Architecture sit Algorithms, Design Patterns, Designs, Event-Driven Programming, Functional Programming, and Functional Reactive Programming, each defined as a discipline. Under Ecosystem sit Communities Around Projects, News, Notable Community Members, Organizations, and Podcasts, each defined as a kind of thing. The taxonomy treats them as equals because the format does, and the format has nowhere to record when an entry arrived. That matters because the two halves age differently. A design patterns page or a fundamentals page changes slowly. A news site, an organizations list, and a roster of notable community members change as sites change owners and people change jobs, and nothing marks which entries were looked at recently. A reader taking a link from Ecosystem is on weaker ground than one taking a link from Architecture, and the file does not say so.

One folder holds CSS, DOM, HTTP, JSON, SVG, and Service Workers, each glossed by its own definition

Languages, Protocols, Browser APIs is a single category whose description is programming and mark-up languages and web related standards. Inside it sit a stylesheet language, a markup language, an application protocol, a data interchange format, a programming interface, a vector image format, and a background processing method: Cascading Style Sheets, HyperText Markup Language, Hypertext Transfer Protocol, JavaScript Object Notation, Document Object Model, Scalable Vector Graphics, and Service Workers. Each entry carries the specification's own abstract, phrased as a definition rather than as guidance, so JSON is described as a lightweight format that is easy for humans to read and write and easy for machines to parse, and CSS as describing how elements should be rendered on screen, on paper, in speech, or on other media. The result is a decent index of where the specifications live and a poor index of how to apply them. Nothing in the category records which revision a link points at.

No license file at the root, and no in-repo route for reporting a dead link

The repository root holds README.md, TOTALLY-GIGANTIC-FILE.md, about.md, contributing.md, and the category directories. No license file sits among them, so the terms for copying the curated text or rebuilding it into a site of your own are not stated anywhere in the project, even though the collection is meant to be passed around. The header does follow the awesome list convention by linking to sindresorhus/awesome, which is a community norm rather than a grant of rights. The same gap shows up in upkeep. The project names where to find itself, a Gitter room at gitter.im/dypsilon/frontend-dev-bookmarks, a Twitter account at FrontendDir, and a directory at frontend.directory. All three sit outside the repository, while the artifact that needs the most maintenance sits inside it and stopped changing on 2024-05-21.

Editorial conclusion

Open this list for its taxonomy rather than its links. The category structure, running from Appearance and Architecture through Compatibility, Ecosystem, and Languages, Protocols, Browser APIs, still maps the shape of frontend work, and every category opens with a definition written in plain English that a newcomer can read without prior context. The links are a separate matter. The last push to the default branch is dated 2024-05-21, the only tag is v.1.0 from 2016 which the project itself describes as having many outdated links, and no entry carries a date of its own, so there is no way to tell a fresh link from a five year old one without opening it. Use it as a map, and check every destination before you pass it on.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes