Back to learning
Web development

From the first request to a deployed application

Start with a page served from your own machine. Finish with a React application other people can use, reviewed and deployed.

  • Beginner
  • About 20 weeks
  • 12 milestones
  • 36 steps
  • 28 reviewed
JavaScriptReactGitREST APIHTML/CSS
Start this journey
What you will have builtA deployed React application — Nearby, a community events board — that loads from a real API, survives a failing network, and was shipped through a reviewed pull request.Start this journey

What this asks of you

Every figure below is read from the journey itself, not written about it.

BeginnerNo prior experience needed
About 20 weeksAn estimate, not a deadline
12 milestonesEach one claims a capability
36 stepsShort, and every one is built
28 reviewedAn engineer reads these, when mentor guided

What you will be able to do

Every milestone claims one engineering capability. You reach it by building something, not by finishing a chapter.

The webWatch what actually happens between a request and a page, and change the response yourselfEverything else in the journey is a request and a response. A beginner who has never seen one debugs by guessing.
3 steps
Show the 3 steps
  • Serve a page from your own machine

    Run an HTTP server and open your page over http:// rather than by double-clicking the file.

  • Tell a real 404 from a page that says not found

    Fetch your page from the command line and read the status line and headers yourself.

  • Account for every request a page makesReviewed

    Account for every request a real page makes, and name the one that costs the most.

HTMLGive a document a structure a browser, a screen reader and another engineer can all followStructure decided now is inherited by every stylesheet, every component and every accessibility fix later.
3 steps
Show the 3 steps
  • Give the board a document structureReviewed

    Express the events board as a document, using the element that means what you mean.

  • Build the form people will actually useReviewed

    Add a form that submits a new event, using native input types and native validation.

  • Make it usable without a mouse or a screen

    Take the page through an accessibility check and fix what it finds.

CSSLay out a page that holds together on a phone, on a laptop and under a keyboardLayout is where beginners lose weeks to guessing. Deciding the model once ends that.
3 steps
Show the 3 steps
  • Lay the page out deliberately

    Lay out the board with a chosen layout model and a spacing scale instead of trial and error.

  • Make it work on a phone firstReviewed

    Make the board usable at 320px wide, then let it grow into a larger screen.

  • Make every interactive thing visible to a keyboard

    Give focus, hover and disabled states that a keyboard user can rely on.

JavaScriptTurn a static page into one that responds, with the logic separate from the screenSeparating what is true from what is displayed is the idea React later automates. Meet it first without React.
3 steps
Show the 3 steps
  • Put the events in data, not in markupReviewed

    Render the event list from an array so the markup holds no event of its own.

  • Write the rules as functions you can run without a browserReviewed

    Move the event rules into pure functions and run them from the command line.

  • Let the page respond to a personReviewed

    Wire the form so that submitting it changes the data, and the page follows.

Modern JavaScriptWork with code split into modules and with data that has not arrived yetThe network is the first thing that takes time. Everything about React data loading is a consequence of that.
3 steps
Show the 3 steps
  • Split one growing file into modules that can move

    Break one script into modules that each have one job, and import them.

  • Render a page whose data has not arrived yetReviewed

    Use a promise and await to handle work that finishes later without freezing the page.

  • Fetch the events over the networkReviewed

    Replace the local array with a real request, and render every state it can be in.

ComponentsRebuild an existing interface as components and say what each one ownsThe argument for React only lands on someone who is deleting DOM code they wrote themselves.
3 steps
Show the 3 steps
  • Stand the same page up in React

    Create a React project and render the existing board from a single component.

  • Give every part of the page an ownerReviewed

    Split the single component into components named for what they are, passing data as props.

  • Render the list from data, and delete the DOM codeReviewed

    Render the events with map, and remove the hand-written DOM building entirely.

React fundamentalsHold state where it belongs and let the screen follow it, everywhereWhere a value lives decides what can change it — the question every React bug eventually reduces to.
3 steps
Show the 3 steps
  • Give the board stateReviewed

    Hold the event list in state so that adding one re-renders the page.

  • Decide who owns each valueReviewed

    Give every piece of state exactly one owner, and pass the rest down.

  • Make the form refuse bad dataReviewed

    Turn the form into controlled inputs that reject an invalid event before it reaches the list.

An application, not a pageBuild several screens people can navigate, return to and send to someone elseOne screen is a demo. The moment there are two, addresses, state and shared components all become real problems.
3 steps
Show the 3 steps
  • Give every screen an addressReviewed

    Add routing so the list, one event and the new-event form each have their own URL.

  • Render every state a screen can be inReviewed

    Give each screen a loading, empty, error and content state that are visibly different.

  • Reuse instead of repeatingReviewed

    Extract the components that now exist three times, without inventing ones that do not.

A real APIPut the application on a real API and keep it honest when the network failsEverything before this could be reloaded to fix. From here the truth lives somewhere else.
3 steps
Show the 3 steps
  • Read the events from the APIReviewed

    Replace the local data with the API, keeping all four states intact.

  • Create an event through the APIReviewed

    Send a new event to the server and handle both answers it can give.

  • Say who you are on every requestReviewed

    Send credentials with each request and handle being refused.

The other side of the requestRead a backend well enough to tell whether a bug is yours or theirsYou will not write the API here. You will stop being unable to look at it, which is what makes you a useful person to hand a bug to.
3 steps
Show the 3 steps
  • Get the API running on your own machine

    Start the API on your own machine and point the application at it.

  • Trace one request from the URL to the rowReviewed

    Follow a single request through the route, the handler and the query to the data behind it.

  • Watch the server decide who you areReviewed

    Follow one authenticated request and state what the server checks before it answers.

DeliveryDeliver a change the way a team does — a branch, a pull request, a review and a deployEverything so far was written for you to read. This is where it becomes work other people can accept.
3 steps
Show the 3 steps
  • Work on a branch, in commits that tell the storyReviewed

    Build one small feature on a branch, committing in steps a reader can follow.

  • Open a pull request and answer the reviewReviewed

    Put the branch up for review with a description, and respond to what comes back.

  • Deploy it where other people can reach itReviewed

    Put the application on the internet and confirm it works there, not only locally.

Something nobody specified for youTake a requirement you have not seen before and ship it end to endEvery step so far told you what to build. The capability being claimed is the one that works when nothing does.
3 steps
Show the 3 steps
  • Turn one sentence into a plan you can buildReviewed

    Take an unfamiliar requirement and break it into slices that each leave the application working.

  • Build it to the standard you now holdReviewed

    Implement the feature with the states, accessibility and failure handling you have been building all journey.

  • Ship it, and leave it runnable by a strangerReviewed

    Take the feature through review and deployment, and write the README that lets someone else run it.

How the work is verified

  1. ReadThe context you need for this step, and why it matters. Never more than that.
  2. BuildYou produce something real. The work is yours, in your own repository.
  3. SubmitYou send it, with a note on what you chose and what you were unsure about.
  4. ReviewA senior engineer reads it and responds. They may ask for changes — that is the normal path through engineering review, not a failure.
  5. VerifiedThe capability is confirmed, it goes on your record, and the next step opens.

How you want to work

You choose when you start. Both cover the same journey and the same definition of done.

Mentor guidedReviewed by a person

A senior engineer is assigned to you. They read every submission, respond in writing, and decide when a capability is verified. Expect to be asked for changes.

Self pacedVerified by you

You work through the same journey and verify your own work against the same definition of done. Nothing is submitted to anyone, and nothing waits on anyone.

What you end up with

Counted from this journey, not described in general.

A deployed React application — Nearby, a community events board — that loads from a real API, survives a failing network, and was shipped through a reviewed pull request.Built by you, in your own repository.
28 pieces of work, each read by an engineerEvery round and every comment stays on the record, including what changed between them.
12 verified capabilitiesEach one confirmed against its definition of done, with the name of whoever confirmed it. There is no certificate. The work is the credential.

Ready to start From the first request to a deployed application?

You will choose how you want to work on the next screen. Nothing starts until you confirm it. You can run several journeys at once, and each one is mentor-guided or self-paced on its own.

Start this journey