# One React/Vite codebase, distinct host boundaries

> WorldScript Studio shares React/Vite product semantics across PWA and Tauri while keeping storage, networking, caching, and policy host-specific.

WorldScript Studio runs one React/Vite product on the web and as an installed PWA, with deployments on edge hosts and in Tauri desktop. In a case study published on 2026-09-27, its author describes shared domain concepts and explicit platform boundaries that select storage, networking, security policy, and caching behavior. Those hosts remain distinct despite sharing a codebase
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

<span id="what-the-project-shares"></span>

## Shared product semantics

WorldScript Studio describes itself as a local-first creative-writing workspace. Its
repository says there is no required WorldScript account or central manuscript database,
and that project state is stored locally in browser/PWA storage or the desktop app's local
data directory. It also says the cached PWA shell keeps core writing and planning useful
offline, while explicitly networked functions still require connectivity
([WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md)).

The case study treats the product model as the shared layer. Definitions of a project,
authoritative state, export, and behavior when an optional provider is unavailable should
not vary merely because the renderer is hosted differently. The implementation mechanisms
below that layer are allowed to differ. The author's rule is to share domain semantics and
interoperability contracts while exposing host capabilities through explicit adapters
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

React and Vite are part of the repository's common web-facing stack. The README identifies
React as the main UI and Vite as the web/PWA build system, while Tauri supplies the desktop
shell. Tauri's Vite guide documents this integration pattern directly: Tauri can launch a
Vite development server and run a Vite build command. It loads the generated distribution
directory through settings in `tauri.conf.json`
([Tauri Vite guide](https://tauri.app/start/frontend/vite/)).

That integration shares frontend assets without erasing the host. Tauri's guide configures
separate development and production locations, fixes the development port, exposes Tauri
environment values to Vite, and sets build targets for the WebView platforms described by
the guide. These host-aware build choices use the same frontend toolchain. They do not
establish that a browser tab and a desktop WebView possess the same APIs or authority
([Tauri Vite guide](https://tauri.app/start/frontend/vite/)).

## Storage remains host-specific

The repository's storage table gives the browser/PWA and Tauri columns different
authorities. It lists IndexedDB for browser project state and snapshots, along with assets. The
desktop side uses local filesystem stores under application data. API keys remain in a
separate encrypted-secret IndexedDB store in both columns, including the desktop WebView.
The table also says optional protected IndexedDB project data can be encrypted, while the
filesystem-backed desktop project store is not application-encrypted at rest
([WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md)).

The case study draws a product-language consequence from that difference. Two controls can
look similar while protecting different persistence paths. The actual browser or
filesystem backend determines where data lives and which lifecycle governs it. It also determines whether a
given encryption path applies. A shared interface therefore needs to identify the active
backend. A common label alone cannot promise protection
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

Browser storage is also scoped by origin. The README says its GitHub Pages, Vercel,
localhost, and custom-domain deployments do not automatically share IndexedDB or model
caches. The desktop filesystem store follows a different location and access model. A
cross-host product cannot infer that data saved under one web origin will appear in another
deployment or in the native store simply because the user sees the same React interface
([WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md)).

## Networking and policy change with the host

The report distinguishes browser fetch behavior from Tauri's native HTTP path. In the
WorldScript implementation, an adapter chooses the native plugin in the Tauri runtime and
the browser's `fetch` elsewhere. The author uses this difference for admitted local and
cloud endpoints on desktop while leaving browser requests subject to browser-origin rules
and server configuration
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

Tauri documents command scopes as granular allow or deny rules. Its scope guide uses the
filesystem plugin to illustrate directory restrictions and the HTTP plugin to illustrate
URL filtering. It also says deny scopes override allow scopes and warns command authors to
audit enforcement for bypasses. This supports a narrow capability boundary, but it does
not make every native request safe without correct configuration and implementation
([Tauri command scopes](https://tauri.app/security/scope/)).

Hosting affects response policy as well. The WorldScript README says its GitHub Pages
deployment cannot inject HTTP security headers and relies on a meta CSP there. It describes
the Vercel deployment as serving response security headers and a same-origin relay. The
case study uses this contrast to show that an identical static interface can operate under
different delivery and server-function guarantees
([WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md)).

Those facts argue for capability checks that name the host path. A browser deployment can
expose browser storage and network behavior; an edge host can add server functions and
response headers; Tauri can expose admitted native commands. None of those capabilities
should be inferred solely from a component being present in the source tree. The adapter
and deployment configuration together determine the available path
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

## The service worker stops at the desktop boundary

The web surface uses a service worker for its cached shell and offline fallback. The case
study says the Tauri branch takes the opposite action: it obtains existing service worker
registrations, unregisters them, enumerates Cache Storage, and deletes cache names owned by
WorldScript. The report presents this as protection against a stale browser cache serving
an offline fallback over the bundled desktop application
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

This is not a general requirement that every Tauri application unregister service workers.
It is a documented decision in this project's branch logic, tied to its cached web shell
and native bundle. The transferable question is which mechanism owns offline delivery on
each host. If the answer is a service worker on web and a packaged application on desktop,
the code should make that authority transition explicit
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

<span id="why-it-matters-for-pwa-developers"></span>

## Impact on PWA and Tauri release testing

The case study offers a concrete alternative to treating cross-platform work as either one
universal implementation or completely separate products. Product entities and file
formats can remain shared. Storage, network transport, offline delivery, security policy,
and operating-system integration can sit behind narrow host adapters. This keeps platform
differences visible at the points where they affect user data and capabilities
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

For an installed PWA, installation does not turn origin-scoped browser data into a native
filesystem store. WorldScript's own matrix continues to describe its PWA path as browser
storage and its Tauri path as filesystem persistence. That distinction affects migration,
backup, recovery, encryption claims, and the UI language used to identify where a project
is saved ([WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md)).

The same discipline applies to network-dependent functions. A cached PWA shell can load
while an optional remote provider, collaboration service, first model download, or other
networked integration remains unavailable. The WorldScript README explicitly separates
offline-capable core writing from functions that require connectivity. Product status
should therefore describe those capabilities separately instead of using shell availability
as proof that every integration is ready
([WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md)).

Testing can follow the same boundary map. Shared domain tests can establish invariant
project semantics. Adapter tests can establish which persistence and transport is selected.
Host-specific integration tests can then cover browser origins, service worker lifecycle,
Tauri scopes, and filesystem behavior. The source report does not provide a universal test
suite, but its architecture makes those separate responsibilities observable
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

Documentation must remain just as specific. The repository warns that guarantees from one
deployment row must not be generalized to another. A feature description should say which
host supplies storage, headers, server functions, native transport, or offline behavior.
That prevents a true statement about one build target from becoming a false product-wide
promise ([WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md)).

Release qualification likewise cannot stop at the shared web pipeline. The README says the
normal web PR pipeline is not the complete native release qualification surface; native or
Tauri changes require the dedicated desktop build workflow and its platform-specific evidence.
The repository also distinguishes updater-artifact integrity signatures from operating-system
code signing, naming Windows Authenticode and macOS Developer ID signing/notarization separately.
Even after the common frontend build passes, a desktop release retains host-specific validation
responsibilities, and the two signing paths are not interchangeable
([WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md)).

WorldScript Studio uses the pattern "share the contract, select an implementation, and state the boundary." Its storage table, deployment descriptions, fetch adapter, Tauri scopes, and service worker teardown expose differences behind the shared React/Vite frontend. Sharing that frontend does not deliver "build once, behave identically."
([One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld)).

## Related entries

- [Capabilities](/reference/capabilities/): see catalog of web app capabilities.
- [Performance](/reference/performance/): see performance reference material.
- [Storage](/reference/storage/): see browser storage APIs and persistence concepts.

## Open and unverified

- Whether WorldScript Studio changes any cited adapter or backend after the referenced revision is not confirmed; the same applies to deployment boundaries.
- Whether another React/Vite and Tauri product should use the same storage split is not confirmed.
- The migration path between this project's browser stores and desktop filesystem store is not confirmed.
- The behavior of every optional provider under each offline transition is not confirmed.
- The platform-specific results of the project's native release workflows are not confirmed.
- Whether the project's future desktop roadmap preserves the same Tauri boundary is not confirmed.

## Sources

- [One React/Vite product across PWA and Tauri](https://dev.to/qnbs/one-reactvite-product-across-pwa-and-tauri-without-pretending-they-are-identical-17ld) (dev.to)
- [WorldScript Studio README](https://github.com/qnbs/WorldScript-Studio/blob/main/README.md) (github.com)
- [Tauri with Vite](https://tauri.app/start/frontend/vite/) (tauri.app)
- [Tauri command scopes](https://tauri.app/security/scope/) (tauri.app)