How a web page becomes alive.

A web page starts as structure. Then it gets style. Then it gets behavior. Then it connects to other systems.

This is the simple mental model: HTML gives the page a body, CSS gives it visual character, JavaScript makes it respond, and APIs let it talk to places outside itself.

Frame it this way: web coding is less mysterious when you can point to what each layer is responsible for.

HTML is the page's frame.

HTML is not a full software framework like React or Next.js. It is more basic and more important: it is the markup that gives the page its parts.

Headings, paragraphs, links, buttons, forms, images, tables, and sections all begin as HTML. Without it, CSS has nothing to style and JavaScript has nothing reliable to control.

<section>
  <h1>Shelter Dashboard</h1>
  <p>Open shelters and available capacity.</p>
  <button>Show open shelters</button>
</section>

• HTML is read by browsers, screen readers, search engines, and code.
• Good HTML makes the page easier to style, test, and improve later.
• When HTML is clear, the rest of the system has a stable foundation.

CSS gives the structure a visual voice.

CSS controls color, spacing, type, layout, borders, states, and motion. It turns raw HTML into something that feels intentional.

The important idea is separation: HTML says what a thing is. CSS says how that thing should appear on different screens.

Plain version: CSS is not decoration after the real work. CSS is part of how the interface communicates.

JavaScript makes the page react.

JavaScript listens for events and changes the page. Clicks, searches, filters, maps, menus, calculators, form validation, and live updates all depend on behavior.

HTML can place a button on the page. CSS can make it look right. JavaScript decides what happens when someone presses it.

button.addEventListener("click", () => {
  panel.textContent = "Showing open shelters";
});

An API is how systems talk.

An API is a doorway with rules. One system asks for something in an agreed format, and another system responds in an agreed format.

An API is not automatically the backend. It is the connector. It can connect your frontend to your backend, your map to ArcGIS, or your dashboard to a weather service.

Simple rule: if one piece of software needs to ask another piece of software for something, an API is probably involved.

The frontend is what the person touches.

The frontend runs in the browser. It is the visible and interactive part: pages, buttons, menus, forms, maps, charts, tables, and visual feedback.

Frontend work blends structure, style, and behavior. A good frontend does not just look nice. It helps people understand where they are, what changed, and what to do next.

In a Red Cross-style map app: the frontend is the map screen, the filter controls, the popup, and the visible workflow.

The backend does work out of sight.

The backend usually runs on a server. It can check permissions, talk to databases, call secure services, process files, generate reports, or protect secrets.

The user may never see the backend directly. They see the frontend. But the frontend often depends on backend work to get trusted data and complete real tasks.

Python is a general-purpose workbench.

Python is a full programming language, not just a cleanup tool. It is good at telling the computer to do repeatable work: read files, transform data, call APIs, run GIS analysis, generate reports, and power server-side logic.

In this learning map, Python is the lane for automation, analysis, and backend work. HTML/CSS/JavaScript still own the browser experience, but Python often prepares the data, checks the logic, or runs the service behind it.

Plain version: use Python when the work needs calculation, automation, GIS processing, backend logic, or repeatable analysis. Use HTML/CSS/JS when the work needs to become the visible browser experience.

Your coding workspace has two doors.

An IDE like Cursor is the visual workbench. It helps you read files, edit code, search a project, and use AI assistance without leaving the project.

The command line is the direct control panel. It runs scripts, starts local servers, installs packages, checks Git status, and talks to tools that do not have buttons.

Beginner rule: you do not need to love the command line. You need to recognize when it is the shortest path.

Build, store, publish, and remember.

Git and GitHub track your project history. Vercel publishes the project to the web. Supabase gives an app a database, login system, storage, and backend-like services when a static page is no longer enough.

These are not the same thing, but they often sit next to each other in one real project.

• Git is the version tracking tool on your machine.
• GitHub is where the tracked project can live online.
• Vercel is where the project can become a public URL.
• Supabase is where an app can keep structured data.

Codex, Claude, Copilot, and Gemini are different kinds of help.

Think of AI coding tools as teammates with different seats. Some are inside the editor, some are local agent workspaces, some are chat-based explainers, and some connect to documents or browser context.

The important beginner move is not choosing one forever. It is learning what kind of help you need: explain, draft, edit, test, research, or operate across files.

Simple frame: ask whether you need a tutor, an editor assistant, or an agent that can move through a project.

ArcGIS is the GIS platform. The SDK is a code door into it.

ArcGIS Online, Experience Builder, Survey123, dashboards, feature layers, and web maps are platform tools. They help you make GIS products without starting from empty code.

The ArcGIS Maps SDK is what you use when you want custom web behavior around maps: specialized filters, custom workflows, app-specific controls, or map interactions that a no-code builder does not easily support.

Beginner rule: use Experience Builder when it already solves the workflow. Reach for the SDK when the map needs behavior the builder cannot express cleanly.

The full loop is the real lesson.

Most useful web apps are not one technology. They are a chain of responsibilities. Each part is simpler when it does its own job.

The point: learn coding faster by asking which layer owns the problem you are looking at.

Words that stop sounding mysterious.

Search a term, or scroll the list. The definitions stay plain on purpose. This is vocabulary for getting oriented, not documentation for experts.

The second pass can get more technical.

These ideas matter, but they should not interrupt the first beginner path. Keep them here until the foundation is comfortable.

Codex is a project workspace, not just a chat box.

Codex can read the project, edit files, run checks, open a browser, and keep useful rules close to the work.

This course is the operational companion to Coding 101. Coding 101 explains the ingredients. Codex 101 explains how an agent helps you work with them.

Codex works inside a real folder.

The practical difference from ordinary chat is that Codex can inspect the files, understand the project shape, make changes, and run commands to verify them.

Plain version: chat gives advice. A project agent can do the work in the project and show the evidence.

Memory keeps recurring rules near the work.

Project instructions, preferences, and durable patterns save you from explaining the same thing over and over. In this project, the left-rail teaching format is one of those preferences.

Plugins let Codex reach outside the folder.

A plugin or connector is a controlled bridge to another surface: browser, GitHub, Vercel, Google Drive, Gmail, Calendar, Supabase, or other systems.

The beginner idea is simple: use file access for local project work, and use connectors when the task depends on an external account, page, repo, deployment, or document.

A skill is a reusable workflow recipe.

When a workflow works well, it can become a skill. That means the next run starts from the procedure instead of from scratch.

Seeing the result changes the work.

For frontend work, the browser is not optional. Codex should open the page, click through it, check layout, inspect errors, and verify that the visible experience matches the intent.

Computer use extends that idea to desktop surfaces when the task depends on something outside the code editor.

Automations make a useful check recur.

An automation is for work that is valuable on a schedule: daily summaries, weekly checks, monitoring, reminders, recurring reports, or project housekeeping.

The best first automations are low risk and easy to inspect. They summarize, check, or prepare rather than silently changing important systems.

Chronicle gives work more context.

Chronicle is useful when the story of what happened across screens matters. It can help recover context from recent activity, screenshots, and workflow history.

Use it for orientation and continuity, not as a replacement for clear project files and explicit instructions.

Start with concrete tasks.

Codex makes the most sense when the request has a real folder, a visible target, or a clear output. These prompts are intentionally practical.

In my Downloads folder, find the receipts I need to process. Analyze them into an Excel workbook, categorize each transaction, and add charts that show spending patterns.

From now on, when I ask for a learning page and do not specify the format, use this left-rail guide layout with short sections, practical examples, and a table of contents.

Open the local app in the browser. Test the buttons, navigation, mobile layout, and the main success path. Fix any visible issues you find.

Three labs to try first.

Small enough to finish, real enough to show why Codex is different.

Deeper Codex topics belong in a second pass.

The first pass should stay practical. These topics are useful after the basic agent loop makes sense.

A plain-English prompt becomes a live ArcGIS map.

This tab uses the Lower 48 choropleth app as a concrete bridge between Coding 101 and real GIS work.

The important idea is not that the app is complicated. The important idea is that one prompt turned into a real web interface with controls, map layers, live services, and deployment.

Beginner frame: this is what coding looks like when HTML, CSS, JavaScript, APIs, ArcGIS, and deployment all show up in one small project.

The request described the user experience first.

The prompt did not start with library names or architecture. It started with what a person should be able to do: see the 48 states, choose variables, search, zoom, change basemaps, and click a state for a useful summary.

make me an app showing the 48 state and then allow me to select different variables and you color code the states choropleth style and also give me searchable drop down of states so when I select a state it zooms to the state and a hope button to return and a button to allow various base maps and some simple instrcutions and an email to jbf@jbf.com if questions and when a user clicks on a state give me a pop up with few facts and 30 word overview
add live NWS alerts and current IRWIN wildfires

Useful habit: describe the workflow in plain English before worrying about the code. The code should serve the workflow.

The working demo stays inside the lesson.

The embedded app keeps its own Prompt and Output tabs. Click Output inside the frame to use the map, change variables, search for a state, switch basemaps, and test the live overlays.

The demo is a stack of familiar parts.

Once you name each layer, the app becomes easier to understand. The browser shows the interface. JavaScript runs the map behavior. ArcGIS services provide spatial data. Vercel makes the result public.

ArcGIS is the map engine and data connector.

The demo uses the ArcGIS Maps SDK for JavaScript. That means the page is still ordinary HTML, CSS, and JavaScript, but the map behavior comes from ArcGIS classes built for layers, views, renderers, popups, and services.

This tab points to the current live source app.

For now, Coding 101 embeds the existing Vercel deployment instead of copying the full ArcGIS app code into this folder. That keeps this teaching site simple and avoids breaking the working map while we decide whether to fully merge the app later.

Deeper map topics belong after the first pass.

The intro should stay focused on what the app does. These topics are valuable once the visible workflow makes sense.