YAZAPROGRAMMING LANGUAGE
Beranda / Dokumentasi / RFC 0008: Linux, WebAssembly, Edge, and Mobile Targets
RFC / RANCANGANrfcs/0008-cross-targets-linux-wasm-edge-mobile.md
Status dokumen bukan klaim bahwa fiturnya sudah tersedia.

RFC dan proposal mencatat rancangan. Untuk kemampuan yang benar-benar dapat dipakai, lihat matriks kapabilitas runtime dan catatan rilis.

RFC 0008: Linux, WebAssembly, Edge, and Mobile Targets

Status: Accepted
Areas: Appendix G.18–G.19; Appendix H.13
Depends on: RFCs 0001–0003 and 0006

Decision: Accepted by the project owner on 2026-10-23. This approves the design direction; implementation and conformance evidence remain outstanding.

Summary

Define target profiles for Linux, WebAssembly/browser, edge runtimes such as Cloudflare Workers, and native mobile applications while keeping language semantics shared. The proposal separates portable business logic from platform UI and privileged host APIs; it does not promise one UI toolkit that behaves identically across browser, iOS, and Android.

Motivation

The blueprint targets web, backend, and mobile from one language. Current templates are scaffolds only: there is no Linux release profile, YAZA WASM/browser or edge compiler, JavaScript interop layer, iOS/Android compiler target, UI framework, or native mobile binding system.

The product owner has also selected YAZA UI as the intended default design system for future generated web projects and a shared design contract for future native mobile renderers. Its YAZA Frame Engine proposal is a future design direction and does not change this RFC's initial non-goal of shipping a universal UI engine with the first cross-target release.

Proposal

  1. Define a platform-independent core profile with deterministic types, error behavior, Text, Bytes, the ordered TextList collection available in the first profile, and no ambient filesystem, process, socket, or clock access. General generic lists and maps are not promised until their type and iteration semantics are specified and implemented.
  2. Define native Linux profiles for supported libc/architecture combinations, initially a documented macOS/Linux development flow followed by Linux release artifacts. Native system calls and libraries are target modules, not portable-core APIs.
  3. Make WASI 0.3 (Preview 3) components the first WebAssembly execution target for CLI, server, and component workloads. Pin the exact WIT package versions and require an explicit import allowlist. WASI 0.3's async future and stream interfaces are the chosen starting point for YAZA's async runtime; the first supported host matrix is Wasmtime 46 or newer. This is a developer-preview ecosystem, so YAZA must label the target experimental and keep its target ABI versioned.
  4. Add a separate browser-hosted core-Wasm target after the WASI component path. Browser output is a core WebAssembly module instantiated through browser APIs and a generated, capability-limited JavaScript host adapter; it does not assume browsers implement WASI. Browser networking, storage, DOM access, and timers are explicit imports granted by the adapter; no import is available implicitly.
  5. Define edge deployment as a separate WebAssembly host profile. Cloudflare-specific request, environment-secret, and outbound-fetch bindings are explicit capabilities; POSIX sockets, process spawning, and ambient filesystem access are unavailable in that profile.
  6. Keep DOM access in an explicit browser package. Provide a typed, reviewed interop layer rather than silently compiling arbitrary platform APIs into core code.
  7. Prototype native mobile on Android arm64-v8a first, using the Android NDK toolchain and a narrow C ABI between YAZA-generated native code and a generated JNI/Kotlin host shim. Add Android x86_64 for emulator/CI coverage, then prototype iOS arm64 with a narrow C ABI and generated Objective-C/Swift host shim. This order lets the current C-emitting compiler exercise a supported 64-bit mobile ABI before adding Apple's distinct build and packaging path. Native rendering work still needs platform lifecycle, text/input, accessibility, and GPU adapters.
  8. Generate bindings only from explicit, checked-in .yabi declarations that identify the exact platform API, minimum OS/API level, types, nullability, ownership, thread affinity, permission, and error mapping. The generator emits the YAZA declarations plus the narrow C/JNI or C/Objective-C/Swift shims and a machine-readable provenance report. It must not scrape or auto-expose entire Android/iOS SDKs. Each generated diff is reproducible and reviewed against the official SDK declarations; new APIs require human review and ABI/ownership/permission conformance tests before merge.
  9. Share models, validation, business rules, and serialization when they use the portable profile. UI rendering may use platform-native widgets or the future YAZA-owned renderer; pixel-identical UI is not a language guarantee.
  10. Tree shaking removes unreachable code and unused runtime modules, but minimum bundle/app size is measured and published per target rather than promised in advance.
  11. Target-specific capabilities are declared in the package manifest. yaza check --target rejects use of unsupported APIs before target linking.
  12. WebAssembly security tests verify memory isolation, import allowlists, CSP-compatible browser output, and adversarial host input. Edge tests verify host-binding behavior and size/time budgets; mobile tests verify permission boundaries and FFI ownership/threading rules.

Shared core profile contract

The shared core profile defines source semantics that must behave the same on native, WASI, browser-Wasm, edge, Android, and iOS targets. It is a language compatibility promise, not a promise that every runtime API exists on every host. Compiler support is currently partial; a profile cannot be advertised as conformant until the same positive and negative conformance suite passes on every target in its published matrix.

  • Portable values: Boolean, checked Int32 and signed 64-bit Number, Float64 with documented IEEE-754 edge behavior, UTF-8 Text, arbitrary-byte Bytes, ordered TextList, product shape, tagged variant, Option[T], and Result[T, E]. Text indexing/length units and serialization rules are defined by the language specification, not delegated to host defaults. Generic List[T]/Map[K,V], tuples, Decimal, Money, and Instant are excluded until their language contracts and implementations are accepted.
  • Portable computation: declared functions and modules, deterministic control flow, checked conversions, exhaustive matching, and pure standard-library operations. Integer overflow, division edge cases, floating-point non-finite values, equality, and collection iteration order must have the same documented result or error on every target.
  • Ownership and safety: only safe, owned values are available to portable code. Raw pointers, platform handles, inline assembly, unsafe FFI, ambient host access, and target-specific object layouts are outside the shared core. Until RFC 0002's source-level ownership and generated-code requirements are implemented and tested, this safety guarantee remains a target requirement rather than a claim about the current compiler.
  • No ambient effects: the core cannot read files or environment variables, spawn processes, access clocks, obtain randomness, open sockets, use databases, touch a DOM, or call a mobile API. Such effects require an explicit capability module and are checked against the selected target.
  • Async contract: RFC 0005 selects structured tasks, cooperative cancellation, and bounded resource ownership, but YAZA has no language-visible async/await yet. Those semantics enter a shared core version only after they are specified normatively and pass cross-target conformance. Adapters may map them to WASI 0.3 futures/streams, browser host tasks, or the mobile scheduler, but may not change ordering, cancellation, or error semantics. Until then, async APIs are target-specific and excluded from the shared core guarantee.
  • Conformance and versioning: every target runs the same semantic suite plus target-boundary tests. The package manifest names the core profile version and capability set; a target that lacks a required capability fails before execution with a diagnostic naming the missing capability. Adding a core feature requires cross-target tests and an explicit compatibility note.

Non-goals

  • A single cross-platform UI rendering engine in the initial target release.
  • Calling all Swift/Kotlin APIs without wrappers or ABI validation.
  • Guaranteeing a fixed APK/IPA or WASM bundle size before measurement.
  • Replacing native platform signing and release requirements.

Security considerations

WASM sandboxing depends on the engine and imported host functions; it does not neutralize unsafe host bindings. Mobile FFI can invalidate ownership and thread-safety guarantees. Capability manifests and target conformance tests are required for each platform release.

Staged implementation

  1. Stabilize portable core types, ownership, modules, and reproducible builds.
  2. Ship a Linux native profile with a supported libc/architecture matrix and documented shared-library requirements.
  3. Produce the pinned WASI 0.3 component target with a strict import allowlist, async conformance tests, and a supported Wasmtime host matrix.
  4. Add browser core-Wasm output, the generated browser adapter, DOM/network capabilities, and bundle-size reports; then add the edge host adapter with documented capability and resource limits.
  5. Prototype Android arm64-v8a and x86_64 with the narrow generated binding surface; validate lifecycle, permissions, ownership, and UI-thread rules.
  6. Add iOS arm64 only after the Android binding schema, generator, ABI review, and security process are repeatable.

Acceptance criteria

  • The same portable-core conformance suite passes on native and WASM targets.
  • Linux artifacts build and run on every declared libc/architecture profile, with dependencies recorded and no unsupported combination advertised.
  • WASM modules cannot use undeclared imports and pass sandbox boundary tests.
  • Edge builds use only allowed host bindings and pass request, execution-time, and bundle-size budget tests against the selected provider's test environment.
  • Mobile bindings document ownership, thread, exception/error, permission, and lifecycle behavior.
  • Build artifacts are reproducible and size reports include toolchain/runtime versions.
  • Platform-specific UI and behavior are accurately documented and tested on real target environments.

Resolved decisions

The project owner asked for a best-effort decision on 2026-10-24. The selected order is WASI 0.3 first and browser core-Wasm second as separate host ABIs; Android arm64-v8a first and iOS arm64 second; the shared-core guarantees are defined above. These are architecture decisions, not implementation evidence. WASI 0.3 is a recent developer-preview release; YAZA must version and label it accordingly. The Component Model is still released in incremental developer-preview milestones, so the supported version must be re-evaluated before each YAZA release.

References

← Kembali ke semua dokumentasiVersi dan status rilis →