# Architecture The goal of this document is to make it easier for contributors (and anyone who’s interested!) to understand the architecture of the framework. The whole Leptos framework is built from a series of layers. Each of these layers depends on the one below it, but each can be used independently from the ones built on top of it. While running a command like `cargo leptos new --git leptos-rs/start` pulls in the whole framework, it’s important to remember that none of this is magic: each layer of that onion can be stripped away and reimplemented, configured, or adapted as needed, incrementally. > Everything that follows will assume you have a good working understanding > of the framework. There will be explanations of how some parts of it work > or fit together, but these are not docs. They assume you know what I’m > talking about. ## The Reactive System: `leptos_reactive` The reactive system allows you to define dynamic values (signals), the relationships between them (derived signals and memos), and the side effects that run in response to them (effects). These concepts are completely independent of the DOM and can be used to drive any kind of reactive updates. The reactive system is based on the assumption that data is relatively cheap, and side effects are relatively expensive. Its goal is to minimize those side effects (like updating the DOM or making a network requests) as infrequently as possible. The reactive system is implemented as a single data structure that exists at runtime. In exchange for giving ownership over a value to the reactive system (by creating a signal), you receive a `Copy + 'static` identifier for its location in the reactive system. This enables most of the ergonomics of storing and sharing state, the use of callback closures without lifetime issues, etc. This is implemented by storing signals in a slotmap arena. The signal, memo, and scope types that are exposed to users simply carry around an index into that slotmap. > Items owned by the reactive system are dropped when the corresponding reactive > scope is dropped, i.e., when the component or section of the UI they’re > created in is removed. In a sense, Leptos implements a “garbage collector” > in which the lifetime of data is tied to the lifetime of the UI, not Rust’s > lexical scopes. ## The DOM Renderer: `leptos_dom` The reactive system can be used to drive any kinds of side effects. One very common side effect is calling an imperative method, for example to update the DOM. The entire DOM renderer is built on top of the reactive system. It provides a builder pattern that can be used to create DOM elements dynamically. The renderer assumes, as a convention, that dynamic attributes, classes, styles, and children are defined by being passed a `Fn() -> T`, where their static equivalents just receive `T`. There’s nothing about this that is divinely ordained, but it’s a useful convention because it allows us to use zero-overhead derived signals as one of several ways to indicate dynamic content. `leptos_dom` also contains code for server-side rendering of the same UI views to HTML, either for out-of-order streaming (`src/ssr.rs`) or in-order streaming/async rendering (`src/ssr_in_order.rs`). ## The Macros: `leptos_macro` It’s entirely possible to write Leptos code with no macros at all. The `view` and `component` macros, the most common, can be replaced by the builder syntax and simple functions (see the `counter_without_macros` example). But the macros enable a JSX-like syntax for describing views. This package also contains the `Params` derive macro used for typed queries and route params in the router. ### Macro-based Optimizations Leptos 0.0.x was built much more heavily on macros. Taking its cues from SolidJS, the `view` macro emitted different code for CSR, SSR, and hydration, optimizing each. The CSR/hydrate versions worked by compiling the view to an HTML template string, cloning that `