HN Debrief

CSSQuake

  • Programming
  • Developer Tools
  • Web
  • Gaming
  • Open Source

CSSQuake is a playable Quake recreation that uses CSS 3D transforms and DOM elements to draw the world in the browser. It is not Quake magically running in pure CSS. The game logic is TypeScript, and the build process extracts data from QuakeC and progs.dat into JSON facts the browser runtime consumes. That framing mattered because a lot of the first reactions assumed either a full port or some deeper abuse of CSS than what is actually happening.

Treat this as a proof-of-possibility for the browser rendering stack, not a template for product architecture. If you build anything unconventional on web primitives, test early across rendering engines because Chrome, Firefox, and Safari can behave very differently even on the same hardware.

Discussion mood

Strongly positive and amused. People were impressed by the technical audacity and the nostalgia hit, while the main complaints were jank, browser-specific bugs, and the obvious mismatch between CSS and high-performance game rendering.

Key insights

  1. 01

    Quake data, not Quake engine

    The runtime is a browser-native reinterpretation of Quake rather than a direct engine port. A small extractor pulls facts out of QuakeC and progs.dat, then a TypeScript game layer uses that data for Quake-like behavior. That explains why some switches, doors, and movement rules initially felt off. The project preserves content and logic cues, not exact engine semantics.

    Do not read feature parity into a familiar asset set. If you are evaluating ports, ask whether the code path is original logic, transpiled code, or a reimplementation driven by extracted data.

      Attribution:
    • rofko #1
  2. 02

    Safari and WebKit look like the weak spot

    Reports clustered around Safari and other WebKit-based browsers being choppy, clipping badly, or acting strangely, while Chrome and Firefox often ran smoothly on similar machines. That points to differences in CSS 3D transform handling and compositor behavior, not just raw device speed. The same M1-class hardware could look broken in one engine and fine in another.

    If your product leans on advanced CSS transforms or DOM-heavy animation, budget for engine-specific debugging. Hardware benchmarks alone will mislead you if WebKit is part of your support matrix.

      Attribution:
    • jamal-kumar #1
    • jeroenhd #1
    • jedberg #1
  3. 03

    Original Quake still sets the performance bar

    The most useful comparison was not old versus new hardware. It was specialized renderer versus intentionally absurd pipeline. Quake in C can fly at very high resolutions on an M1, while this version asks a general-purpose styling engine to do work it was never tuned for. That makes the demo a compliment to both modern browsers and to the original Quake engineers.

    When a prototype feels slow on powerful hardware, check whether you chose a system optimized for that workload. General-purpose stacks can be surprisingly capable, but they rarely erase the advantage of purpose-built rendering paths.

      Attribution:
    • jedberg #1
    • matt_kantor #1
    • harrall #1
    • api #1
  4. 04

    The author was fixing bugs live

    Several rough edges were not inherent limitations of the idea. The author replied with concrete fixes for menu dismissal, switch behavior, and other issues while people were playing. That changes the interpretation of some early bug reports. Part of the jank was simply an active demo maturing in public, not a settled ceiling on what the approach can do.

    When judging unusual demos, separate architectural limits from first-day bugs. Early reports can overstate what the technique cannot do if the project is still being patched in real time.

Against the grain

  1. 01

    CSS is not the thing running Quake

    The pushback against "CSS has gone too far" was basically correct. The game logic is JavaScript and TypeScript. CSS is handling visual presentation through transforms and styled elements. That makes this less a story about declarative styling becoming a programming language, and more a story about the DOM being pressed into service as a renderer.

    Do not let a flashy demo distort your architecture mental model. If you are deciding what web technologies can or cannot do, separate rendering tricks from where the actual computation lives.

      Attribution:
    • ulrischa #1
    • slopinthebag #1
    • cynicalsecurity #1
    • Rohansi #1

In plain english

3D transforms ↩
CSS operations that move, rotate, scale, or position elements in three-dimensional space.
CSS ↩
Cascading Style Sheets, the language used to control how web pages are styled and laid out.
DOM ↩
Document Object Model, the browser's in-memory representation of a web page that JavaScript and CSS operate on.
FPS ↩
Frames per second, a measure of how smoothly graphics are rendered.
JSON ↩
JavaScript Object Notation, a widely used text format for structured data exchange.
M1 ↩
Apple's first generation of in-house ARM-based Mac processors.
progs.dat ↩
A compiled Quake game data file that stores gameplay logic and related definitions for the engine to load.
QuakeC ↩
The scripting language used by the original Quake to define gameplay behavior such as weapons, monsters, and triggers.
TypeScript ↩
A typed superset of JavaScript that adds static checking and compiles down to standard JavaScript.
WebKit ↩
The browser engine used by Safari and some other browsers to render web content.

Reference links

Project and source

Related CSS game experiments

  • cssDOOM
    Another browser game rendered with CSS that people compared to CSSQuake
  • NielsLeenheer/cssDOOM
    Repository mentioned when asking whether CSSQuake was derived from CSS Doom
  • css3d project
    Older handcrafted CSS 3D engine cited as a precursor
  • Keith Clark CSS FPS lab
    An older CSS first-person rendering experiment referenced as an original inspiration point
  • x86.css
    Referenced jokingly as a route toward even more browser absurdity

Author and social references

Standards and jokes