Unit 01 · lesson

A Website Is Files Before It Is a Screen

Open a polished website and your brain wants to start with the screen.

That is the trap.

Before a browser draws a heading, card, image, navigation bar, or button, somebody had to create source that eventually became files the browser could understand.

Jekyll makes that relationship unusually visible because there is no database hiding the content model from you. Your site begins as files and folders.

Start with the smallest possible site

Create a folder:

my-portfolio/

Inside it, create index.html:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>My Portfolio</title>
  </head>
  <body>
    <h1>Your Name</h1>
    <p>Student developer, builder, and problem solver.</p>
  </body>
</html>

Read the file before changing it.

<html> contains the document.
<head> contains metadata and resources.
<body> contains the visible document content.
<h1> establishes the primary heading.
<p> creates a paragraph.

This is plain HTML. Jekyll has not done anything yet.

That distinction matters.

Debug a small HTML source file

Before you build a full portfolio, prove you can read and repair a small source file.

Fix the fake HTML tags so the profile card uses real semantic elements.
Keep the visible text, but make the structure testable.
Run the checks, then compare the preview with the DOM evidence.

<main>
  <h1>Nova Robotics</h1>
  <heading2>About</heading2>
  <pp>Nova builds small classroom robots.</pp>
  <heading2>Focus</heading2>
  <pp>We test code before driving hardware.</pp>
</main>

Preview

Checksnot run yet

CHECK · The page has exactly one h1.waiting for check
CHECK · The fake heading2 tags became two h2 elements.waiting for check
CHECK · The fake pp tags became two paragraph elements.waiting for check
CHECK · The first h2 says About.waiting for check

Hints

Browsers do not treat <heading2> as the same thing as <h2>.
Paragraph text belongs inside <p> and </p>.

The lab runs entirely in your browser. It does not save progress, create an account, grade you, or execute code on a server. The point is evidence: can the source use real HTML elements that the browser and tests can inspect?

The first mental model

Jekyll is a static site generator. You author source files. Jekyll processes those files and produces a static website.

SOURCE FILES
      ↓
JEKYLL
      ↓
GENERATED STATIC FILES
      ↓
WEB SERVER
      ↓
BROWSER

After Jekyll has built the final files, the browser does not need Jekyll to render them. The browser receives HTML, CSS, JavaScript, images, and other static assets.

That is one reason static sites can be simple to deploy: the expensive authoring/build logic happens before the browser request.

What Jekyll is not

Do not leave this lesson thinking:

Jekyll is a website editor.

Nope.

Your editor edits source.

Jekyll transforms source.

A server delivers output.

A browser renders output.

Four different jobs.

Inspect the boundary

Look at the HTML above and answer:

Which parts are source?
Which program will eventually transform or copy that source?
Which program will display the final HTML?
If the browser displays old content, what are at least three possible layers that could be responsible?

A useful answer to #4 might include:

the source was not saved;
Jekyll did not rebuild;
the browser is showing an older response.

Notice how much better that is than:

The website is broken.

Build your first identity boundary

Replace the sample name and description with information you are comfortable publishing publicly.

Do not put any of these into a public portfolio:

passwords or API keys;
home address;
personal phone number unless you have a deliberate public-contact reason;
private school records;
private account-recovery information;
other people's identifying information without permission.

A portfolio is public evidence of your work. It does not need to become a dump of your private life.

Evidence checkpoint

Save:

your first index.html;
a screenshot or copy of the project tree;
a one-sentence explanation of source;
a one-sentence explanation of generated output; and
your first source → Jekyll → server → browser sketch.

You are ready to continue when you can explain why the HTML file is not the same thing as the browser screen.

Vocabulary lab

Flip the idea, not just the card

Explain the term before you reveal the back. Then compare your explanation with the definition, example, and warning.

Read all terms without animation

Source: Files a developer or author edits before the site is built. Example: index.html in the project root is source. Do not confuse it with: The final browser screen or generated _site output.
Static Site Generator: Software that transforms source content and templates into static web files before they are served. Example: Jekyll builds source files into a generated site. Do not confuse it with: A browser or visual page editor.
Generated Output: Files produced by the build process for serving or deployment. Example: Jekyll normally writes built files into _site. Do not confuse it with: The source files you should normally edit.
Browser: Software that requests and renders web resources for the user. Example: Firefox renders the HTML produced by a Jekyll build. Do not confuse it with: The program that runs the Jekyll build.