Architectural Positioning

Framework comparisons become stale quickly. Pricing changes, features move between core and plugins, runtimes add capabilities, and benchmark results depend on workload. This page therefore compares architectural approaches, not volatile product checklists.

Where Stacks sits

Stacks combines two ideas:

1. an opinionated, integrated TypeScript/Bun framework;
2. a draft language-neutral protocol intended to make its conventions and behavioral contracts portable.

less integrated                                              more integrated

independent libraries ── metaframework ── full-stack framework ── Stacks.js
                                                         + protocol draft

Integration can reduce selection and glue work. It also expands the surface that one project must stabilize, test, document, and upgrade.

Approach comparison

Distinguishing questions

Instead of counting checkmarks, ask:

Architecture

• Where does reusable business behavior live?
• Can it run outside HTTP?
• What is the observable middleware/validation/authorization order?
• How do user overrides interact with framework defaults?

Data and types

• Is schema declared once or copied across layers?
• Which artifacts are inferred, generated, or runtime-validated?
• Can generated migrations be reviewed before apply?
• Which dialects pass the same contract tests?

Replaceability

• Is a “driver” a real interface with multiple tested implementations?
• Does selecting an unsupported provider fail loudly?
• Can an application change provider without changing domain logic?

Operations

• Which deployment topologies are tested at the pinned revision?
• How are request IDs, logs, health, queues, and rollbacks verified?
• Which state is process-local and which is shared?

Maturity

• Is the project pre-1.0?
• Are compatibility and deprecation policies published?
• Do code samples run in CI?
• Are security and performance claims backed by independent or reproducible evidence?

Stacks.js strengths at the audited revision

Source revision bf1245e3 demonstrates:

• a coherent application layout and override model;
• Actions with validation, authorization, and hooks;
• Models with relationships, traits, factories, and migration generation;
• routing, middleware, request context, API resources, and error handling;
• broad authentication/authorization primitives;
• sync/database/Redis Job execution and scheduling;
• real-time and notification surfaces;
• request IDs, structured logs, and health checks;
• an extensive Buddy CLI and a wide package/test surface.

Stacks.js tradeoffs at the audited revision

• Root and workspace versions differ; a generated source/package manifest now records the exact mapping.
• The runtime registry exposes every audited driver status and rejects known unsupported selections.
• OpenAPI and declarations include generated artifacts that must be kept fresh.
• Environment encryption v2 replaces the simplified construction, but RFC ratification and independent cryptographic review remain open.
• Cloud capability depends partly on the installed ts-cloud version.
• Craft desktop delivery requires an external binary; its published matrix has zero stable targets pending platform evidence and signing.
• The protocol suite and reports are public, but Stacks currently makes no Core, Standard, or Complete claim.

About cost and lock-in

Open-source licensing, hosted-service pricing, and infrastructure cost are separate dimensions. A framework package may be free while its chosen database, SMS, AI, email, or cloud provider costs money. Self-hosting may avoid a subscription while increasing operational cost.

Similarly, “no lock-in” is too broad to be useful. Evaluate lock-in by layer:

• source and license;
• runtime APIs;
• model/query semantics;
• generated migrations;
• provider-specific infrastructure;
• data export;
• operational tooling;
• application knowledge and conventions.

Stacks’s driver and protocol ambitions can reduce some forms of coupling, but only tested alternative paths provide evidence of portability.

About performance

This documentation does not publish cross-framework requests-per-second or “N× faster” tables. A valid comparison must pin versions, behavior, data, hardware, concurrency, warm-up, and errors, then publish scripts and raw results.

Use the performance methodology to evaluate your workload.

When to evaluate Stacks.js

Stacks.js is a reasonable candidate when:

• Bun and TypeScript are intentional choices;
• the team values a broad convention-driven framework;
• Actions, model-driven artifacts, and application overrides fit the design;
• versions can be pinned and 0.x changes can be scheduled;
• the exact database, queue, provider, and deployment paths will be tested.

Choose or retain another approach when its ecosystem, compatibility policy, deployment evidence, staffing familiarity, or specialized capability better matches the system. The protocol proposal is not an argument that every application should use the reference implementation.

Maintaining a named-product comparison

If the project publishes a comparison of current frameworks, it should be a separate dated research artifact with:

• exact product and version;
• official primary sources;
• capture date;
• definitions for “built in,” “supported,” and “production-ready”;
• public benchmark methodology;
• a correction/update process.

That keeps the protocol durable while allowing current market research to evolve independently.