Playable revamp

React-Chess

A modern TypeScript rebuild of an older React chess project, embedded directly into the site as a playable article.

Project type
Legacy rebuild and modernization case study
Current focus
The current emphasis is on contrasting a monolithic learning-era implementation with a cleaner engine-first architecture.
Full app
Open full-page playable version

The embedded board is meant for immediate play inside the post. Use this button to open a roomier full-page version hosted inside the site.

This page is the first part of a larger comparison project. The plan is to place three versions of the same chess app side by side over time: the legacy original, a careful patch-up branch, and a full rebuild. This page hosts the rebuild first.

The rebuilt version moves the game rules into a dedicated engine and lets the page act as a thin interface over typed game state. That shift matters because it changes the kinds of mistakes the project is likely to make: fewer UI-driven bugs, clearer legal move handling, and a codebase that can be tested without clicking through the board.

Instead of talking about that separation abstractly, the article folds the game directly into the page. You can play immediately, read the framing around it, and later compare the experience against the earlier branches when they are wired into the same post.

Loading board

Preparing the interactive chess rebuild.

Why this rebuild matters

The old app stored the board inside one large React component and mixed rules, DOM mutation, and rendering together. The rebuild turns those concerns into separate layers so the board can be reasoned about as data first and interface second.

That does not make the project magically “finished,” but it does change the quality of future work. New rules and UI changes can be added from a much steadier foundation.

What comes next

The next steps for the post are comparative rather than purely technical. The legacy branch and the patch-up branch can be mounted into this same slot later so the differences become visible in one place instead of being scattered across screenshots and code excerpts.

That should make the blog post more honest. Readers will be able to feel the differences between repair and redesign instead of just reading a claim that they exist.