// resources

FAQ and technical context.

Answers to common questions about the platform, its capabilities, and its constraints. Written for engineers making infrastructure decisions.

Frequently asked questions.

What is cpp.js?

cpp.js is an open-source orchestration system that compiles C++ libraries for web (WebAssembly), iOS, and Android targets from a single configuration. It handles dependency resolution, automatic bindings generation, and cross-platform packaging. It is the open-source foundation and technical proof layer that Celoce's commercial infrastructure extends.

What is Emscripten+?

Emscripten+ is Celoce's extended WebAssembly interoperability layer. It extends and re-architects Emscripten's interoperability capabilities, providing improved embind interoperability, C++ object-oriented interoperability, overloaded function support, and enhanced runtime binding workflows. It does not replace Emscripten; it extends it with interoperability enhancements for production workflows.

What is JSI++?

JSI++ is Celoce's extended React Native runtime interoperability layer (JSI++: extended React Native runtime interoperability layer). It extends and re-architects JSI's interoperability capabilities, providing embind-compatible JSI integration, C++ object interoperability, unified runtime semantics, and reduced bridge inconsistency across platforms.

What is Celoce Cloud?

Celoce Cloud is distributed build execution and artifact caching infrastructure. It executes builds remotely, caches artifacts for reuse, and distributes compiled outputs via CDN. It provides reduced setup overhead and reusable build outputs compared to local Docker-based workflows.

What is Celoce Enterprise?

Celoce Enterprise is a self-hosted build control plane for organizations that require full control over their compilation environment and artifacts. It includes internal binary registries, secure compilation pipelines, governance and audit logging, and reproducible builds infrastructure deployed on your own systems.

Does Celoce use AI?

No. Celoce has zero AI runtime or build dependency. It does not require LLMs or AI models to compile, package, or run native code. The core infrastructure is deterministic systems software, not AI inference.

The relationship is the reverse: AI-agent workflows and AI-based companies can consume Celoce infrastructure. They can use Celoce through the same commercial infrastructure as human developers. They rely on Celoce infrastructure to gain native C++ performance for their cross-platform workflows. With Celoce, they can use C++ libraries through a unified cross-platform build and interoperability layer.

Is the build plane deterministic? Does it depend on AI?

Yes, deterministic. No, no AI dependency. Celoce has zero AI runtime or build-time dependency. The core infrastructure is deterministic systems software: the same inputs always produce the same artifacts. AI agents are consumers of the API, not part of the engine.

Why not use Emscripten directly?

Emscripten compiles C/C++ to WebAssembly. cpp.js and Celoce extend Emscripten with workflow abstraction: automatic dependency resolution, bindings generation, multi-target output (web + mobile), artifact caching, orchestration, and deployment consistency.

For single-file compilations, Emscripten alone may be sufficient. For libraries with transitive dependencies and multi-platform targets, the orchestration layer reduces significant operational complexity. See the detailed comparison.

How is this different from Bazel, Buck2, vcpkg, or Conan?

Bazel and Buck2 are build orchestrators optimized for very large monorepos - their unit of work is computing the minimum rebuild set across a graph of targets. Celoce's unit of work is different: compile and package a C/C++ library as a polyglot artifact for web, iOS, Android (and soon Rust, Go, Swift, Kotlin), with bindings generated automatically.

The closer comparables are vcpkg and Conan - package managers for C/C++ - neither of which targets WebAssembly or mobile as first-class outputs. Celoce extends that pattern to the modern target set, with a managed cloud option (Celoce Cloud) and a self-hosted control plane (Celoce Enterprise) for teams that need it.

Can builds run locally?

Yes. cpp.js runs entirely locally using Docker-based toolchains. No account or cloud connection is required. Celoce Cloud is optional and provides remote build execution for teams that want to avoid maintaining local build environments.

How does caching work?

Celoce Cloud caches compiled artifacts by content hash. When a build is requested, the system checks whether an identical configuration (same source, same dependencies, same target) has been built before. If a cached artifact exists, it is returned without recompilation. This is particularly effective for libraries that change infrequently but are rebuilt often.

How does Celoce handle copyleft (LGPL/GPL) library licensing?

Celoce Cloud executes builds on behalf of customers; it does not itself redistribute compiled outputs. License obligations of underlying libraries - including any LGPL or GPL components - remain with the customer running the build, the same as if they had run the toolchain locally. The Celoce Hub catalog identifies the license of each library so teams can make informed adoption decisions.

For Enterprise customers, we generate compliance artifacts (notice files, SBOM exports, source-availability declarations) as part of the build pipeline, turning licensing rigor into a supported workflow rather than a customer burden.

What workloads benefit most?

Compute-heavy workloads see the most significant benefits: geospatial processing, numerical computing, media encoding/decoding, physics simulation, and cryptographic operations. These are domains where C/C++ implementations have years of optimization that JavaScript alternatives cannot easily replicate. See supported workloads for details.

What are the limitations?

Not all C++ libraries are portable to WebAssembly. Libraries that depend on OS-specific APIs, GPU drivers, or kernel features may not compile. Threading support depends on environment configuration (SharedArrayBuffer, COOP/COEP headers). Performance varies by workload: compute-bound tasks benefit most. See the Known Limitations section below for details.

Is there a learning curve?

Minimal. Celoce works with Claude Code, Cursor, Codex CLI, Copilot CLI, Gemini CLI, OpenCode, and any agent that can follow instructions. Human developers can start just as quickly with npm create cpp.js@beta.

Can AI agents and automated systems use Celoce?

Yes. AI-agent workflows can use Celoce through the same APIs, SDKs, and CLI tooling as human developers. They call Celoce Cloud APIs for compilation, trigger distributed build and packaging pipelines, and run end-to-end build workflows.

AI-generated application code is often written in Python, JavaScript, or TypeScript. With Celoce, AI-agent workflows can move performance-sensitive parts into C++ while targeting supported web and mobile platforms. They can add custom C++ code and use native original unmodified C++ libraries. Celoce provides the infrastructure; the AI-agent workflows are the consumers.

Known Engineering Constraints

Engineering credibility requires honesty about boundaries. These are the current constraints of the Celoce build plane.

Not all libraries are portable

Libraries that depend on OS-specific system calls, GPU drivers, or kernel-level APIs may not compile cleanly to WebAssembly. We document supported library categories explicitly.

Threading depends on environment

Multi-threading via SharedArrayBuffer requires specific browser and server configurations (COOP/COEP headers). We provide setup guidance per host environment.

WebAssembly memory limits exist

WASM has a 4 GB memory limit in most current runtimes. Startup time includes module instantiation, which we minimize but cannot eliminate.

Performance varies by workload

Compute-bound workloads see the largest benefit. I/O-bound tasks dominated by JS interop calls may see smaller improvements. We publish per-workload benchmarks rather than a single hero number.

// known limitations

What we don't claim.

Engineering credibility requires honesty about constraints. These are the current boundaries of the platform.

Not all libraries are portable

Libraries that depend on OS-specific system calls, GPU drivers, or kernel-level APIs may not compile to WebAssembly. Portability depends on the library's dependency surface.

Some APIs require adaptation

File system access, networking, and device APIs behave differently across WebAssembly, iOS, and Android. Runtime differences exist across platforms, and some library features may need platform-specific adaptation layers.

Threading depends on environment

Multi-threading via SharedArrayBuffer requires specific browser and server configurations (COOP/COEP headers). Not all deployment environments support this.

WebAssembly constraints exist

WASM has a 4GB memory limit in most runtimes. Startup time includes module instantiation. Some C++ features (exceptions, RTTI) have overhead in WASM.

Performance varies by workload

Compute-bound tasks (math, encoding, data processing) see the most benefit. I/O-bound tasks or workloads dominated by JavaScript interop calls may see less improvement.

Some integrations may require adaptation

Not all C++ APIs map directly to JavaScript or mobile runtime semantics. Complex APIs may need thin interoperability layers to provide idiomatic interfaces on each platform.

Questions? Let's talk.

If your question isn't answered here, reach out. We're engineers and prefer technical conversations.