Trade-offs, Honestly
Every chapter so far has argued for something. This one audits the price list. Mar’s own documentation keeps a section titled “the honest caveats”, and this book ends in the same spirit, because a tool chosen on marketing is a tool resented in month three.
Where the walls are
The ecosystem is small and young. No package registry of a hundred thousand libraries; expect to write things a JavaScript developer would install (and, in fairness, audit forty transitive dependencies for). Breaking changes still land between versions. Building on Mar today means enjoying frontier weather.
The UI vocabulary is closed. If your product’s identity depends on bespoke visual design, the fixed vocabulary will chafe, and there is no HTML escape hatch by design. Evaluate this wall early: build one representative screen before committing.
Storage is SQLite, one file per app. Phenomenal for its class; a real ceiling for write-heavy, multi-region, or many-service systems. The Repo is deliberately minimal: no query DSL, no relations API, no raw SQL. Most apps never notice; data-analytics workloads will.
Numbers are exact. Int and Decimal cover counting, layout, game math, and money; approximate work with huge dynamic range (scientific computing, signal processing) does not fit, and Decimal caps at 34 significant digits rather than lose precision quietly.
One process, one machine. Scaling is vertical. This covers more than the industry admits, and it is still a boundary.
Interpreted execution. The tree-walking runtime is fast enough for 60fps games, which says a lot, but compute-bound inner loops (video encoding, large-scale simulation) belong elsewhere.
Who the trade suits
Mar concentrates its wins where one person or a small team owns a whole product: internal tools, dashboards, small and medium SaaS, team apps, indie games, personal software with real users. In that setting, the compiler-checked seams and the included scaffolding convert directly into shipped features, and the walls are mostly out of sight.
Signals that Mar is the wrong choice today: a design team with pixel-level opinions; data volume or write concurrency beyond one healthy SQLite file; heavy numerics; a hard requirement on some third-party SDK; an organization that cannot absorb language-version churn.
The deeper bet
Underneath the feature list, Mar is one wager made repeatedly: that guarantees compound better than options. Each removal (mutation, null, exceptions, floats, free-form markup, ad-hoc SQL, the second language) traded local convenience for a global property the compiler can hold forever. Options feel good on day one; guarantees feel good on day four hundred, when the codebase has grown past what anyone holds in their head and the compiler is the only teammate who has actually read all of it.
The Elm community, Mar’s direct ancestor, proved the bet can work for frontends: codebases famous for surviving years of refactoring without runtime exceptions. Mar’s contribution is extending the same wager across the wire, to the database, the API, the auth layer, and the deploy artifact, on the theory that the seams between layers were always where the worst bugs lived.
Whether that extension wins in the large is not yet proven; the language is young and says so. What this book hopes to have shown is that the design is not a pile of restrictions but a single idea applied uniformly, and that the idea is testable on your own next side project, which is, fittingly, exactly the scale Mar recommends for itself.
Build small things first.