Compile the application
We adapted Static Hermes for ahead-of-time compilation, TypeScript inputs and an interpreter-free runtime. Work includes language semantics, native calls and object lifetimes across garbage collection.
Inside the compiler ↓Engineering / The first eight weeks
Eight weeks.
Deep in the engine.
Two cofounders, working with AI, building across the compiler, browser engine, native runtime and developer tools. From the first commit on 23 July to this snapshot on 17 September 2026, here is the work behind Attar.
- Lines added or removed in patches
- 198K
- Chromium & Hermes patches
- 813
- Nonblank lines of Rust
- 151K
- Calendar weeks
- 8
A source snapshot of the broader project, including Attar Electron R&D. Source counts describe the work; the compatibility guide describes release support. How we counted ↓
Six parts of the engineering
Every layer has to meet
the one below it.
Bring Blink into a native window
We connected the real DOM, CSS, layout and paint engine to Chromium’s native window, input and accessibility code. Removing browser dependencies also requires preserving those paths.
Inside the engine ↓Give React a native host
We built a host that compiles React’s reconciler with the application, translates its commits into Blink operations and carries events, refs and component lifetimes across the boundary.
React support ↗Connect Rust and native code
We built C interfaces, Rust ownership wrappers and generated bindings. Native clients need matching libraries, explicit handle lifetimes and a clear owner for the UI thread.
The native boundary ↗Turn the toolchain into an SDK
We built the path from a fixed application graph to a compiled, linked and packaged application, plus the workflow that pins, builds and checks the native SDK inputs.
Build and delivery ↓Check behavior at every boundary
We built runners for language suites, native engine tests and application checks, with separate reports for compiler errors, runtime failures and missing behavior.
The verification work ↓Inside Chromium
Make a browser engine
serve one application.
Blink already implements the DOM, CSS cascade, layout, text and painting. Attar keeps that work. It changes how the engine is built and embedded so a native application can use it without shipping the whole browser.
That means working inside Chromium: native windows, input, accessibility, resource loading and presentation all have to remain connected. Removing a subsystem is useful only if the application still behaves correctly.
Reuse the web engine
Blink for web semantics. Chromium’s rendering and platform code for the native interface.
Compile the application
Ahead-of-time JavaScript and a fixed executable graph, linked with the engine code the application needs.
Inside the compiler
Two substantial upstreams.
Attar maintains changes to Chromium and Meta’s Hermes. Chromium supplies the UI engine; the Static Hermes fork supplies JavaScript compilation and execution. Their responsibilities stay separate. The two patch series touch 866 Chromium paths and 125 Hermes paths.
Across 813 patches, the series adds 135,813 lines and removes 62,248: 198,061 lines of changes in total. Chromium accounts for 770 patches; Hermes accounts for 43.
| Upstream | Added lines | Removed lines |
|---|---|---|
| Chromium | +115,252 | −60,380 |
| Hermes | +20,561 | −1,868 |
| Total | +135,813 | −62,248 |
These are cumulative patch edits, including source, tests and build files. Repeated edits count each time; unchanged context lines do not. This is not the amount of unique new code in the final tree.
The Hermes work ranges from TypeScript type handling and loop bindings to RegExp behavior, garbage-collection roots and native embedding. Compiler work also means fixing the small semantic differences that real programs depend on.
Ordered patch series record those changes against pinned upstream sources. They make the fork reconstructible and give each update a concrete set of changes to review.
Rust connects the platform, application lifetime and public native interfaces. The C ABI also lets other native code meet the UI at the same boundary.
Runtime & delivery
The forks are only
part of the work.
Alongside the upstream patches, the snapshot contains 150,983 nonblank lines across 149 Rust source files in the compiler and runtime directories. This is separate from the Chromium and Hermes patch counts.
| Area | Responsibilities | Lines |
|---|---|---|
| Build contracts | Application graphs, diagnostics, bundle validation and capability binding generation. | 22,268 |
| Runtime | UI and native adapters, ownership, application lifecycle and Electron R&D providers. | 128,715 |
Nonblank lines include comments and inline tests. Generated files and known upstream pins are excluded. This is a source inventory, not the size of the shipped runtime.
From a fork to a repeatable build
The SDK workflow builds pinned native sources, records the engine identity and verifies archive hashes. Application builds consume that SDK, resolve their own inputs and package the executable with its resources.
Separate tooling checks the link: which native code is reachable, which inputs produced it and whether forbidden runtime dependencies remain. A compiler that produces an executable also needs a way to explain what went into it.
The Rust count excludes the Python, JavaScript and shell tooling, as well as upstream source, ports and standalone test directories. It is deliberately narrower than the whole repository.
Verification
102,619 language-test variants.
A report for every outcome.
The published Test262 run on 2026-09-14 recorded 69,656 passes and 32,963 non-passing outcomes. That report includes failures, timeouts and unverified negative tests; it is not a claim of full JavaScript conformance.
Compiler tests check language behavior. Native tests exercise the retained engine interfaces. Packaged application checks cover another level: startup, rendering, interactions and teardown.
Those results answer different questions. The JavaScript report and web-platform report retain passing, failing and unmeasured results. A source audit or successful bundle is not a substitute for a native application run.
One concrete research result
The recorded Etcher comparison shows the direction: the same application occupied 375.1 MiB with Electron and 73.3 MiB in the Attar build. The full comparison gives the machine, methods and other measurements.
That work belongs to Attar Electron R&D. Attar Electron is planned and is not included in the standalone SDK release.
About the snapshot
Count the series,
keep the scope.
The Chromium total comes from the reviewed export manifest: each of its 770 patch entries matches its recorded SHA-256. The Hermes total counts the 43 entries in its ordered series. Loose patch files and legacy queues are excluded. Line counts use Git’s numstat parser on every patch and sum additions and deletions. A replacement contributes a deletion and an addition; later edits to the same line count again. File counts deduplicate paths named by patches within each fork; a rename can contribute both its old and new path. They measure the span of the series, not the number of final files in a binary.
The snapshot was reviewed on 2026-09-17. Eight weeks means 56 calendar days since the first commit, not eight weeks of one person’s effort. The Rust count reads committed source at the same revision. It includes nonblank comment and inline-test lines, excludes generated output and known upstream pins, and rounds 150,983 to 151K for display. None of these counts is an estimate of engineer-years or development cost.
The current SDK guide describes what developers can use. Additional frameworks and the Electron compatibility layer have their own place on the roadmap.