A useful application.
Delivered as a file.

Download. Extract. Open.

1. Download the ZIP and extract the entire folder.
2. Open index.html from the extracted folder in a desktop browser.
3. Choose an example, inspect its source and try its local behavior.

The download is the maintained serverless gallery from the gallery release. It contains JavaScript examples and a browser Worker host. Local examples can run without a server; actions that contact an external service still require a connection.

Download the current ZIP ↓ · Prefer the hosted galleries?

Serverless here means a browser Worker.

In Gramlot this profile is not a cloud function hosting plan. @gramlot/gramlot-serverless packages JavaScript pages with the runtime and a Worker host. Page construction and local endpoint methods run in that Worker, on the person’s computer.

The browser renders the interface and manages bindings and behavior. A self-contained output can open from disk. The people using it need a browser; Node.js and npm belong to the author’s build environment.

Three reasons to consider it.

A registration form can be distributed as a file. A local calculator can explain an estimate without a round trip. A questionnaire can remain useful during disconnected work. In each case, the application’s value comes from the local behavior, not simply from putting HTML in an archive.

The current offline gallery is a concrete way to examine the profile. It runs JavaScript lessons locally; its pages are examples, not automatically your finished business application.

Build a first page.

The scaffold creates a JavaScript page and its project files. Install the packages, then build the output. The file includes the page, runtime and supported bundled resources. Keep external resources out of an offline promise unless you have actually packaged and tested them.

npm create @gramlot page registration
cd registration
npm install
npm run build

Read the explanation here. The working lesson and full contract are linked below.

Send the data when the workflow needs it.

Local completion and remote delivery are separate. save/restore supplies explicit typed draft files. JSON export supplies interchange data. sendHttp supplies a POST to a service that accepts it. Network operations still need connectivity and compatible origin/security policies.

A service could turn that JSON into a PDF. That receiver and the final response experience are application work; the exporter does not install a PDF backend.

Understand the boundary before choosing.

Python is not executed in the Worker profile. Everything shipped in the file is readable by its recipient, so it cannot hold server secrets. A local host is not a shared database, an authentication authority or a service that receives other people’s submissions.

State is in memory unless explicitly saved. Automatic offline queues, background synchronization and universal mobile file compatibility are not part of this explanation. For trusted or shared operations, combine the interface with a suitable service or use a server host.

KEEP EXPLORING

Follow the idea.