HTML in Templates and Frameworks

Prerequisites: Custom elements, Sanitizing user content

In real projects, HTML is rarely written as static files. It's generated by server-side templates or JavaScript frameworks — but what reaches the browser is still HTML, and everything in this course applies to it.

Server-side templates

{{-- Laravel Blade --}}
<ul>
  @foreach ($products as $product)
    <li><a href="{{ route('products.show', $product) }}">{{ $product->name }}</a></li>
  @endforeach
</ul>

Layouts and partials (components) keep the page skeleton, head, and navigation in one place.
Output is escaped by default; raw output needs a deliberate choice.
Look at the generated HTML (View Source) when checking validity and accessibility — template bugs like duplicate ids in loops only show up there.

JSX (React) and other framework syntaxes

function ProductList({ products }) {
  return (
    <ul>
      {products.map(p => (
        <li key={p.id}>
          <label htmlFor={`qty-${p.id}`}>{p.name}</label>
          <input id={`qty-${p.id}`} type="number" min={0} className="qty" />
        </li>
      ))}
    </ul>
  );
}

JSX looks like HTML but is JavaScript: className instead of class, htmlFor instead of for, camelCase event handlers, and every element must be closed (<input />). Vue and Svelte templates stay closer to real HTML.

Common framework pitfalls

Div soup — components that render nothing but divs. Components should output the right semantic element (<button>, <nav>, <li>).
Duplicate ids when a component is used twice — generate unique ones (React's useId()).
Click handlers on non-interactive elements — use a button.
Focus management on route changes — single-page apps don't reload the page, so move focus to the new page's heading and update the title.
Hydration mismatches — server-rendered HTML that the parser repairs (say, a div inside a p) differs from what the framework expects, causing errors. Valid HTML avoids them.

Rendering strategies

Strategy	HTML is produced	Good for
Static generation	At build time	Docs, blogs, marketing sites
Server-side rendering	Per request	Personalized or frequently changing pages
Client-side rendering	In the browser by JavaScript	App-like interfaces behind a login
Islands / partial hydration	On the server, with small interactive parts enhanced	Content sites with some interactivity

Server-produced HTML is fastest to show and most robust; the more you rely on client-side rendering, the more you need to manage loading states, focus, and SEO yourself.

The takeaway

Frameworks change how you write HTML, not what good HTML is. Check the output with the validator and accessibility tools, and choose elements for their meaning — the same skills from Level 1.

What's next

Try the Advanced Projects, then read What You Should Know Now — and What's Next for where to go from here.