HTML/CSS has a benefit of built-in accessibility support. Other rendering systems in the browser (such as Canvas or WebGL/WebGPU) that bypass HTML/CSS would have to reimplement accessibility from scratch, with all the downsides of increased binary size and performance overhead. With HTML/CSS we can rely on what's already included in the browser and has been tested and polished by hundreds of engineers over the decades of browser development.
Additionally, we can rely on optimized CSS layout algorithms where possible. This also unlocks more use-cases for Tokamak, such as static HTML generation and server-side rendering.
At the same time, Tokamak has a new layout system in development that accesses DOM directly for layout calculations, bypassing CSS for a lot (or potentially all) of its algorithms.
The project was originally inspired by React, which utilizes a model of an atom in its logo, apparently as a reference to nuclear reactors. Токамак is a nuclear fusion reactor, and the word itself is roughly an abbreviation of "toroidal chamber with magnetic coils".
The first commit to this project was made in September 2018, 9 months before SwiftUI was publicly announced. The original maintainer of it had a feeling it would be beneficial to replace UIKit and AppKit with a declarative UI framework. It originally started as a port of the React API to Swift. The opinion of the original maintainer was that React was a pretty good solution at that time and was adopted widely enough for people to be acquainted with the general idea. The architecture of React was quite modular, and it had a well-documented reconciler algorithm that worked independently from platform-specific renderers.
The plan was to build something similar to the React API in Swift with renderers for macOS and iOS, and then potentially for WebAssembly, Android, and Windows. Shortly after a short series of 0.1 releases with the React API, Tokamak for iOS/macOS was sherlocked by SwiftUI at WWDC 2019. It no longer made sense to continue developing it in that form for Apple's platforms, even though it could still be useful for other platforms. The original maintainer thought it would be hard to convince Swift developers to use something that doesn't look like SwiftUI, at least as long as the majority of Swift developers target Apple's platforms.
In addition to SwiftUI and React, we'd like to credit SwiftWebUI for reverse-engineering some of the bits of SwiftUI and kickstarting the front-end Swift ecosystem for the web. Render, ReSwift, Katana UI, and Komponents declarative UI frameworks served as additional inspiration for the project.