|
| 1 | +# Frequently Asked Questions |
| 2 | + |
| 3 | +## Why does Tokamak use HTML/CSS for rendering in the browser? |
| 4 | + |
| 5 | +HTML/CSS has a benefit of built-in accessibility support. Other rendering systems in the browser (such as Canvas or WebGL/WebGPU) |
| 6 | +that bypass HTML/CSS would have to reimplement accessibility from scratch, with all the downsides of increased binary |
| 7 | +size and performance overhead. With HTML/CSS we can rely on what's already included in the browser and has been tested and polished |
| 8 | +by hundreds of engineers over the decades of browser development. |
| 9 | + |
| 10 | +Additionally, we can rely on optimized CSS layout algorithms where possible. This also unlocks more use-cases for Tokamak, such as |
| 11 | +[static HTML generation](https://github.com/TokamakUI/TokamakPublish) and [server-side rendering](https://github.com/TokamakUI/TokamakVapor). |
| 12 | + |
| 13 | +At the same time, Tokamak has [a new layout system in development](https://github.com/TokamakUI/Tokamak/pull/472) that accesses |
| 14 | +DOM directly for layout calculations, bypassing CSS for a lot (or potentially all) of its algorithms. |
| 15 | + |
| 16 | +## Does the word Tokamak mean anything? Why is it called this? |
| 17 | + |
| 18 | +The project was originally inspired by [React](https://reactjs.org), which utilizes a model of an atom in its logo, |
| 19 | +apparently as a reference to nuclear reactors. [Токамак](https://en.wikipedia.org/wiki/Tokamak) is a nuclear fusion reactor, and |
| 20 | +the word itself is roughly an abbreviation of "**to**roidal **cha**mber with **ma**gnetic **c**oils". |
| 21 | + |
| 22 | +## What's the history behind it? |
| 23 | + |
| 24 | +The first commit to this project was made in September 2018, 9 months before SwiftUI was publicly announced. The original maintainer of |
| 25 | +it had a feeling it would be beneficial to replace UIKit and AppKit with a declarative UI framework. It originally started |
| 26 | +as a port of the [React API](https://reactjs.org/) to Swift. The opinion of the original maintainer was that React was a pretty good |
| 27 | +solution at that time and was adopted widely enough for people to be acquainted with the general idea. The architecture of React |
| 28 | +was quite modular, and it had a well-documented reconciler algorithm that worked independently from platform-specific renderers. |
| 29 | + |
| 30 | +The plan was to build something similar to the React API in Swift with renderers for macOS and iOS, and then potentially for |
| 31 | +WebAssembly, Android, and Windows. Shortly after a short series of [0.1 releases with the React |
| 32 | +API](https://github.com/swiftwasm/Tokamak/blob/0.1.2/README.md), Tokamak for iOS/macOS was [sherlocked](https://en.wikipedia.org/wiki/Sherlock_(software)#Sherlocked_as_a_term) by |
| 33 | +SwiftUI at WWDC 2019. It no longer made sense to continue developing it in that form for Apple's platforms, even though it could |
| 34 | +still be useful for other platforms. The original maintainer thought it would be hard to convince Swift developers to use something |
| 35 | +that doesn't look like SwiftUI, at least as long as the majority of Swift developers target Apple's platforms. |
| 36 | + |
| 37 | +In addition to SwiftUI and React, we'd like to credit [SwiftWebUI](https://github.com/SwiftWebUI/SwiftWebUI) for reverse-engineering |
| 38 | +some of the bits of SwiftUI and kickstarting the front-end Swift ecosystem for the web. [Render](https://github.com/alexdrone/Render), |
| 39 | +[ReSwift](https://github.com/ReSwift/ReSwift), [Katana UI](https://github.com/BendingSpoons/katana-ui-swift), and |
| 40 | +[Komponents](https://github.com/freshOS/Komponents) declarative UI frameworks served as additional inspiration for the project. |
0 commit comments