Web Development Workflow

zolo dev recognizes a web program when it reaches http.serve. Web mode keeps the VM and the server alive while source files change.

Start a session¶

zolo dev src/main.zolo

The CLI prints the local URL and a hot everything banner. Use --mode=web to require web mode, --mode=script for the classic script swap behavior, and --workers=N to describe the production worker count while development stays on one live VM.

What happens on save¶

1. The changed source and compile-time file dependencies are recompiled.
2. The entry module is swapped into the live VM.
3. let<shared> values are kept when their names still exist.
4. The development server emits an event over SSE.
5. The browser fetches the current route and morphs the new document into the live DOM.
6. Changed islands are rehydrated and signal state is carried where key/count identity is safe.

This is not a full page reload. Unsubmitted form input, focus and client state outside changed island roots can survive a server edit.

Changing the initializer text of a shared value is reported, but the running value wins until an explicit restart. Press r in the dev session when a clean process is what you want.

Compile errors keep the app alive¶

A failed edit does not replace the last good program. Connected tabs show an overlay with the diagnostic, code frame and suggestion when available. Fixing the source clears the overlay and applies the next successful update.

Files read through compile-time filesystem APIs are watched as dependencies, so embedded CSS or templates participate in the same reload cycle.

Production is a different mode on purpose¶

Development runs on the VM because in-place swaps need a live interpreter. Before shipping, build and test the backend selected by the project:

zolo build

Views, markup, islands, actions and scoped CSS have output parity across the VM, LLVM and Cranelift. The std::web Request/Cookies layer is the current exception and should be treated as VM-only until its declaration-module types are available to AOT lowering.

Browser Lab versus local development¶

The Verniz Lab is the fastest way to explore a component. It runs a single source file through the same WASM-hosted compiler used by the Zolo playground and renders the printed document in a sandboxed iframe.

Use the local CLI when you need a listening HTTP server, routing, @action, cookies, databases, multiple files or the real zolo dev state-preserving reload protocol.

For complete programs, see the examples/features/36-web/ directory and the examples/apps/todo/ development-server example.