Skip to content

About

Source of awssalmubarak.com, a dependency-free static site with a hand-virtualized contributions ledger.

Resources

Stars

1 star

Watchers

0 watching

Forks

Latest commit

 

History

23 Commits

Folders and files

Repository files navigation

awssalmubarak.com logo

awssalmubarak.com

English · 简体中文 · 日本語 · 한국어 · Русский

licence live at awssalmubarak.com

The ledger · The builds page · How it works · Run it · Tests · Layout · License


The home page


The source of my personal site. It's a static site with no runtime dependencies and no framework, generated by a small Python standard-library pipeline. Its contributions page stays smooth whether it lists twenty merged pull requests or twenty thousand, and its builds page only runs the previews you're looking at, however many builds it lists.


The virtualized ledger

The contributions page is a record of every merged pull request I've made. At the scale I'm heading toward that's tens of thousands of rows, so the list is virtualized by hand in plain JavaScript. Only the rows near the viewport are in the DOM, a repository's pull requests are built only when you expand it, and search is debounced and filters the data instead of rebuilding the page on every keystroke.

Here's what that's worth, measured against a version that renders every row at once, with 2,500 repositories and 13,724 merged pull requests:

Naive (render everything) Virtualized (this site)
DOM nodes 127,306 281
Re-render one sort 279 ms 3 ms
Time to interactive 534 ms 312 ms

You don't have to take the numbers on trust. bench/ regenerates them on your own machine, see the benchmark.

The contributions ledger


The builds page

The builds page shows each tool I've built with a preview of it in a window that says what it is. A command-line tool runs in a terminal, and a website runs live in a browser window. Clicking a preview opens it large. On desktop the title stays put and only the builds scroll under it.

A live preview is a whole web page, so a page of them gets heavy fast. The browser's own lazy loading only decides when a download starts. It never unloads anything, and browsers have no lazy loading for video at all. So the builds page loads its previews through a media scheduler written in plain JavaScript.

  • Every preview starts as a still image.
  • A preview goes live once it's mostly in view and has stayed there for a quarter of a second. At most two are live at once.
  • A preview that scrolls far away goes back to its still, which frees its page or its video.
  • Videos pause while they're out of view, and everything waits while the tab is in the background.
  • Anyone who asks for reduced motion or less data gets the stills only.

Here's what that's worth with 300 builds, scrolling the whole list at a constant speed, measured against loading everything at once and against the browser's lazy loading:

Load everything Browser lazy loading Scheduler (this site)
Downloaded on open 38.6 MB 12.7 MB 0.47 MB
Live previews at once 75 75 2
DOM nodes at most 29,037 29,037 6,763
JS heap at most 31.8 MB 29.1 MB 3.6 MB

The benchmark measures this on your own machine too.

The builds page


How it works

The site is generated, not maintained by hand. Each merged pull request is one small markdown file in data/entries/. bin/site_data.py reads them and writes data/contributions.json, and bin/build_pages.py inlines that data into three pages, so each one loads with no requests beyond a stylesheet and a font. bin/deploy.py publishes the built pages to GitHub Pages. Each repository's star count lives once in data/stars.json and bin/refresh_stars.py pulls every count from GitHub, so no count is copied into an entry or left to drift.

  • No framework and no build tooling. All you need is Python and a browser.
  • Three themes, switched from the swatches in the top right, built on CSS custom properties.
  • Generative SVG backdrops drawn in the browser: meshing gears on the home page, a git merge-graph behind the ledger, a drafting blueprint behind the builds.
  • A Content-Security-Policy on every page, and every URL that comes from data is validated before it reaches an href.

The three themes

violet slate nordic
violet slate nordic

Run it

python3 bin/site_data.py        # entries to data/contributions.json
python3 bin/build_pages.py      # data to the three pages in site/
python3 -m http.server --directory site

Then open http://localhost:8000.


Tests

python3 -m unittest discover -s tests

They cover the pipeline and the pages.

  • A rebuild is reproducible, and the stats have the right shape.
  • A new entry increments the sequence and lands in the output.
  • The built pages carry the security hardening and the virtualized list.
  • The builds page loads its previews through the scheduler, and builds are ordered by stars.
  • Both benchmarks still build their pages from the current templates.
  • Every translation matches its English source.

Layout

bin/     the pipeline, reads entries, builds pages, deploys
data/    one markdown file per merged PR, plus the per-repo star counts, the builds and the featured picks
site/    the three page templates, the shared stylesheet and script, the built output
bench/   the reproducible performance benchmarks and the server that measures the builds page
tests/   the pipeline tests

License

MIT, see LICENSE.

About

Source of awssalmubarak.com, a dependency-free static site with a hand-virtualized contributions ledger.

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages