rkaehn

Over the past year, I have been working to find a better way to write cross-platform apps.

The problems I am trying to solve:

- Native frameworks only work on a subset of platforms, so a different implementation of the UI needs to be written per target. - They are updated at the same pace as the platform itself, which forces the developer to split the user base to be able to use new features, or wait a long time for bugs to get fixed. - They also force developers to use specific high-level languages, so they are not a good fit for apps with high performance requirements, like creative apps or games. - Cross-platform frameworks that rely on bundling a browser engine solve the problem of code reuse, but they inherit the limitations of HTML/CSS. - Those that take control over layout and rendering are not efficient and lightweight enough to be used on the web, and require the use of compiled languages.

Ideally, we would be able to bundle the UI framework directly with the application. This would allow developers to use new features and fix issues in the UI framework immediately. It would also allow ideas for improvements to compete in a natural way, rather than being decided by a committee.

Uniform is my idea for how we can solve these problems. This is the structure:

- A layout and rendering engine written in C, compiled to WASM on the web and native code on all other platforms - A JavaScript API where each function call gets forwarded directly into the core, for best performance and efficiency - A native runtime (<2 MB) that makes it possible to run the same JavaScript code on macOS and iOS (more platforms to come). The runtime can also generate packaged apps to upload to app stores. The packaging steps are also described in JS.

Uniform supports very fast iteration cycles via hot-reload on all platforms. Even on iOS, the JS source code of an app can be changed while the app is running. Changes are visible on the next display refresh. No connection to a computer or the internet is required. Apps can be written from scratch on a phone, with native performance.

The readme in the linked repository includes many examples and a detailed explanation of the core ideas. It is handwritten without any use of AI.

And here is a live demo: https://raffk.com/hn-demo/

It should work in any browser that supports WebGPU. (To get 120 Hz support in Safari, the “Prefer Page Rendering Updates near 60fps” feature flag needs to be disabled.)

Regarding the footnote about the temperature encoding: it seems to be Gray code

The tasks themselves come from a pool and are reused automatically, so no call to `free` is needed there. As for the executor, destroying it is a bit involved, because you need to wait for the currently executed task to finish before joining the threads and releasing the resources. It is a feature I do want to work on in the future though.

The library is an "stb-style" header-only library, so the header has two modes: when you define CR_TASK_IMPL, it includes the implementation (starting from line 20), otherwise it just includes declarations (the first 19 lines). The implementation should only be included in one translation unit, but the declarations can be included in multiple units.