Polyglot Runtime Strategy
TypeScript is the default product language for Prox OS. It covers React apps,
TypeScript is the default product language for Prox OS. It covers React apps, Hono/Workers APIs, package contracts, SDKs, Storybook examples, and most runtime glue with one shared type system.
Polyglot work is welcome only when a specific runtime job justifies the extra toolchain, hiring, deployment, and debugging surface.
TypeScript First
Use TypeScript by default for:
- React and OS app UI.
- Browser-safe feature packages.
- Cloudflare Workers and Hono APIs.
- Shared contracts and manifests.
- SDKs, adapters, and repo tooling.
- Storybook and docs examples.
TypeScript keeps early platform iteration fast because the same types can move from package contracts to UI, API boundaries, docs, and tests.
When Python Makes Sense
Introduce Python when the work is naturally AI/data heavy:
- AI/ML pipelines.
- Embedding batch jobs.
- Image, video, OCR, and media analysis.
- Data cleaning and enrichment.
- Research notebooks and experiments.
- Offline evaluation jobs.
Python should usually sit behind a backend job boundary, not inside browser packages or OS shell runtime code.
When Go Makes Sense
Introduce Go for infrastructure-style binaries:
- CLI tools.
- Local agents.
- Sync daemons.
- Gateways and proxy layers.
- High-concurrency workers.
- Single-binary distribution.
Go is a good fit when deployment simplicity and concurrency matter more than deep UI or shared React contracts.
When Rust Makes Sense
Introduce Rust for performance and safety-critical runtime modules:
- WASM modules.
- Encryption or signing.
- Sync engines.
- Local runtime performance hot paths.
- Security-sensitive parsing or isolation.
Rust should have a narrow API surface and a clear owner. Do not introduce it for ordinary UI, docs, or CRUD service work.
When Java Or Kotlin Makes Sense
Java or Kotlin can be considered for:
- enterprise backend integrations,
- large customer deployments,
- ERP, banking, or integration-heavy systems,
- teams that already operate JVM infrastructure.
They should not be introduced early by default. Use them when a customer, runtime, or integration ecosystem makes the JVM the practical choice.
When A Desktop Client Makes Sense
Electron, Tauri, or a native desktop shell becomes relevant when Prox OS needs:
- local filesystem integration,
- tray/menu bar presence,
- offline caches,
- local agents,
- native notifications,
- deep links,
- desktop distribution,
- richer OS integration than the browser can provide.
The current browser OS should keep architecture-ready seams, but desktop client work should wait until local runtime needs are concrete.
Current Principle
TypeScript first. Add another language only when a specific runtime job, operational need, or product capability clearly pays for the extra complexity.