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

How I Transformed VS Code Into a Cozy, Minimalist Workspace (Full Setup Guide)

Marian — Fri, 06 Mar 2026 00:00:00 +0000

If you've ever opened VS Code and felt like you were staring at the cockpit of a spaceship - activity bars, status bars, breadcrumbs, line numbers, a minimap, sidebars - you're not alone. Out of the box, VS Code is powerful, but it can also feel really cluttered, especially when all you want to do is sit down and write some code.

I've been tweaking my setup for a while now, and I finally landed on something that feels genuinely calm and focused. No unnecessary noise. Just the code, a nice font, and (okay, a little pet running around in the sidebar). In this post, I'm going to walk you through my exact setup - step by step - so you can recreate it yourself, even if you're fairly new to VS Code.

By the end of this guide, you'll have:

A clean, distraction-free editor layout
A beautiful minimal theme and icon pack
A set of must-have extensions
My full settings.json you can copy and paste in 30 seconds

Let's get into it.

What We're Starting With (And Where We're Going)

Here's the thing: the default VS Code UI isn't bad, it's just designed to show everything at once. For beginners, that's actually helpful - you can see all the buttons and options. But once you know where things are, a lot of that UI becomes visual noise.

The transformation is pretty dramatic. And the best part? You're not removing functionality. Everything is still there. You're just hiding what you don't need on a day-to-day basis, so you can focus on what actually matters.

Step 1: Open Your settings.json File

Everything in this guide lives in a single file called settings.json. This is VS Code's main config file, and editing it is the fastest way to customize your entire editor.

Here's how to open it:

On Mac:

Press Cmd + Shift + P to open the Command Palette
Type Open User Settings (JSON)
Click the result - it looks like Preferences: Open User Settings (JSON)

On Windows/Linux:

Press Ctrl + Shift + P to open the Command Palette
Type Open User Settings (JSON)
Click the result

You'll see a file that looks something like this:

{
  "editor.fontSize": 14,
  "workbench.colorTheme": "Default Dark+"
}

This is where all your configuration lives. Throughout this guide, I'll be showing you settings to add or update here. At the very bottom of the post, you'll find my complete settings.json that you can copy and paste all at once if you prefer.

Step 2: Install a Beautiful Font

One of the biggest upgrades you can make to your coding experience is switching to a better monospace font. The default VS Code font is fine, but it's not inspiring.

Option A: Brass Mono (My Pick)

Brass Mono is the font I currently use. It's clean, well-spaced, and has a slightly warm, organic feel to it - very different from the cold, technical look of most coding fonts. It makes long coding sessions way more comfortable.

Download it here: github.com/fonsecapeter/brass_mono

Option B: Fira Code (Great if You Want Ligatures)

If you want font ligatures - where symbols like =>, !==, and -> merge into a single, cleaner glyph - then Fira Code is an excellent choice. It's one of the most popular coding fonts in the world for a reason.

Download it here: github.com/tonsky/FiraCode

How to Install a Font

Once you've downloaded your chosen font:

Unzip the downloaded file
Open the font file (usually a .ttf or .otf file)
Click Install (Mac will show a Font Book preview; Windows shows an Install button)
Restart VS Code so it picks up the new font

Then add this to your settings.json:

"editor.fontFamily": "Brass Mono, monospace",
"editor.fontSize": 14,
"editor.lineHeight": 1.6,
"editor.letterSpacing": 0.3

💡 Tip: The lineHeight: 1.6 setting is underrated. It adds a little breathing room between lines of code, which makes it much easier to read at a glance.

Step 3: Install a Minimal Theme

The theme controls the colors of everything - your syntax highlighting, background, sidebar, and more. I use Min Theme , which is exactly what it sounds like: minimal, clean, and available in both dark and light variants.

Installing Min Theme

Open the Extensions panel with Cmd/Ctrl + Shift + X
Search for Min Theme
Click Install
Press Cmd/Ctrl + K, then Cmd/Ctrl + T to open the theme picker
Select Min Dark or Min Light

Or add this to your settings.json:

"workbench.colorTheme": "Min Dark"

That said - theme is 100% personal preference. If you have one you love already, keep it! The rest of this guide will still apply.

Step 4: Install a Minimal Icon Pack

The file icons in VS Code's sidebar make it easier to tell files apart at a glance. The default icons are okay, but Symbols is a much cleaner option - simple, monochrome shapes that don't fight for attention.

Installing Symbols

Open Extensions: Cmd/Ctrl + Shift + X
Search for Symbols (by Miguel Solorio)
Click Install

Then add to settings.json:

"workbench.iconTheme": "symbols"

Step 5: Clean Up the UI Layout

This is the core of the minimalist transformation. We're going to hide a bunch of UI chrome that you probably haven't thought about much, but that's quietly adding clutter to your editor every single day.

Here's what we're hiding and why:

Hide the Status Bar

The status bar at the bottom shows things like your current branch, language mode, and encoding. Useful sometimes - but you can get all that information on demand anyway.

"workbench.statusBar.visible": false

Move the Activity Bar to the Top

By default the activity bar (with icons for Explorer, Search, Git, Extensions, etc.) sits on the left side and takes up a vertical column of space. Moving it to the top frees up horizontal space for your code.

"workbench.activityBar.location": "top"

Disable the Command Center

VS Code added a big search bar in the title bar called the Command Center. If you use Cmd/Ctrl + Shift + P to run commands (which you should), you don't need this.

"window.commandCenter": false

Turn Off Breadcrumbs

Breadcrumbs show you the file path and symbol hierarchy at the top of the editor. Handy for navigating large codebases, but just noise for most day-to-day work.

"breadcrumbs.enabled": false

Disable the Minimap

The minimap is that tiny birds-eye view of your code on the right side of the editor. It looks cool, but in practice almost nobody uses it for navigation once they know keyboard shortcuts.

"editor.minimap.enabled": false

Hide Line Numbers

This one's controversial - I know! But hear me out. Once you're comfortable with VS Code, you rarely actually need to see line numbers. Removing them gives the editor a much cleaner, document-like feel. Error messages still tell you the line number; you can jump to any line with Ctrl + G.

"editor.lineNumbers": "off"

💡 Not ready to go lineless? Try "editor.lineNumbers": "relative" instead - it shows numbers relative to your cursor position, which is super useful if you use Vim motions.

Remove Indentation Guides

Those faint vertical lines that show indentation levels? Gone.

"editor.guides.indentation": false

Remove Code Folding Arrows

Those little arrows in the gutter that let you collapse blocks of code. If you don't use them, they're just visual clutter.

"editor.folding": false

Step 6: Set Up the Terminal to Match

If you use the integrated terminal (and you should - it's really handy), make sure it matches your editor's font so everything looks consistent.

"terminal.integrated.fontFamily": "Brass Mono, monospace",
"terminal.integrated.fontSize": 14,
"terminal.integrated.lineHeight": 1.6

Step 7: Configure Your Code Formatting

Good formatting settings mean you spend less time thinking about whitespace and more time thinking about code. I use Prettier for automatic formatting.

Install Prettier

Open Extensions: Cmd/Ctrl + Shift + X
Search for Prettier - Code formatter
Click Install

Then add these settings:

"editor.defaultFormatter": "esbenp.prettier-vscode",
"prettier.tabWidth": 2,
"prettier.useTabs": false,
"editor.formatOnSave": false,
"editor.tabSize": 2,
"files.trimTrailingWhitespace": true,
"files.insertFinalNewline": true,
"files.trimFinalNewlines": true

💡 Note on formatOnSave: I keep this set to false because I prefer to format manually when I'm ready. If you want your code auto-formatted every time you save (which a lot of people prefer!), change this to true.

Suppress Tailwind CSS Warnings

If you use Tailwind CSS, you'll get annoying "Unknown at-rule" warnings for things like @tailwind and @apply. Silence them with:

"css.lint.unknownAtRules": "ignore",
"scss.lint.unknownAtRules": "ignore",
"less.lint.unknownAtRules": "ignore"

Step 8: Improve Navigation Behavior

These small tweaks make navigating your codebase feel snappier and less interrupting.

"editor.gotoLocation.multipleReferences": "goto",
"editor.gotoLocation.multipleDefinitions": "goto",
"editor.gotoLocation.multipleDeclarations": "goto",
"editor.gotoLocation.multipleImplementations": "goto",
"editor.gotoLocation.multipleTypeDefinitions": "goto",
"workbench.editor.enablePreviewFromQuickOpen": false

The goto settings mean that when you press F12 to go to a definition, VS Code jumps straight there instead of showing you a picker - much less friction. The enablePreviewFromQuickOpen: false setting stops VS Code from opening files in "preview mode" (that italic tab title) when you open them with Ctrl/Cmd + P.

Step 9: Install Must-Have Extensions

These are the extensions I consider essential for a great development experience. Most of them work quietly in the background and just make things better without getting in the way.

For Code Quality

Extension	What it does
Error Lens	Shows errors and warnings inline next to your code, instead of making you hover over the red squiggles
SonarQube for IDE	Catches bugs, code smells, and security vulnerabilities as you type
Code Spell Checker	Catches typos in your code and comments (more useful than you'd think!)
Pretty TypeScript Errors	Makes TypeScript error messages actually readable

For Workflow

Extension	What it does
GitLens	Supercharges the built-in Git integration - shows who wrote each line, rich history, and much more
Prettier - Code formatter	Automatic, opinionated code formatting
Auto Rename Tag	Automatically renames the closing HTML/JSX tag when you rename the opening one
Import Cost	Shows the file size of imported packages inline - great for keeping bundle sizes down

For Specific Tech

Extension	What it does
Tailwind CSS IntelliSense	Autocomplete, linting, and hover previews for Tailwind classes
Image Preview	Shows a thumbnail of image files in the gutter and on hover

For Fun 🐾

vscode-pets - This one doesn't make you more productive at all. It adds a little pet (cat, dog, snake, and more) that runs around in a panel while you work. You can set the background theme, pet size, and even throw a ball with your mouse. It's ridiculous and I love it.

"vscode-pets.theme": "forest",
"vscode-pets.throwBallWithMouse": true,
"vscode-pets.petSize": "small"

Step 10: Hide Clutter from the File Explorer

If you're working on a JavaScript/TypeScript project, your node_modules and .next folders are constantly showing up in the explorer and it's really annoying. Hide them:

"files.exclude": {
  "**/.next": true,
  "**/node_modules": true
}

You can add any folders or file patterns here that you never want to see in the explorer.

The Complete settings.json

Here's everything in one place. Open your settings.json (Cmd/Ctrl + Shift + P → Open User Settings (JSON)) and paste this in:

{
  // ─────────────────────────────────────────────
  // WORKBENCH / UI LAYOUT
  // ─────────────────────────────────────────────

  "workbench.activityBar.location": "top", // Move the activity bar (Explorer, Git, etc.) to the top
  "window.commandCenter": false, // Disable the large command center search bar
  "workbench.iconTheme": "symbols", // Minimal icon pack
  "workbench.colorTheme": "Min Dark", // Color theme
  "workbench.statusBar.visible": false, // Hide the status bar for a cleaner UI
  "window.newWindowDimensions": "inherit", // New windows inherit the current window size
  "window.nativeFullScreen": true, // Use OS native fullscreen behavior
  "breadcrumbs.enabled": false, // Disable breadcrumbs navigation bar

  // ─────────────────────────────────────────────
  // FONTS & TYPOGRAPHY
  // ─────────────────────────────────────────────

  "editor.fontFamily": "Brass Mono, monospace", // Main editor font
  "editor.fontSize": 14, // Editor font size
  "editor.lineHeight": 1.6, // Improve readability of code spacing
  "editor.letterSpacing": 0.3, // Slight spacing between letters (optional aesthetic tweak)

  // ─────────────────────────────────────────────
  // TERMINAL APPEARANCE
  // ─────────────────────────────────────────────

  "terminal.integrated.fontFamily": "Brass Mono, monospace", // Terminal font
  "terminal.integrated.fontSize": 14, // Terminal font size
  "terminal.integrated.lineHeight": 1.6, // Extra spacing for terminal readability

  // ─────────────────────────────────────────────
  // FORMATTER / CODE STYLE
  // ─────────────────────────────────────────────

  "editor.defaultFormatter": "esbenp.prettier-vscode", // Use Prettier as the default formatter
  "prettier.tabWidth": 2, // Number of spaces per indentation level
  "prettier.useTabs": false, // Use spaces instead of tabs

  "editor.formatOnSave": false, // Format files automatically when saving
  "editor.insertSpaces": false, // Use spaces instead of tabs
  "editor.tabSize": 2, // Number of spaces per indentation level

  "files.trimTrailingWhitespace": true, // Remove trailing whitespace when saving
  "files.insertFinalNewline": true, // Ensure every file ends with a newline (POSIX standard)
  "files.trimFinalNewlines": true, // Remove multiple blank lines at end of file

  "css.lint.unknownAtRules": "ignore", // Ignore Tailwind warnings
  "scss.lint.unknownAtRules": "ignore", // Ignore Tailwind warnings
  "less.lint.unknownAtRules": "ignore", // Ignore Tailwind warnings

  // ─────────────────────────────────────────────
  // EDITOR BEHAVIOR
  // ─────────────────────────────────────────────

  "editor.detectIndentation": false, // Disable indentation auto-detection, Forces your manual indentation rules
  "editor.snippetSuggestions": "top", // Place snippets at top of autocomplete suggestions
  "editor.emptySelectionClipboard": true, // Copy line if nothing is selected
  "editor.copyWithSyntaxHighlighting": false, // Copy plain text instead of colored syntax

  // ─────────────────────────────────────────────
  // MINIMALIST UI (REMOVE VISUAL NOISE)
  // ─────────────────────────────────────────────

  "editor.minimap.enabled": false, // Disable minimap on right side
  "editor.lineNumbers": "off", // Hide line numbers
  "editor.guides.indentation": false, // Remove vertical indentation guides
  "editor.folding": false, // Optional: remove code folding controls

  // ─────────────────────────────────────────────
  // DIFF / GIT COMPARISON
  // ─────────────────────────────────────────────

  "diffEditor.ignoreTrimWhitespace": false, // Show whitespace differences in git diffs
  "diffEditor.renderSideBySide": true, // Side-by-side diff view instead of inline

  // ─────────────────────────────────────────────
  // NAVIGATION BEHAVIOR
  // ─────────────────────────────────────────────

  "editor.gotoLocation.multipleReferences": "goto", // If multiple results exist, jump directly instead of showing picker
  "editor.gotoLocation.multipleDefinitions": "goto", // If multiple results exist, jump directly instead of showing picker
  "editor.gotoLocation.multipleDeclarations": "goto", // If multiple results exist, jump directly instead of showing picker
  "editor.gotoLocation.multipleImplementations": "goto", // If multiple results exist, jump directly instead of showing picker
  "editor.gotoLocation.multipleTypeDefinitions": "goto", // If multiple results exist, jump directly instead of showing picker

  "workbench.editor.enablePreviewFromQuickOpen": false, // Prevent preview tabs from Quick Open (Ctrl+P)

  // ─────────────────────────────────────────────
  // AI / EXTENSIONS
  // ─────────────────────────────────────────────

  "gitlens.ai.model": "vscode", // GitLens AI model configuration
  "gitlens.ai.vscode.model": "copilot:gpt-4.1", // GitLens AI model configuration

  // ─────────────────────────────────────────────
  // FUN (VS CODE PETS)
  // ─────────────────────────────────────────────

  "vscode-pets.theme": "forest", // Pet theme
  "vscode-pets.throwBallWithMouse": true, // Allow throwing ball with mouse
  "vscode-pets.petSize": "small", // Smaller pet size

  // ─────────────────────────────────────────────
  // FILE EXPLORER
  // ─────────────────────────────────────────────

    "files.exclude": {
        "**/.next": true,
        "**/node_modules": true
    },
}

⚠️ Heads up: This will replace your existing settings. If you have settings you want to keep, copy specific sections instead of pasting the whole file.

Quick Reference: What Each Section Does

Setting	Effect
`activityBar.location: "top"`	Moves icons from the side to the top
`statusBar.visible: false`	Hides the bottom bar
`minimap.enabled: false`	Removes the code overview on the right
`lineNumbers: "off"`	Hides line numbers for a cleaner look
`breadcrumbs.enabled: false`	Removes the navigation path above the editor
`editor.folding: false`	Removes code folding arrows
`editor.lineHeight: 1.6`	Adds breathing room between code lines
`files.trimTrailingWhitespace: true`	Automatically cleans up whitespace on save

Frequently Asked Questions

Q: Will hiding the status bar mean I can't see my Git branch? A: You'll still see it in the activity bar when you open the Source Control panel. And GitLens gives you much richer Git info anyway.

Q: What if I need line numbers back temporarily? A: Just open the Command Palette (Cmd/Ctrl + Shift + P) and search for "Toggle Line Numbers" - no need to edit settings.

Q: Can I use a different theme instead of Min Dark? A: Absolutely! The theme setting is completely independent from everything else. Popular alternatives include Tokyo Night, Catppuccin, Dracula, and One Dark Pro.

Q: My font isn't showing up after installation. A: Make sure you restarted VS Code after installing the font. Also double-check that the font name in settings.json exactly matches the font's name as installed on your system.

Q: Some of my extensions seem to conflict with these settings. A: The most common culprits are other formatter extensions. Make sure editor.defaultFormatter is set to Prettier, and disable any other formatters that might be interfering.

Final Thoughts

The goal of a setup like this isn't to look cool on Twitter (although, yeah, it does look pretty nice). It's to reduce the cognitive load of your environment so your brain can focus on the actual problem you're trying to solve.

Once you get used to working in a clean, minimal editor, going back to the default VS Code layout feels genuinely overwhelming. Give it a week and I promise you won't look back.

Happy coding! 🎉

Found this helpful? Share it with a fellow developer who's drowning in VS Code.

Originally posted here: https://dudych.com/blog/how-i-transformed-vs-code-into-a-cozy-minimalist-workspace-full-setup-guide

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