From-Scratch Build · Academic Web
The single-page website a research paper deserves — title, authors, abstract, figures, equations and a video, all on one clean, fast page. Rebuilt from scratch to understand how a modern academic project page is authored and shipped.
What it is
When a research paper comes out, it usually gets a project page: a single, polished web page that summarises the work, shows the key figures, renders the important equations, links to the PDF and code, and often embeds a short video. This build is a reusable template for exactly that page — write the content once in Markdown, and get a fast, accessible site out the other end.
I built it to learn the gap between "a paper" and "a paper people actually click on." The content is the easy part; the interesting work is the toolchain that turns plain prose into a typeset, image-optimised, automatically-deployed page without me hand-writing a line of HTML.
The core idea I wanted to learn: separate content from presentation. The author writes Markdown with a handful of rich components; the build system handles typography, math rendering, image compression and deployment. Change the words, push, and the live page updates itself.
The stack
The point of this rebuild was the toolchain. Here is what each piece does in turning Markdown into a finished page.
A modern framework that ships almost no JavaScript by default. It renders the page to plain HTML at build time, so it loads fast and works without a server.
The page is written in Markdown, but you can drop in rich components mid-prose — a figure, a table, a video — without leaving the document.
Equations are written in LaTeX and typeset in the browser, so the math on the page looks exactly like the math in the paper.
Reusable blocks for figures, comparison sliders, carousels, embedded video and even 3D objects — the visual vocabulary a paper needs.
Figures are compressed to a modern format and served at the right size for each screen, and PDF figures are auto-converted to images. The page stays light.
Every push to the main branch triggers a workflow that builds the static site and publishes it to GitHub Pages. No manual deploy step.
How it works
The whole point is that authoring stays simple while the build does the heavy lifting. The flow from text to published site is short and repeatable.
Edit one Markdown file — title, authors, abstract, sections — dropping in components wherever a figure, equation or video belongs.
Rich blocks for figures, tables, columns, tabs, carousels and media give the page structure without hand-written HTML.
LaTeX expressions are rendered to crisp equations as part of the build, matching the paper exactly.
Images are compressed and made responsive, PDF figures become images, and fonts are tuned to avoid layout shift.
The generator outputs a plain, fast, SEO-friendly site — just files, no running server required.
A GitHub Actions workflow rebuilds and republishes to GitHub Pages every time the main branch changes.
Why it matters
A good project page does real work for a paper, and each design choice here serves that:
In my rebuild I focused on the authoring-to-deploy loop: write the content in one file, preview it locally, push, and watch the workflow publish the finished page — proving the separation of content and presentation actually holds end to end.
Reflection
git push, you actually keep the page up to date instead of letting it rot.