BLOG
Handwired: Hardly writing JS code as a neural network
On October 15th, React team member chenglou published handwired 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 fulliability. By October 20th, the repository had received 1804★, with popularity mainly coming from GitHub trending and social media. The project was written in TypeScript under the MIT license, using bun as the build tool. The online demo can be found at chenglou.me/handwired, and it can be run locally with bun install && bun start. This article breaks down the project into six sections.
What makes this project unique is that it doesn’t follow the old path of “training a network to simulate programs.” Instead, it goes the other way: first write the program, then compile it into a form that can run as a neural network. This reverse operation turns the neural network from a “learner” into an “executor.”
I. Who Is It?
The author is chenglou, a well-known GitHub developer and member of the React team. This time, he released handwired as a personal project. From the experimental logs in the lab directory, there were daily updates starting in early September, and discussions on design in June and July were also mentioned, indicating a long preparation period before its public release. The intensive submissions shortly after the repository was open should be understood as “one-time public release after long-term preparation with continuous refinement,” not the entire development process. This release pace is not uncommon in the open-source community: polish privately first, then release all at once, using social media to increase initial attention.
In terms of project scale, the core src/ directory contains sub-modules such as runtime, handwiredos, and json-search. The key file sizes are as follows: src/runtime/numeric-ui-core.ts is about 152 KB, src/runtime/cells.ts is about 22 KB, and src/runtime/host-timing.ts is about 21 KB. The repository is 90.5% TypeScript, making it a complete project with documentation, tests, and an online demo, not just a concept demonstration at the gist level. Its goal is not to become another front-end framework, but to provide a executable reference implementation for the concept of “program as network.” For developers who want to quickly understand differentiable programming, this repository offers a starting point for direct cloning, running, and modification.
II. Mechanism Breakdown
The starting point of handwired: Any program is nothing more than if-else statements, loops, and states, and it transforms these three into “matrix multiplication + ReLU” to be executed on floating-point numbers.
The example given in the README is the most intuitive. A branch like ((a > 4) ? 10 : 12) can be rewritten purely in arithmetic:
above4 = max(0, a - 4) - max(0, a - 5) // 1 if a > 4, otherwise 0
result = above4 * 10 + (1 - above4) * 12 // Calculate both branches and choose based on above4Here, max(0, x) is ReLU. These control flow primitives—comparisons and selections—are encoded into addition, subtraction, multiplication, and ReLU. Loops and states work similarly: the state is stored in a Float32Array source table, and each iteration reads the table, computes, and writes back.
To integrate the entire compilation process, handwired runs a regular JavaScript during construction, expanding macros like emitMultiply and emitCompare into fixed-length instructions. During runtime, there are no branches or loops; only sequential evaluation of this floating-point table. This means that once the program is compiled, its execution path is determined, allowing the GPU to schedule a large number of isomorphic threads in one go, without needing to handle dynamic branches at runtime.
The next step is collection: all additions, multiplications, and Reuls in the program are combined into a massive matmul, which is run on JS or WebGPU. Since only these two primitives are used, the README outlines three properties: the entire program remains differentiable; weights are handwritten and do not require training; mature GPU optimization techniques work particularly well with these minimal primitives.
The core innovation of the project is that it does not train a network to approximate the program, but rather compiles the handwritten program precisely into a neural network structure. Weights are not a product of training; they are the program itself. This triple goal of “no training, precision, and differentiation” is achieved through the choice of compilation direction. In other words, the neural network here resembles more an execution format for a program than an approximate function learned from data.
The value of this approach lies in moving “differentiability” from the training phase to the compilation phase. Traditional neural networks require large amounts of data and backpropagation to adjust weights; handwired first allows you to write deterministic behavior using familiar program logic, then retains its gradient structure for integration with an optimizer when needed. It does not aim to replace training, but to push the boundary between “training” and “program” forward.
III. Engineering Quality
From the directory structure, src/ is the core runtime, lab/ is experimental projects, template/ is templates, and docs/ is documentation. The runtime section is mainly composed of files like cells, host-timing, and numeric-ui-core. Among them, numeric-ui-core.ts, a single file, weighs approximately 152 KB and serves as the backbone of the numerical/UI runtime.
The proportion of TypeScript in the repository reaches 90.5%, indicating that it is not a lightweight wrapper but an engineering project that integrates numerical calculations, animation scheduling, and host interactions. The documentation in docs/ covers execution models, tutorials, patterns, and behavior choices, making it friendly for those interested in understanding differentiable programming. This level of engineering density also shows that handwired is not the product of a single day’s inspiration but a system developed through multiple iterations.
Looking at the dependencies, handwired does not introduce any heavy runtime. The package.json file only contains TypeScript, testing tools, and linting tools, with the core logic being completely self-contained. This choice keeps the repository lightweight, but it also means that it currently can only cover program segments that can be expressed using the builder API. For existing large business systems, direct migration is not practical; a more realistic approach is to extract and rewrite locally compute-intensive segments. In terms of source code organization, the tests/ directory is parallel to the template/ directory, indicating that the author wants users to start with templates and gradually rewrite ordinary JS into handwired style.
The online demo and examples in the template/ directory provide the most intuitive entry point: an ordinary JS-written UI component, after being converted by handwired’s builder code, becomes a numerical table that can run on the GPU. During compilation, ordinary JavaScript runs once to expand macros like emitMultiply and emitCompare into fixed-length instructions; during execution, there are no branches or loops.
This approach naturally appeals to front-end engineers: you don’t need to write CUDA or WGSL. You only need to use JavaScript’s builder API to describe numerical calculations, with the rest being handled by handwired. For those accustomed to React declarative components, this is like replacing the “component tree” with a “numerical program graph,” but the interface is still written in JavaScript. This also means that front-end engineers can use their most familiar language to explore GPU parallelism and differentiable programming, with a much lower entry barrier than learning a new language.
However, the simplicity of the builder API also brings limitations: all calculations must be expressible using the primitives provided by the project, and any operations beyond this range must be handled in ordinary JavaScript. Handwired is more like a domain-specific language embedded in JS rather than a uniform translation of JS syntax.
IV. Results and Verification
The effect of the repository’s self-description is divided into three levels. The first level is proof-of-concept: converting if-else statements, loops, and state transitions into matrix multiplication and ReLU operations, while the program remains precise and differentiable. The second level is demonstration: the online demo showcases the complete UI-based desktop system HandwiredOS. Interactions such as window dragging, maximization, clicking and selecting, text line wrapping, and virtual list scrolling are all compiled into the numerical program. The host only needs to write browser events into the source code, run it once for evaluation, and write the output back into the DOM. The third level is performance demonstration: the JSON search demo claims to complete searches in milliseconds on 100,000 documents, thanks to isomorphic parallelism, where each document undergoes the same operations without interference. In other words, Handwired’s demonstration is valuable because it proves that “programs can run on a floating-point table” is feasible, not just theoretically possible. It turns abstract concepts into clickable demos in the browser, which is a key reason for its high ratings.
However, the author himself labels these efforts as experimental. The style in the README, “What does that even do? Let’s find out!” and questions like “By connecting a frozen specific program to a general neural network end-to-end training, nanoGPT can learn both Shakespeare and your UI?” indicate that it is more of an exploratory project than a mature tool.
V. Boundaries and Controversies
First, there are the boundaries of expression. The README’s “Turn your regular JavaScript code into a neural net” easily leads people to believe that any JS can be automatically compiled into a network; but the technical reality is that it requires manually rewriting programs using the project’s provided builder primitives and numerical contracts, not a general JS compiler.
Next is the numerical boundary. Encoding integers using ReLU depends on the operands falling within the declared grid and range. In the floating-point world, inputs outside the range have no magic; indexing also has limits. Programmers need to actively maintain these numerical contracts.
The third is the scale boundary. Computing on both sides of a branch increases the complexity of the operands as the program grows. Handwired is suitable for verifying the idea that “programs are networks,” but if the control flow of a real business system is fully expanded into matrix operations, the scale and debugging costs will rapidly increase. This also means that Handwired is currently more applicable to local compute-intensive scenarios such as controls, searches, and animations, rather than entire business logic.
Finally, there are the ecological boundaries. As an experimentally released project, Handwired has not yet formed a stable community and toolchain. Third-party libraries, editor plugins, and debugging tools are not mature. Companies considering adoption must bear both maintenance and cognitive costs.
Lastly, there is the temperature difference between dissemination and popularity. On GitHub, it has 1804★ stars, and HN has also appeared on the homepage multiple times; but high ratings measure topic relevance, not adoption. The interface may change at any time, and open issues are increasing. It is not advisable for those looking for production tools to adopt it directly now.
VI. Conclusion
The value of handwired lies in using a concrete, runnable project to transform the idea that “ordinary programs can be compiled into differentiable neural networks” from a slogan into a practical demo. It challenges the default belief that neural networks must be trained and shows that differentiability can arise from the compilation structure, rather than being forced in from outside through backpropagation. This approach complements the current AI engineering practices that rely heavily on training data: in some scenarios, the structure of the program itself can enable differentiability without needing to model the problem entirely as an optimization issue.
The fact that it reached 1804 stars in just 4 days indicates that this topic has struck a nerve among communities; however, whether it is a research toy or a sign of a new paradigm requires seeing if others can apply it to real-world problems and if anyone can expand this approach to more complex control flows. At this stage, it is more suitable as a textbook-level entry point for understanding differentiable programming and numerical compilation, rather than a ready-to-use new generation front-end framework. For developers in the fields of frontends and compilers, handwired offers a program representation method worth considering; for teams looking to apply it directly, more verification and ecosystem development are needed.
An interesting comparison is with traditional neural networks. Traditional networks use training to find weights, which have the advantage of being versatile but the downside is that their behavior is non-explanatory and require large amounts of data. Handwired uses programs to directly specify weights, which have the advantage of being deterministic and explainable, but the downside is that its expressive power is limited by the programs that programmers can write. The two are not alternative but complementary. In scenarios where high demands are placed on explainability and certainty, such as UI animations, financial computing, and physical simulation, handwired’s approach may be more reliable than training networks.
It may not change how you write tomorrow, but it has indeed cut a hole in the “wall between programs and networks.” Future issues worth attention include: Can it support more dynamic control flows? Can it reduce scale expansion while maintaining differentiability? Can it complement existing front-end frameworks rather than replacing them? There are no ready-made answers to these questions, but it is precisely because of them that handwired retains its value for discussion.
Information Sources
- GitHub Repo: chenglou/handwired (README, docs/, src/, lab/)
- Fact Pack: /Users/kael/xhs-content/drafts/2026-10-20-facts-packages.json (repo size, author, core mechanism, Demo address, popularity)
- Online Demo: https://chenglou.me/handwired/