DEV Community

Bryan Hamilton
Bryan Hamilton

Posted on

10 Production-Extracted Repos, Zero Dependencies

I run The DJ Calendar — a site that tracks electronic music events for about 214,000 people. It's built with PHP and vanilla JavaScript. No frameworks, no build step, no npm install.

Over the years I've extracted the patterns I'm proudest of into standalone repos, each with a live demo, CI, and its own README. Here's the full catalog.

The Philosophy

Every repo here follows the same rules:

  • Zero dependencies. No npm, no Composer, no CDN script tags. Drop the file in your project and it works.
  • Extracted from production. Every pattern was running on a live site first. Nothing was written for the sake of a demo.
  • Accessibility built in. Reduced-motion respect, keyboard navigation, ARIA attributes, consent-first geolocation — not bolted on later.
  • CI-tested. Every repo has a GitHub Actions workflow that validates the code.

1. dj-card-preview

GitHub | Live Demo

Hover over an artist card and hear a 30-second iTunes preview. The audio plays through a Web Audio API analyser (fftSize: 64, smoothing: 0.8) that drives an 8-bar canvas equalizer in real time.

What makes it interesting: the autoplay gate. Browsers block audio until the user clicks once, so the first hover primes a one-click unlock. After that, every hover fires an iTunes Search API lookup (entity=musicTrack, limit=12), grabs the preview URL, and starts the analyser. A generation-counter race guard prevents stale responses from overwriting the current playback.

Also includes: mediaSession integration (lock screen controls), document.title swap, reduced-motion early return, and a 75% black overlay with "You are now listening to:" label.

2. instant-search-index

GitHub | Live Demo

A client-side search system that works from a prebuilt JSON index. No Algolia, no Elasticsearch, no server endpoint — just a JSON file and ~200 lines of JavaScript.

The index is generated at build time (a PHP script crawls the artist database and writes a flat JSON file). On the client, the search function runs scored AND/OR matching across weighted fields (name scores highest, genre and location lower). Results render in an ARIA combobox with keyboard navigation, Escape-to-close, and focus trapping.

This was the feature I was proudest of on bryanhamilton.info — a search that feels instant because it is. No network request, no loading spinner, no debounce dance.

3. next-show-radar

GitHub | Live Demo

A geolocation-aware tour map. It asks for the user's location (consent-first — no nagging), calculates haversine distances to upcoming shows, and plots the nearest ones on a Leaflet map.

The consent pattern is worth studying alone: the map loads with a "Find shows near me" button. Nothing happens until the user clicks it. If they deny geolocation, they get a text list instead. Race-safe Leaflet boot prevents the map from initializing twice, and the whole thing works without a single third-party script tag beyond Leaflet's own CSS.

4. tour-feed-pipeline

GitHub | CI Status

The backend counterpart to the radar. It ingests tour data from Bandsintown and Ticketmaster, normalizes both feeds into a single row shape, deduplicates overlapping events, caches aggressively, and prunes stale entries.

Written in PHP 8 with zero Composer dependencies. CI-tested with PHPUnit against the actual production library code — not mocked abstractions. The test suite taught me a hard lesson about testing production-verbatim code: your tests need to match the library's actual behavior, not what you imagine the contract to be.

5. eq-visualizer

GitHub | Live Demo

An 8-bar sensory equalizer that renders in pure CSS. Zero JavaScript required to display it — the bars are just divs with staggered animation delays. An optional 1 KB injector script adds Web Audio reactivity.

This repo holds the line on an important principle: visual effects should degrade gracefully. If JavaScript fails, the EQ still animates. If the user prefers reduced motion, it freezes at full height. No broken UI states.

6. sri-lazy-loader

GitHub | Live Demo

A race-safe lazy script loader with Subresource Integrity. If two components request the same script simultaneously, only one network request fires. Subsequent callers get the same promise. Timeout and cleanup are built in.

The pattern I extracted from a production pain point: The DJ Calendar's artist pages load different widgets depending on the artist. Without a loader, widgets would trample each other's script tags. With this, each widget calls loadScript() independently and the deduplication handles the rest.

7. event-calendar-schema

GitHub | Live Demo

A PHP library that generates valid schema.org Event JSON-LD. It handles sameDay date detection (no more "through Feb 3" when the event is one day), geo-coordinate injection, and performer-by-type resolution.

This is the library that powers The DJ Calendar's structured data — every event page on the site runs through it. I extracted it because I was tired of rewriting the same JSON-LD boilerplate for every new project.

8. jsonld-schema-audit

GitHub | Live Demo

A PHP tool that validates JSON-LD against schema.org shapes and audits structured data across your entire site. It crawls your pages, extracts every <script type="application/ld+json"> block, and reports errors, warnings, and missing properties.

Built because Google's Rich Results Test only checks one URL at a time. When you have hundreds of event pages, you need bulk auditing.

9. wp-schema-audit

GitHub | Live Demo

A WordPress plugin version of the same idea. It adds a Schema Audit page to the WordPress admin, scans every post and page for JSON-LD, and flags issues. Zero-config — activate and run.

10. csrf-json-fetch

GitHub | Live Demo

A lightweight fetch wrapper that automatically injects CSRF tokens into every request. Tokens are read from a meta tag, rotated on each session, and validated server-side. Error handling is baked in — network failures, non-JSON responses, and 403s all produce typed error objects instead of silent failures.

What I Learned Extracting Production Code

  1. Your production code has hidden dependencies. The first extraction always fails because you forgot the utility function living in a sibling file. That's fine — it forces you to write standalone utilities.

  2. Tests reveal the truth. The tour-feed-pipeline taught me that my mental model of the code was wrong in three places. Only the test suite caught it.

  3. Zero dependencies is a constraint that improves code. Without npm, you can't reach for a library. You have to write the 20-line function yourself. Nine times out of ten, that's the right call.

  4. Live demos matter more than READMEs. Every repo has a GitHub Pages demo. People trust what they can interact with.

What's Next

I'm still extracting. The DJ Calendar has patterns I haven't touched yet — the city map system, the email newsletter pipeline, the caching layer. Every extraction makes the parent site better because the extracted code gets hardened, documented, and tested.

All 10 repos live under github.com/bryanhamiltondev. The full portfolio is at bryanhamilton.info.

If any of these patterns save you a weekend of work, that's exactly why I extracted them.

Top comments (0)