Handwired: Converts ordinary JS code into neural networks. Achieved 1730 stars in 4 days.

---

On October 15th, developer chenglou created the handwired repository on GitHub. The first sentence of the README is “Turn your regular JavaScript code into a neural net; no training, exact, yet also fully differentiable”: Convert ordinary JavaScript code into a neural network without training, with accurate results and full differentiation capabilities. As of October 19th, the repository had 1730 stars, 143 forks, and 9 open issues. It rose to thousands of stars in 4 days, with the sole contributor chenglou making 825 commits. The project is licensed under MIT, built with bun, and has an online demo at chenglou.me/handwired. cloning and running it locally requires bun install && bun start. Interestingly, during the same period, there were only 5▲ and 4▲ commits on HN respectively, with almost all popularity coming from GitHub. This article breaks down the content into six sections as usual.

I. Who Is It?

The author is chenglou, with 1295 HN karma points. Only links to GitHub and Twitter are provided in the personal profile. Community information indicates that he is a well-known developer in the React ecosystem (author of React Motion, promoter of ReasonML, formerly at Meta). This background was not independently verified in this article; the content is handled as “developer chenglou.”

There is a time difference to explain about the project itself: The repository was created on October 15th, but the experimental records in the lab directory were written earliest in early September, mentioning design discussions in June and July. There were daily updated experimental logs in mid-September, indicating that development predated public release. The 4-day 825 commits represent the submission pace of the public repository, not the entire project’s duration. Understanding it as “long-term preparation followed by one-time public release and continuous organization” is more consistent with the evidence.

Local clone test results (light clone, October 19th): There are 1542 files in total, including 1101 ts files, totaling approximately 275,000 lines; the src core directory has about 18,000 lines, the lab experiment directory has about 235,000 lines, tests have about 22,000 lines, and the six documents in docs have a total of 1,296 lines. The file type distribution is 1101 ts files, 151 json files, 141 md files, 49 txt files, 38 html files, and 22 css files. This is not a gist-level idea demonstration; it is a complete project with documentation, tests, tutorials, and an online site.

II. Mechanism Breakdown

The concept behind handwired: Programs are composed of if-else statements, loops, and states. It transforms these three elements into “matrix multiplication plus reglu” operations performed on floating-point numbers.

The example given in README is the most intuitive. A branch like a > 4 ? 10 : 12 can be rewritten as pure arithmetic: first calculate above4 = max(0, a-4) - max(0, a-5), where max(0, x) is ReLU. For integer a, above4 equals 1 if a > 4, otherwise 0. Then compute result = above4*10 + (1-above4)*12. Both branches are evaluated, and one of them is selected by above4. These control flow primitives—comparison and selection—are encoded into addition, subtraction, multiplication, and ReLU. The same applies to loops and states: states are stored in a Float32Array source table, and each iteration reads from the table, computes, and writes back.

The next step is collection: all additions, multiplications, and Reuls are combined into a large matmul, which is executed in JS or WebGPU. Since only these two primitives are used, README provides three properties: the entire program remains differentiable; weights are handwritten and do not require training; GPU’s advanced optimization techniques (fusion, sparsity, reordering) work particularly well with these minimal primitives.

The definitions in docs/execution-model.md are much more strict than those in README. The program is a sequence of fixed-length instructions, with only four types: affine (affine weighted sum), reglu (left * max(0, gate), which degenerates to ReLU when gate is constant 1), boolean (hardening the score from 0..1 to precise 0 or 1), and index (table reading, i.e., retrieving values from candidate tables based on floor(subscript)). All numerical semantics are written at the FP32 rounding order level. Affine terms are rounded individually according to storage order, and the document explicitly requires that any backend must be bit-for-bit consistent with the reference evaluator.

Comparison is not only encoded using ReLU. emitCompare directly produces precise bits on the operands of an integer grid: a>=b on a 1/64 grid requires only 2 operations and 2 layers. Without a grid declaration, symbolic cascading is used, and a>=b in the range of 0..16,384 requires 15 operations and 14 layers. Index reading has a dedicated lowering process, completing in one operation for any table size, with index ranges limited to ±2^24. What you write is not an instruction list but “builder code”: ordinary JavaScript runs once during construction, expanding macros like emitMultiply and emitCompare into instructions, with no branches or loops during runtime.

Differentiability is also structural, not a patchwork. Gradients can flow back along these four instructions: the gradient of affine is the coefficient, the gradient of reglu includes ReLU gate, and hardening operations like boolean are marked as “rounding points” in the document. Backends can freely rearrange and merge other sums, but these points must maintain semantic consistency. When taking gradients from indices, the caller must explicitly choose between zero or backward-difference strategies; otherwise, an error is thrown: the design prefers to report an error rather than secretly giving you an undefined gradient. This convention turns “the entire program being differentiable” from a slogan into a bounded contract.

The next level up is time and animation. host-timing.ts breaks the spring animation into 4ms intervals, and a 2×2 stepping matrix is pre-calculated based on stiffness and damping. Each frame, the host writes this matrix into 4 input cells, which is then applied using emitApplySpringMatrix within the program. In other words, even UI animations, which don’t seem like neural networks at all, are compiled into the same numerical table.

III. Engineering Quality

The src folder is divided into four parts: runtime is the core operating system, with four files: cells, host-timing, numeric-ui-core, and prefix-networks; handwiredos is a complete desktop demonstration, where window managers, Photos, Notes, and Files are all compiled into numerical programs, totaling about 5500 lines; json-search has around 6200 lines and is a search demonstration; learned-gallery is a learning-related demonstration. The tests directory contains 42 test files covering comparative semantics, gather lowering, numerical semantics, spring matrix, etc. A single module in json-search includes 184 tests, running for about 45 seconds. The template directory contains a teaching example of a switch button, with docs/tutorial.md explaining each line, along with a reference implementation written in ordinary JS, ensuring that the outputs of both are consistent. Inside docs, there are also six documents: patterns.md (484 lines), behavior-choices.md, execution-model.md, etc., showing quite organized engineering habits.

HandwiredOS is worth mentioning further; it is the most convincing demonstration in the entire repository. Window dragging,最大化, clicking to select photos, text wrapping, and virtual scrolling lists—these interactions do not appear in the host JS but are compiled into numerical programs: window hit tests use emitCompare on a 1/64 pixel grid, with pointer coordinates first rounded to the grid before entering the program, so each comparison is precise in integer digits. The virtual list in the Files window is simply a list of values from the program itself, with 64 DOM slots allocated by the program. The host is only responsible for writing browser events into the source table, running the evaluation once, and writing the output back to the DOM. In other words, a usable desktop system’s runtime essence is matrix operations on a floating-point number table.

Performance numbers are recorded in lab/status.md, down to the microsecond level. HandwiredOS as a whole is compiled into 20,381 active operations, 230 layers, and 45,436 storage weights. A single evaluation takes about 133µs, idle frames about 141µs, and typing frames about 282µs. The README for json-search admits that a single GPU round trip takes over 0.6ms, which is not beneficial for individual documents. Benefits are only seen in a scenario where 100,000 documents are parallelized: each document runs the same operations without reading others’ values, thoroughly scanning them all.

README: There are three use cases for the self-description (the author’s perspective): Unfrozen weights for direct training, as the author put it, “What will happen? Only by trying can you know”; End-to-end training using a frozen specific program connected to a general neural network, “Can nanoGPT learn both Shakespeare and your UI?”; And JS, traditionally single-threaded, gaining GPU-level parallelism, with JSON search completing in milliseconds over 100,000 documents. All three use cases end with question marks, indicating an experimental tone.

The submission rhythm itself is noteworthy: 825 submissions in 4 days by a single person. The author did not claim any generation methods, but the review notes from September 3rd in the lab state that the author reviewed “Claude conversations in June and July” and “Codex design discussions in June.” Three independent audits were conducted for the review. The details are presented here; the judgment is left to the reader.

There is also evidence of honesty: The September review notes mention, “The most concerning finding was specific: some correctness checks are sharing the same error across implementations.” It’s unusual in a star repository to actively document vulnerabilities in one’s testing system rather than waiting for others to find them.

IV. Comparison with Similar Projects

Conceptually, handwired falls under the old direction of “differentiable programming”: making the control flow of ordinary programs exist in differentiable numerical forms, similar to neural symbol systems. However, its approach has its place: it doesn’t train a network to approximate the program, but precisely compiles handwritten programs into neural network form. Weights are not products of training; they are the program itself. Differentiable interpreter-based work usually sacrifices precision for derivability, using softening instead of branching; handwired, on the other hand, first locks in precision through range declarations, integer grids, and symbolic cascades, then gains derivability. The terms “no training required, precise, differentiable” all hold true, thanks to this compilation approach. This comparison is only at the conceptual level and does not involve judgments about the merits of specific projects.

V. Limitations

Three points. First, numerical boundaries: Using ReLU to encode integers relies on the operator falling within the declared grid and range. The repository uses range declarations and precision bits to cover these cases, but this means that programmers must maintain their own numerical contracts. In the floating-point world, inputs outside the range have no magic; index reads exceeding ±2^24 are directly rejected. Second, scale expansion: Both sides of branches are counted, and the number of operations increases with program complexity. There are ready examples in status.md. After the Notes application was migrated, HandwiredOS saw an increase from 14,019 active operations to 20,381, and storage weights increased from 31,359 to 45,436. A single evaluation time increased from about 75µs to about 133µs. A toy desktop already has 20,000 operations; the scale of real applications is imaginable. Third, practicality: The author himself defines the project as experimental. README says, “What does that even do? Let’s find out!” This is direct evidence and doesn’t need to be exaggerated for him.

VI. Judgment and Who Can Use It

First, let’s look at the popularity structure: HN has two posts with a total of 9 likes. On GitHub, it reached 1730★ in 4 days. It gained attention from trending and social media but received little response from technical forums. This contrast indicates that most people were attracted by the concept of “code becoming a neural network.” The cost of liking is much lower than reading execution-model.md. Likes here measure topic relevance, not adoption rate.

For those who want to understand differentiable programming, this is an entry-level resource: read six documents, run examples with templates, and start local demos with one command—a half-day effort that’s more intuitive than reading papers. For those working on GPU numerical computing or compilers, they can learn from its macro design. Macros like emitCompare and index read can be transformed into minimal commands during construction, and rounding point can be used to retain flexibility in reordering. These are techniques worth adopting. For those looking for production tools, avoid this now: there are 9 open issues, and interfaces may change frequently. The author’s role is experimental.

Whether it’s a research toy or a paradigm signal, it’s unclear after 4 days. But what’s certain is that the compilation goal of “program as a network” has been achieved by someone using 270,000 lines of TypeScript to create a system that runs on desktop and can search 100,000 documents in milliseconds. The completeness of documentation and testing deserves the likes. This itself makes it worth analyzing.

Information Sources

• Repository: github.com/chenglou/handwired (README, docs/execution-model.md, docs/tutorial.md, docs/patterns.md, template/, src/json-search/README.md, lab/status.md, lab/reassessment-2026-09-03.md, local clone verified on 10-19; number of lines and files counted locally by find/wc)
• Likes, forks, creation time, contributors, and number of commits: GitHub API (snapshot on 10-19, likes still changing)
• HN submission records: id=50105849 (5▲), id=50105735 (4▲), snapshot on 10-19
• Unverified parts of the author’s background are marked as “community data” in the text.