10 · Desktop & Mobile — one skillset, more screens (optional phase)

By Phase 9 the Library runs in any browser. This optional phase shows how the SAME JavaScript/TypeScript/React skillset also ships desktop installers and phone apps. Mostly a read-and-understand phase — build it only if a real need appears.

1. The map — where code can run

Target	Tool	What it really is	Famous examples
Browser	React (done)	your Phase 6 app	every website
Desktop (Win/Mac/Linux)	Electron	your web app + its own private Chrome + Node, zipped into an installer	VS Code, WhatsApp Desktop, Slack, Discord
Phone (Android/iOS)	React Native	React components that render REAL native buttons/lists — not a webpage	Instagram, Discord mobile, Shopify

Why these exist at all Before them, desktop meant C++/C#, iOS meant Swift, Android meant Kotlin — three more languages, three codebases, three teams. Electron (2013, built FOR the Atom editor) and React Native (2015) let web teams reuse what they have. The trade: bigger downloads and more memory than true native. For most business apps — including a library system — nobody notices.

2. Electron in one picture

Two processes, and you know both already An Electron app runs your React build inside a bundled Chromium window (the renderer — browser world, DOM rules apply) plus a main process in Node (files, menus, tray — Node world, §1 of the Node notes). The two talk over IPC messages — request/response again, just inside one app instead of over a network. VS Code — the editor you've used since Phase 0 — is exactly this. You've been living inside an Electron app the whole course.

When the Library would want it A front-desk machine that must work offline-first, auto-start with Windows, and print receipts — that's the Electron use case. A URL on the desk computer covers everything else with zero extra code.

3. React Native in one picture

// same mental model, different vocabulary — no DOM on a phone
<View style={styles.row}>              // ← div
    <Text>{book.title}</Text>          // ← the ONLY place text may live
    <Pressable onPress={borrow}>       // ← button/onClick
        <Text>Borrow</Text>
    </Pressable>
</View>

What transfers, what changes Transfers untouched: components, props, useState/useEffect, the no-mutation rule, Zustand store, fetch to your Fastify API, all your TypeScript. Changes: HTML tags → View/Text/Pressable, CSS files → style objects, and there's no localStorage (AsyncStorage instead). The thinking — UI = f(state) — is identical; that's the point of having learned React first. Tooling: Expo makes dev painless (scan a QR code, the app runs on your real phone).

The one server change a phone forces On your phone, localhost:3000 means the phone itself — not your PC. The phone must call your PC's network address (e.g. 192.168.1.5:3000), and later a real deployed URL. First lesson of leaving the machine: localhost was always "this machine", and now "this machine" changed. Phase 10 makes the API reachable from anywhere, properly.

4. How to choose (the pro's checklist)

Situation	Answer
Works fine as a website?	Ship the website. Seriously — most "we need an app" requests don't.
Desk machine, offline, printers, auto-start	Electron
Users need it in their pocket, push notifications, camera	React Native
Just want a home-screen icon + offline cache	PWA — a website with a manifest; smallest effort of all

5. The mental model to keep

Idea	One line to remember
Electron	your web app + private Chrome + Node in an installer — VS Code is one
React Native	React thinking, native widgets — View/Text/Pressable instead of div/span/button
What carries over	everything conceptual: components, state, store, fetch, TS
localhost lesson	"this machine" changes meaning when the app leaves your machine
Default answer	a good website first; wrap it only for a reason

← Prev: Auth · Back to contents · Next: Git & Deployment →