# How the stack fits together Three products, three different jobs, one stack. [Bare](/bare/explanation/bare-runtime) is the engine: a small JavaScript runtime with a module system, native addons, and threads, and nothing else built in. P2P is the peer-to-peer building blocks—Hypercore, Hyperswarm, Autobase, and the rest—ordinary JavaScript modules that happen to run on Bare. [Pear](/) is the platform on top of both: a CLI, over-the-air updates, and the machinery that turns building blocks into a shippable app. Knowing which layer you're working at makes the rest of these docs easier to navigate. This page lays out the layers, bottom to top, and shows where each library you'll meet elsewhere belongs. ## The layers at a glance [#the-layers-at-a-glance] Each layer runs on the one beneath it. Read from the bottom up, it's a story about how raw C bindings become a peer-to-peer app you can install. The three product tabs in this site's sidebar map onto four of these layers: **Bare** covers the runtime and its userland modules, **P2P** covers the building blocks, and **Pear** covers the platform and app layers on top. ## The engine room: native foundations and the Bare runtime [#the-engine-room-native-foundations-and-the-bare-runtime] At the very bottom are C libraries: [`libjs`](https://github.com/holepunchto/libjs) (and its JavaScriptCore-backed sibling [`libjsc`](https://github.com/holepunchto/libjsc)) give an engine-independent, ABI-stable way to talk to a JavaScript engine; [`libuv`](https://github.com/libuv/libuv) provides the asynchronous I/O event loop; [`libudx`](https://github.com/holepunchto/libudx) carries the reliable UDP streams the networking stack rides on. [Bare](/bare/explanation/bare-runtime) sits directly on top. It's a small, embeddable JavaScript runtime that adds only what those C primitives can't supply on their own: a module system (with CommonJS/ESM interop), a native-addon loader, and lightweight threads. Everything else is left to userland—which is the next layer up. ## Bare userland: the `bare-*` modules [#bare-userland-the-bare--modules] Bare ships almost no standard library. The familiar runtime surface—file system, sockets, crypto, HTTP—lives in installable [`bare-*` modules](/bare/reference/bare/modules) you opt into. The same layer holds two other families that matter for cross-platform apps: * **Embedding & native** ([`bare-kit`](/bare/reference/bare/bare-kit), [`react-native-bare-kit`](/bare/reference/bare/bare-kit), and the typed RPC seam of [`bare-rpc`](/bare/reference/bare/modules/bare-rpc) + [`hyperschema`](/p2p/reference/helpers/hyperschema)) let a native app run a Bare core on a background thread. See [One core, many platforms](/bare/explanation/bare-on-native). * **Build & bundle** (`bare-pack`, `bare-bundle`, `bare-make`, `bare-build`) turn a Bare program and its dependencies into an embeddable bundle or a standalone executable. ## The P2P building blocks [#the-p2p-building-blocks] The libraries [P2P](/p2p) is built around—[Hypercore](/p2p/reference/building-blocks/hypercore), [Hyperbee](/p2p/reference/building-blocks/hyperbee), [Hyperdrive](/p2p/reference/building-blocks/hyperdrive), [Autobase](/p2p/reference/building-blocks/autobase), [Hyperswarm](/p2p/reference/building-blocks/hyperswarm), [HyperDHT](/p2p/reference/building-blocks/hyperdht), and [Corestore](/p2p/reference/helpers/corestore)—are ordinary JavaScript modules. They have no special status in the runtime; they run *on* Bare like any other dependency, and they don't require Pear at all. That's why the same storage and networking code works unchanged whether it's hosted by Electron on the desktop, a worklet on a phone, or a plain Bare or Node.js process with no Pear app around it. ## The Pear platform [#the-pear-platform] [Pear](/) is the layer that turns those building blocks into a product: [`pear-runtime`](/pear/reference/pear/runtime) spawns and updates your app, the [`pear-*` modules](/pear/reference/modules/pear-modules) supply application services, and the [Pear CLI](/pear/reference/pear/cli) stages, seeds, and releases it. Pear is built *on* both Bare and the P2P building blocks—it doesn't replace them. ## Apps: one core, many UI hosts [#apps-one-core-many-ui-hosts] At the top are the apps—[Keet](https://keet.io), [PearPass](https://pass.pears.com), and whatever you build. The recommended shape splits an app into a portable JavaScript **core** (peer-to-peer logic and storage) and a thin **UI host** that changes per platform: Electron on desktop, a native shell on mobile, a standalone binary in the terminal. The core is the same code everywhere; only the host swaps. That split is the subject of [Runtime and languages](/pear/explanation/runtime-and-languages) and [One core, many platforms](/bare/explanation/bare-on-native). ## See also [#see-also] * [Inside Bare](/bare/explanation/bare-runtime)—what the runtime layer actually adds. * [One core, many platforms](/bare/explanation/bare-on-native)—how the portable core reaches mobile and native apps. * [Runtime and languages](/pear/explanation/runtime-and-languages)—why the stack is JavaScript and how other languages join in. * [Bare modules](/bare/reference/bare/modules)—the catalog of `bare-*` userland modules. * [Primitives, helpers & tools](/p2p/reference)—the full P2P module catalog. * [Pear modules](/pear/reference/modules/pear-modules)—the `pear-*` libraries at the platform layer.