An experimental C++ browser engine with a dependency-free rendering foundation.
Built on a Ladybird/SerenityOS-derived codebase · not production-ready · authored by Dr. Sohil Momin.
Landing page · Get started · Rendering pipeline · FAQ · Downloads · User guide · Architecture · All projects
-brightgreen){kind=icon}
Visit the project landing page →
Features · build steps · interactive rendering-pipeline walkthrough · get-started · FAQ
An experimental C++ browser project built on a Ladybird/SerenityOS-derived codebase.
Minimal by intent · measurable by discipline · honest about provenance.
Quick Start • User Guide • Architecture • Contributing • Security • Changelog
Status: Experimental. Aetheris is not currently a production-ready, standards-complete replacement for established browsers.
Aetheris Browser is an experimental C++ browser project built on a codebase derived from the Ladybird and SerenityOS browser ecosystem. The repository contains upstream-derived infrastructure, including components and libraries from that ecosystem, alongside Aetheris-specific experiments and modifications.
Aetheris is not presented as a browser built entirely from scratch. Its work focuses on adapting, extending, simplifying, and experimentally developing browser subsystems on an existing technical foundation.
The Aetheris-specific core today is the dependency-free AetherisRendering
foundation in src/rendering/ with its regression suite in
Tests/AetherisRendering/. See
docs/ARCHITECTURE.md for the full layout of the tree.
- Explore a smaller and more understandable browser architecture where practical.
- Improve memory efficiency and startup characteristics through measurable engineering work.
- Develop HTML, CSS, DOM, layout, rendering, resource, and document integration incrementally.
- Preserve upstream licensing and attribution requirements.
- Prefer coherent, testable changes over speculative architectural rewrites.
The project aims to be more resource-conscious than typical Chromium- or Electron-based applications where practical and measurable. These are engineering goals, not guaranteed universal metrics.
Aetheris contains code and infrastructure derived from the Ladybird/SerenityOS ecosystem. This includes foundational components visible in the repository such as AK, LibCore, and other imported browser infrastructure.
Aetheris-specific code should be distinguished from upstream-derived code during maintenance and review. Existing upstream copyright notices and licenses must not be removed or replaced by project rebranding.
See docs/UPSTREAM_ATTRIBUTION.md for the repository-level provenance policy.
HTML input ──► HTML tokenization ──► DOM
│
CSS input ───► CSS parsing ──────────┤
▼
Style resolution
│
▼
Layout
┌────────────┼────────────┐
▼ ▼ ▼
Block Flex Grid
│
▼
Render tree
│
▼
Paint commands
│
▼
Paint execution
│
▼
Software surface
The rendering pipeline currently includes work in block and inline layout, Flex and Grid foundations, positioning, sizing constraints, text layout, clipping, paint ordering, backgrounds, images, fonts, and software rasterization. Feature presence does not imply complete HTML or CSS standards compliance.
Aetheris may evaluate standard techniques such as controlled caches, allocation reduction, compressed resource storage, and secure clearing of sensitive memory where justified. LZ4 or similar mechanisms are implementation options rather than proprietary technology claims.
The project may explore delayed initialization of expensive subsystems, including scripting, when document requirements permit. Dynamic documents and compatibility requirements make this a design problem that must be validated rather than assumed to provide a universal benefit.
Current and future work may reduce redundant paint operations, improve clipping and invalidation, and evaluate accelerated backends where the complexity and dependencies are justified.
Aetheris does not currently claim fixed limits for binary size, idle memory usage, or startup time.
Performance measurements should record the operating system, hardware, compiler, build configuration, enabled features, workload, and measurement method. Future public performance claims should be reproducible.
A typical development workflow is:
cmake -S . -B build
cmake --build build --config Debug
ctest --test-dir build --output-on-failureReconfiguration is required when CMake configuration or build-registered files change. Otherwise, an existing build directory can be reused.
For a dependency-light workflow that skips the upstream tree entirely, use the
Standalone preset; for a size-first release build, use StandaloneSize:
cmake --preset Standalone
cmake --build --preset Standalone
ctest --preset Standalone
cmake --preset StandaloneSize # -Os, gc-sections, LTO, stripped
cmake --build --preset StandaloneSizeThe size profile applies only to the Aetheris targets (AetherisRendering,
AetherisRuntime, aetheris); a stripped aetheris executable is on the
order of 1 MB with the current feature set (HTML/CSS layout, bitmap-font
text, PNG/JPEG/GIF/SVG/WebP images, HTTPS/TLS and the HTTP client all linked in).
The aetheris executable exposes a small headless command surface:
./aetheris --smoke-test # init all subsystems, bounded frame loop, exit 0
./aetheris --fetch <url> # fetch a URL over HTTP, print status and size
./aetheris --render <url> [out] # fetch a URL and render it to a PPM image
./aetheris --eval <script> # run a JavaScript snippetNetworking supports http:// and, when the build finds OpenSSL, https://
(TLS with certificate and hostname verification; set AETHERIS_CA_FILE to use
a custom CA bundle). Hostnames resolve through getaddrinfo and the connect is
time-bounded.
The remaining work is organised into phases with combined batches and a delivery workflow aimed at a high quality-to-time ratio. See docs/ROADMAP.md.
Aetheris is derived from Ladybird and SerenityOS (BSD-2-Clause); a self-contained mini JavaScript engine, the rendering foundation and the standalone runtime are Aetheris additions. Optional external libraries (OpenSSL, libwebp, LZ4, X11) and bundled public-domain data are used with their own licences. See CREDITS.md for the full breakdown.
- Preserve working architecture unless a change has a clear technical justification.
- Do not claim code provenance, performance, security, or compatibility that has not been verified.
- Keep upstream attribution and licensing intact.
- Add regression tests with new behavior where practical.
- Prefer incremental, coherent changes and avoid unnecessary abstractions.
- Use clear subsystem-oriented commit messages.
Aetheris is an experimental browser-engine and systems-programming project. It should not currently be represented as a complete browser built from an empty codebase, a fully standards-compliant browser, or a project with guaranteed resource limits unless those statements are supported by reproducible evidence.
Start with the User Guide and
Architecture reference, then read
CONTRIBUTING.md. In particular, contributors must
determine whether affected code is upstream-derived or Aetheris-specific,
preserve applicable notices, and validate relevant builds and tests.
Report problems following ISSUES.md; review the release gates in
docs/V0.1_ACCEPTANCE.md and
docs/RELEASE_CHECKLIST.md before tagging.
Windows users: see docs/WINDOWS_BUILD.md.
Licensing and redistribution obligations must remain compatible with the upstream-derived code present in this repository. The existing repository license should not be treated as sufficient proof that all imported components may be relicensed under the same terms.
See docs/UPSTREAM_ATTRIBUTION.md. A dedicated provenance and licensing audit is required before making broad relicensing or commercial-use claims about the entire repository.
Aetheris Browser — experimental C++ browser project.
Authored and maintained by Dr. Sohil Momin ·
Derived from the Ladybird/SerenityOS ecosystem · License: see LICENSE and
provenance policy.