# How Makra differs

Makra sits between hand-maintained wrappers and per-page model extraction. It uses semantic inference to learn a structural program, then uses deterministic code to run that program.

## Compared with hand-written selectors

A CSS or XPath scraper is cheap, fast, and predictable once it exists. The cost appears before and after execution. A developer must inspect each site, write selectors, understand repeated structures, and repair the scraper when markup changes.

Makra removes selector authoring from the SDK contract. You describe the data you want. Makra learns structural bindings, measures whether they still cover the rendered page, and scopes relearning to uncovered structure.

Choose hand-written selectors when one stable site, maximum control, and minimum runtime overhead matter more than authoring cost. Choose Makra when there are many page classes, schemas change, or maintaining site-specific wrappers has become the larger expense.

## Compared with browser automation

Browser automation controls a page. It clicks, types, authenticates, waits for custom states, and navigates interaction flows. Extraction is only one possible outcome.

Makra renders JavaScript pages but its public extraction model is read-oriented. It supports bounded pagination, regional proxy selection, readiness waits, and one recovery retry. It does not expose a general action language for arbitrary clicks and form flows.

Use browser automation when the task is primarily an interaction. Use Makra when the target information is present after normal page loading or supported pagination.

## Compared with asking a model on every page

Per-page model extraction is easy to prototype because the request can be little more than a page and a prompt. The model remains in the value-producing path. Cost and latency grow with page count, repeated templates are understood repeatedly, and plausible output may lack document provenance.

Makra confines model work to structural comprehension and repair. The warm path evaluates stored programs. Returned values remain strings read from the document. The tradeoff is that Makra must maintain a page-class model and can pay a learning cost when its approximation groups incompatible layouts or splits one layout into too many classes.

## Compared with cached extraction results

A result cache answers the same request with old data. Makra's memory answers new requests with fresh data. A class learned for title and price may also contain bindings useful to a later request for reviews or availability.

The stored unit is reusable comprehension, not a page snapshot.

## The practical difference

| Property | Hand-written wrapper | Per-page model | Makra |
| --- | --- | --- | --- |
| Selector maintenance | Manual | None | Learned and repaired |
| Model inference on every page | No | Yes | No on a fully covered warm path |
| Current values read from page locations | Yes | Not guaranteed by architecture | Yes |
| New schema over a known page class | Code change | New prompt and inference | Binding retrieval and evaluation when known |
| Arbitrary interaction support | With browser code | Tool dependent | Not a general public SDK feature |
| Structural drift handling | Manual repair | Fresh inference | Coverage measurement and focused repair |

Makra's strongest claim is narrow and useful. The expensive unit of web extraction is often the number of distinct page structures, not the number of pages. Makra makes its cost model follow that unit.

Next, read [Where Makra fits](/markdown/makra-sdk/v0.0.3-beta/foundations/where-makra-fits).