DEV Community: Marian

What Is Semantic HTML and Why Does It Matter?

Marian — Sat, 07 Mar 2026 00:00:00 +0000

Early in my career I wrote a lot of <div> soup. Everything was a div. The header was a div. The nav was a div. The sidebar was a div with a class called sidebar-right-wrapper because apparently I needed two words to describe something that could have just been an <aside>.

It worked. Browsers are incredibly forgiving. But a senior dev on one of my first real projects pulled up my markup in a code review and said something that stuck with me: "Would a screen reader have any idea what's going on here?"

I didn't have a good answer. That's when I actually learned semantic HTML — not the definition, but why it matters in practice.

Why it's more than just "best practice"

When people say semantic HTML is a best practice, it sounds like one of those things you're supposed to do but nobody actually enforces. In reality there are three concrete reasons it affects real users and real outcomes.

Accessibility. Screen readers navigate by semantic landmarks. A <nav> element lets a blind user jump straight to navigation. A proper heading hierarchy lets them scan the document outline the same way a sighted user skims visually. Without those landmarks, the page is just one long wall of text read top to bottom.

The WebAIM Million report audits the top million websites every year. Every year, over 95% of home pages have detectable accessibility failures, and missing or incorrect semantic structure is always near the top. That's not a niche edge case — that's most of the web failing a basic test.

SEO. I'm always cautious about SEO claims because a lot of them are snake oil. This one isn't. Search crawlers parse your HTML to understand what a page is about. A <main> element tells Google where the actual content starts. <article> signals a standalone piece worth indexing independently. Heading tags communicate hierarchy and topic structure. None of this is magic, but it removes ambiguity for crawlers — and less ambiguity generally means better indexing.

Maintainability. Honestly, this is the one I care about most day to day. <header> is just faster to read than <div class="page-header-outer-wrapper">. When I open a codebase I haven't touched in a year, semantic structure tells me what's going on without me having to trace CSS class names back to some stylesheet. Future-me always appreciates past-me using the right tags.

The tags I actually use regularly

I'm not going to list every HTML5 semantic element — MDN does that better than I ever could. These are the ones that come up in almost every project.

`<header>`

Not just for the top of the page. A <header> inside an <article> is completely valid — it's the introductory part of that article, not the site header. I use it for both.

<header>
  <nav>...</nav>
  <h1>Dudych Blog</h1>
</header>

The mistake I see most often: people treat <header> as a singleton, like there can only be one per page. There can be multiple. Each semantic section can have its own.

`<main>`

One per page. Just one. It wraps the primary content — the stuff that's unique to this page and not repeated elsewhere. Your site-wide nav doesn't go in here. Your newsletter form that appears on every page doesn't go in here.

<main>
  <article>
    <!-- the actual post -->
  </article>
</main>

This is also useful for accessibility — screen readers have a "jump to main content" shortcut that relies on this element existing.

`<article>` vs `<section>` — the one that trips everyone up

These two cause more confusion than anything else. The distinction I use:

Can you lift this content out, drop it on a completely different site, and have it still make sense? If yes, it's an <article>. Blog posts, news articles, product cards, comments — all articles.

If no — if it's a thematic chunk of this page that doesn't stand on its own — it's a <section>.

If you can't even give it a meaningful name, it's a <div>.

Question	Tag
Makes sense on another site entirely?	`<article>`
Named section that belongs to this page?	`<section>`
Just a layout container with no semantic meaning?	`<div>`

<!-- A blog post listing -->
<article>
  <h2>What Is Semantic HTML?</h2>
  <p><time datetime="2026-03-07">March 7, 2026</time></p>
  <p>Content...</p>
</article>

<!-- A section within a longer article -->
<section>
  <h2>Why It Matters</h2>
  <p>...</p>
</section>

`<aside>`

Tangentially related content. Sidebars, pull quotes, author bios, related posts. The key word is tangentially — if the content is important to understanding the main article, it probably shouldn't be an <aside>.

`<nav>`

Navigation links. Not all link groups — just the ones that constitute actual navigation. The main menu, yes. Breadcrumbs, yes. The three links in the footer (home, privacy policy, copyright)? Probably not worth wrapping in <nav>.

If you have multiple <nav> elements on a page, add aria-label to distinguish them:

<nav aria-label="Main navigation">...</nav>
<nav aria-label="Post pagination">...</nav>

`<time>` — the underrated one

Nobody talks about this tag enough. Every date on your site should be in a <time> element:

<time datetime="2026-03-07T08:00:00Z">March 7, 2026</time>

The datetime attribute gives machines an unambiguous timestamp. The text content stays human-readable in whatever format you want. Search engines use this for rich results. Screen readers use it to announce dates correctly. Takes five seconds to add. Worth it every time.

What a properly structured page looks like

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>What Is Semantic HTML? | Dudych Blog</title>
  </head>
  <body>

    <header>
      <nav aria-label="Main navigation">
        <a href="/">Home</a>
        <a href="/blog">Blog</a>
        <a href="/about">About</a>
      </nav>
    </header>

    <main>
      <article>

        <header>
          <h1>What Is Semantic HTML and Why Does It Matter?</h1>
          <p>
            By Marian Dudych ·
            <time datetime="2026-03-07">March 7, 2026</time>
          </p>
        </header>

        <section>
          <h2>Why It Matters</h2>
          <p>...</p>
        </section>

        <section>
          <h2>The Tags You Should Know</h2>
          <p>...</p>
        </section>

        <footer>
          <p>Filed under: HTML, Accessibility</p>
        </footer>

      </article>

      <aside>
        <h2>Related Posts</h2>
        <ul>...</ul>
      </aside>
    </main>

    <footer>
      <p>© 2026 Dudych Blog</p>
    </footer>

  </body>
</html>

Notice the <header> and <footer> nested inside <article>. Completely valid. The article header contains the title and byline. The article footer contains tags and metadata. It reads exactly like what it is.

The thing I see wrong most often

Using semantic tags for their visual side effects rather than their meaning.

<blockquote> to indent arbitrary text. <ul> to shift content left. <h3> because "that's about the right font size." I've done all of these. They're wrong.

The browser's default rendering of semantic elements is a side effect, not the point. CSS handles visuals. HTML handles meaning. The moment you pick a tag based on how it looks in a browser without styles, you've introduced a bug — it's just a bug that doesn't throw an error.

A test I find useful: disable all CSS on the page. Does the document still communicate its structure clearly? Can you tell what's a heading, what's navigation, what's the main content? If yes, you're in good shape.

A checklist before I ship

I don't always run through this explicitly, but it's what I'm checking for:

One <main> per page, contains only page-specific content
Heading hierarchy is sequential — no jumping from <h1> to <h3>
Dates are in <time> elements with datetime attributes
Standalone content is in <article>, thematic sections in <section>
Multiple <nav> elements have aria-label attributes
No tag chosen for its visual appearance rather than its meaning

Worth learning properly

This is one of those fundamentals that has an outsized return on investment. A few hours spent actually understanding the element spec pays off every time you write markup — better accessibility, better SEO, cleaner code.

The MDN HTML elements reference is where I go when I'm not sure about a specific element. The HTML Living Standard is more exhaustive if you want the full picture.

Start with <main>, <article>, <section>, and <nav>. Get those right consistently and you're already ahead of most of the web.

Originally posted here: https://dudych.com/blog/what-is-semantic-html-and-why-does-it-matter

Is Your Email Already Compromised? How to Check in 30 Seconds

Marian — Thu, 05 Mar 2026 00:00:00 +0000

Most people find out their email was hacked the hard way — a suspicious login, a friend asking why you sent them a weird link, or a bank notification at 2am. But there's a good chance your credentials are already floating around on some hacker forum right now, and you have no idea.

Here's how to check in under a minute.

The Tool: Have I Been Pwned

haveibeenpwned.com is a free service built by security researcher Troy Hunt. It maintains a massive database of email addresses and passwords that have been exposed in known data breaches — the kind that get dumped on hacker forums in batches of hundreds of thousands.

The logic is simple: when a company gets breached, the stolen data almost always ends up publicly posted somewhere. Troy's team collects those dumps and indexes them so you can check if your email is in there.

How to Check

Go to haveibeenpwned.com
Enter your email address
Hit pwned?

You'll get one of two results:

🔴 Bad news — your email shows up in one or more breaches. The site tells you exactly which ones (LinkedIn, Adobe, Dropbox, etc.) and what data was exposed (passwords, usernames, phone numbers).

🟢 Good news — "Good news — no pwnage found!" Your email isn't in their database.

Don't Celebrate Too Early

Here's the thing — a clean result doesn't mean you're safe. It just means your email hasn't shown up in a known, public breach yet. There are plenty of breaches that never get published, credentials sold privately on the dark web, or leaks that haven't been indexed yet.

You might already be compromised and just not know it.

What to Do If You're Pwned

If your email shows up, don't panic — but do act fast:

Change your password immediately on the breached service
Change it everywhere else where you used the same password (yes, all of them)
Enable 2FA on your email and any important accounts
Use a password manager — Bitwarden is free and open source (My Choice)

The real danger isn't the breached site itself — it's credential stuffing. Hackers take your leaked email + password combo and automatically try it on hundreds of other sites (Gmail, Facebook, your bank). If you reuse passwords, one breach becomes every breach.

The Uncomfortable Truth About Passwords

If you're using the same password on more than one site, you're not securing your accounts — you're just hoping the weakest site in your list never gets breached.

Spoiler: it will.

Check your email now. It takes 30 seconds, and you might be very glad you did.

Originally posted here: https://dudych.com/blog/is-your-email-already-compromised-how-to-check-in-30-seconds

NPM vs Yarn vs pnpm vs Bun: Which Package Manager Should You Use in 2026?

Marian — Wed, 04 Mar 2026 00:00:00 +0000

Every JavaScript project starts the same way: you need to install dependencies. But in 2026, you have four serious options — and the choice matters more than most people admit.

I've shipped projects with all four. Here's my honest breakdown so you can pick one and stop second-guessing yourself.

The Quick Answer

If you just want a recommendation:

🆕 Starting a new project? → pnpm or Bun
🏢 Working on an existing codebase? → Stick with whatever it already uses
🗂️ In a large monorepo? → pnpm — nothing else comes close
⚡ Want the absolute fastest installs? → Bun
🤷 Don't want to think about it? → npm is fine, really

npm — The One That Ships with Node

npm comes pre-installed with Node.js, which is both its biggest strength and the reason people take it for granted. It's everywhere — every tutorial, every CI pipeline, every Dockerfile you've ever copy-pasted.

npm install
npm run dev
npm install lodash

The problem? npm was notoriously slow for years, and it still writes a flat node_modules folder that grows to terrifying sizes. The node_modules meme exists because of npm.

💡 It's gotten much better since v7 (workspaces) and v9 (performance improvements), but it's still the slowest of the four when you benchmark a cold install.

Who should use it: Beginners, solo projects, or situations where you genuinely can't add tooling. Otherwise, there are better options.

Yarn — The Veteran Challenger

Yarn was created by Facebook in 2016 specifically to fix npm's problems — mainly speed and reliability. It introduced yarn.lock, parallel installs, and a notably nicer CLI.

yarn install
yarn dev
yarn add lodash

Yarn Classic (v1) is still widely used and battle-tested — you'll find it in countless large open source projects. Yarn Berry (v2+) is a complete rewrite with a radical feature called Plug'n'Play (PnP) — it eliminates node_modules entirely and resolves dependencies from a single .pnp.cjs file.

I tried Yarn Berry on a project in 2022. The speed was impressive. The compatibility headaches with tools that assume node_modules exists were... less impressive. Your mileage may vary.

Who should use it: Teams already using it, or developers who want to experiment with PnP on a greenfield project with modern tooling.

pnpm — My Daily Driver

pnpm is what npm should have been from the start. Instead of copying packages into every project's node_modules, pnpm stores everything in a global content-addressable store and uses hard links. Install lodash in 10 projects — it only exists on disk once.

pnpm install
pnpm dev
pnpm add lodash

The structure looks like this:

my-project/
  node_modules/
    .pnpm/ ← actual packages, stored as hard links
    lodash → .pnpm/lodash@4.17.21/node_modules/lodash

The results are real. On my MacBook, switching a large project from npm to pnpm cut install time by ~60% and freed up several gigabytes of disk space. If you've ever run npx npkill and been horrified by how much space node_modules was eating — pnpm solves that problem permanently.

It also enforces strict dependency isolation — you can't accidentally use a package you didn't explicitly declare. This has already caught implicit dependency bugs on two of my projects that would have caused subtle production issues.

🏆 This blog is built with pnpm. I switched from npm about two years ago and haven't looked back.

Who should use it: Anyone starting a new project, monorepo teams, and developers who are serious about disk efficiency and dependency correctness.

Bun — The Exciting New Arrival

Bun isn't just a package manager — it's an entire JavaScript runtime (like Node.js), bundler, test runner, and package manager in one. Written in Zig, it's engineered from the ground up for raw speed.

bun install
bun dev
bun add lodash

The first time I ran bun install on a large Next.js project, I genuinely thought something had gone wrong. It finished before the terminal had even scrolled. Installs that take 30+ seconds with npm can take under 3 seconds with Bun.

It has its own lockfile (bun.lockb) and is mostly compatible with the npm registry and existing package.json files. The trade-off is maturity — edge cases and occasional compatibility issues still surface, especially with packages that rely on native Node.js internals.

🚀 Bun is moving incredibly fast. Check the Bun changelog — major improvements ship almost every month.

Who should use it: New projects where you want maximum speed and don't mind the occasional rough edge. Increasingly safe for production in 2026.

Head-to-Head Comparison

	npm	Yarn	pnpm	Bun
Install speed	🐢 Slow	🚶 Medium	🏃 Fast	⚡ Fastest
Disk usage	High	High	Low	Low
node_modules	Flat	Flat / PnP	Linked	Flat
Monorepo support	Basic	Good	Excellent	Good
Lockfile	package-lock.json	yarn.lock	pnpm-lock.yaml	bun.lockb
Maturity	Very mature	Mature	Mature	Newer
Standalone runtime	No	No	No	Yes

The node_modules Problem, Visualised

All four managers (except Yarn Berry with PnP) create a node_modules folder. The difference is how:

npm / Yarn Classic — copies everything. 10 projects means 10 full copies of React on your disk
pnpm — hard links from a global store. 10 projects, 1 copy of React
Bun — similar global cache approach, comparably disk-efficient

If you've ever cleaned up old projects with npx npkill and freed 20GB in one go — pnpm prevents that accumulation from happening in the first place.

What I Actually Use

This blog uses pnpm. It's fast, saves disk space, and the strict dependency isolation has already prevented real bugs.

If I were starting fresh today with no constraints, I'd take a hard look at Bun — the speed is difficult to argue against, and the ecosystem compatibility story gets better with every release.

The Honest Bottom Line

Don't lose sleep over this. The best package manager is the one your team already uses consistently. Mixing package managers in one project — some devs on npm, others on Yarn — causes far more pain than any performance gap between them.

That said, if you have the freedom to choose:

Pragmatic pick → pnpm
Exciting pick → Bun
Safe default → npm

Pick one. Commit to it. Then focus on actually building things.

Originally posted here: https://dudych.com/blog/npm-vs-yarn-vs-pnpm-vs-bun-which-package-manager-should-you-use-in-2026