# For teams whose TypeScript app has become a system.

NetScript is a meta-framework: it coordinates the web layer, services, durable runtimes, and operations you would otherwise integrate by hand. The trade is explicit — pick-any-library freedom for a coordinated Deno workspace.

[Start a workspace](https://rickylabs.github.io/netscript/netscript/quickstart/) [Read the mental model](https://rickylabs.github.io/netscript/netscript/concepts/)

If the product is a static site, a short-lived prototype, or one request/response process, start with Fresh or Hono. NetScript begins to pay for itself when the boundaries between processes, background work, and the browser have become part of the product.

## 1. The integration tax

You shouldn't have to assemble a backend from a dozen libraries that have never met. The cost is not choosing them once; it is maintaining the seams between them:

1. **The service and browser disagree.** Request and response shapes drift until a production call finds the mismatch.
2. **A retry loop stands in for durable state.** Multi-step workflows lack recorded checkpoints or explicit rollbacks, leaving the system half-executed when a process dies.
3. **Resources and telemetry are assembled separately.** Queue, service, database, health, and trace configuration drift, so an incident crosses several tools before it becomes an explanation.

That standing maintenance is the **integration tax**: unrelated tools pretending to be one system.

## 2. What a meta-framework changes

NetScript does not replace the underlying primitives — Fresh renders, Hono serves, and Postgres stores as they would without it. It standardizes boundaries that become expensive after they have spread through an application: shared contracts keep handlers and callers aligned, durable runtimes make long-running work explicit, and generated resource wiring keeps processes, dependencies, and telemetry in one operational model. These constraints cost flexibility; their value is that a team does not redesign the same seams independently in every service.

NetScript makes those boundaries operational. Services serve the contract at request time, plugin runtimes own the work that outlives a request, and Aspire brings up the resources with their telemetry connected. The implementation details live in [Core concepts](https://rickylabs.github.io/netscript/concepts/).

## 3. Compare the center of gravity

No row is a universal winner. Choose the system whose primary constraint matches yours.

**Where each choice starts, and what NetScript changes**

| Name | Type | Description |
| --- | --- | --- |
| `Fresh or Hono` | `The web app or small API is the whole system` | NetScript uses Fresh and Hono as foundations, then adds service contracts, plugin runtimes, and an Aspire workspace. The cost is more framework and more project shape. |
| `Next.js` | `React and the Next ecosystem are the center` | NetScript chooses Deno with Fresh and Preact, plus explicit service and durable-runtime boundaries. It is not the React/Next path; choose the web ecosystem your product needs. |
| `Encore-style stack` | `Integrated infrastructure workflow is the center` | NetScript keeps a Deno/JSR workspace in the application and uses .NET Aspire for local orchestration through an adapter. It provides less managed infrastructure, so deployment and operations remain your responsibility. |
| `Temporal` | `A dedicated workflow platform is the main decision` | NetScript's saga core keeps TypeScript definitions, store and bus ports, transports, and compensation inside a broader application workspace. It is not a drop-in Temporal API. |
| `Assemble it yourself` | `Maximum component choice is a requirement` | You can choose every queue, tracer, service layer, and runtime independently. NetScript constrains those choices; assembling them yourself leaves every integration seam with your team. |

For the longer comparison — what the canonical getting-started flows of Next.js, Nuxt, SvelteKit, Laravel, and Rails teach first, where NetScript's ordering diverges, and where those peers are ahead today — see [how NetScript's path compares](https://rickylabs.github.io/netscript/explanation/compared/).

## 4. The trade-offs are real

- **The package family is pre-1.0.** APIs move, so scaffolded imports use exact `@0.0.6` pins. If you need a frozen surface today, NetScript is not ready for you.
- **The .NET Aspire CLI is the default orchestration path.** Scaffold with `--no-aspire` to opt out; resource wiring and local telemetry then belong to you. [See the Aspire boundary](https://rickylabs.github.io/netscript/quickstart/aspire/).
- **The web layer is Fresh and Preact.** That is a deliberate fit, not compatibility with the React/Next ecosystem. [See the web layer](https://rickylabs.github.io/netscript/web-layer/).
- **A coordinated workspace adds structure a one-process app may never use.** Durability, plugin runtimes, and multi-resource operations justify that cost only when the product needs them.
- **NetScript is not a hosted platform.** You own the workspace and the deployment decisions.

If those are the problems and trade-offs you recognize, [start the workspace](https://rickylabs.github.io/netscript/quickstart/).