Skip to content

Instantly share code, notes, and snippets.

@szymdzum

szymdzum/The Interface Ignored.md

Created June 16, 2025 21:45
Show Gist options
  • Save szymdzum/9db3a3faade490fe989da6c4963ae53c to your computer and use it in GitHub Desktop.
Save szymdzum/9db3a3faade490fe989da6c4963ae53c to your computer and use it in GitHub Desktop.
Download ZIP
Raw
The Interface Ignored.md

HTML is an Interface, and We've Been Treating It Like a Whiteboard

The Interface We All Agreed to Ignore

Picture this: You're reviewing a pull request and you see this beauty:

interface Product {
  sc_kDDrLX: string;      // ??? maybe a title?
  eYUOdi: any;            // your guess is as good as mine
  sc_eTJJzz: HTMLElement; // definitely contains... something
  jZIOjg: {
    sc_jOrMOR: {
      jhjLMC: Array<{
        'animated-usp-bar'?: boolean; // at least this one has a hint!
        kBDVDP: unknown;
      }>;
    };
  };
  
  // New requirement: add price
  sc_HzFiz?: {
    laNWFJ: number | string | JSX.Element; // why not all three?
  }
}

You'd probably leave a comment like "Hey, could we maybe use... words?"

Yet here we are, shipping this exact interface to production every day. We just call it HTML.

The Plot Twist: HTML Has More Consumers Than Your Average API

When we write a REST API, we know exactly who's calling it. Our frontend. Maybe a mobile app. That's it.

But HTML? Oh boy, HTML is the social butterfly of interfaces:

  • Screen readers trying to navigate our div maze like it's an escape room
  • Search engines attempting to understand if sc_kDDrLX is a product name or a nuclear launch code
  • Browser translation wondering if "jhjLMC" is a new slang term kids are using
  • Voice assistants having an existential crisis ("Hey Siri, click on the sc-bPyhqo gXWwCr")
  • That one developer who joined last week and is now questioning their life choices
  • Future AR glasses that will project our div soup directly onto people's retinas

The Hidden Invoice Nobody Wants to Talk About

Here's where it gets expensive. That innocent-looking CSS-in-JS setup? It's costing more than your coffee budget:

The Bundle Size Tax

{
  "dependencies": {
    "react": "^18.2.0",              // 142kb
    "styled-components": "^6.0.0",   // 95kb
    "emotion": "^11.0.0",            // 87kb
    "your-ui-library": "^3.0.0",     // 400kb
    "the-library-that-library-needs": "^2.0.0", // 200kb
    // ... 147 more dependencies
  }
}

That's 2.3MB of JavaScript... to display a price. Your customers are downloading the equivalent of Windows 95 to see "€504".

The Build Time Premium

  • Local build: 45 seconds (enough time to question your career choices)
  • CI/CD pipeline: 12 minutes (AWS bills go brrrrr)
  • Deploy to production: 8 minutes
  • Developer waiting: Priceless... no wait, it's about €50/hour

Multiply that by every commit, every hotfix, every "just updating dependencies" PR.

The Client-Side Environmental Disaster

Here's the part that should make us all uncomfortable: We're essentially running a small power plant on every visitor's device.

// What happens on EVERY page load:
1. Download 2.3MB of JavaScript
2. Parse it all
3. Execute styled-components runtime
4. Generate CSS from JavaScript
5. Inject into DOM
6. Recalculate styles
7. Re-render everything
8. Pray the user's phone doesn't catch fire

Fun fact: A study showed that JavaScript-heavy sites cause phones to use 3x more battery. We're literally draining the planet one sc-kDDrLX at a time.

A Real Example That Hurts Just Right

Take a look at this actual markup for a simple price display:

<div class="sc-csvncw jRhAgz">
  <div class="sc-fIavCj cvVbeA">
    <span class="sc-grREDI bxFdGg">
      <span class="sc-fctJkW hZHWuD">€</span>
      <span class="sc-brCFrO dFiDPF">630</span>
    </span>
  </div>
  <div class="sc-HzFiz laNWFJ">
    <span class="sc-fctJkW hZHWuD">€</span>
    <span class="sc-brCFrO dFiDPF">504</span>
  </div>
</div>

Quick quiz: Which one is the current price? Is there a discount? Is this even a price, or did someone's cat walk across the keyboard?

The Same Thing, But With Respect for Physics and Wallets:

<div class="price-display">
  <del class="price--original">€630</del>
  <data class="price--current" value="504">€504</data>
</div>

Cost savings:

  • 80% less markup
  • 0 JavaScript required
  • Builds in 0 seconds
  • Runs on a potato
  • Screen readers understand it
  • Google loves it
  • Your AWS bill thanks you

The Thing Is, HTML Already HAD an Interface Spec

HTML elements are like interface methods. When you use a <button>, you're not just getting a clickable rectangle. You're getting:

  • Keyboard support (Enter AND Space, thank you very much)
  • Focus management
  • Screen reader announcements
  • Touch target sizing hints
  • Right-click context menus
  • Drag and drop participation
  • Form submission superpowers

When we replace it with <div onclick="...">, we're essentially saying: "Nah, I'll implement the Button interface myself. How hard could it be?"

Narrator: It was, in fact, very hard.

The European Accessibility Act Has Entered the Chat

Here's where it gets spicy. The EAA deadline isn't just a suggestion - it's the universe's way of saying "Remember that interface you've been ignoring? Yeah, about that..."

And honestly? Thank goodness. Because left to our own devices (pun intended), we've turned the web's universal language into:

<!-- A heading, apparently -->
<div class="sc-kDDrLX eYUOdi">Our unmissable summer deals</div>

<!-- A... navigation? List? Modern art installation? -->
<div class="sc-hiMGwR kRmEyF">
  <div class="sc-ehmTmK jGDwjw">
    <div class="sc-gFGZVQ sc-ckMVTt jeOjzz jkQHlf">

The Numbers That Make CFOs Cry

Let's talk money, because apparently that's the only language that gets through:

Scenario: E-commerce site with 100k daily visitors

The JavaScript-All-The-Things Approach:

  • Average page weight: 3.2MB
  • Load time on 4G: 8 seconds
  • Bounce rate at 8 seconds: 38%
  • Lost customers daily: 38,000
  • Infrastructure costs: €4,200/month
  • Developer time debugging sc-kDDrLX: Immeasurable

The HTML-First Approach:

  • Average page weight: 0.8MB
  • Load time on 4G: 2 seconds
  • Bounce rate at 2 seconds: 9%
  • Lost customers daily: 9,000
  • Infrastructure costs: €1,100/month
  • Developer time debugging <article class="product">: Minimal

Annual difference: €37,200 in hosting + whatever 10,585,000 extra customers are worth to you.

The Beautiful Truth Nobody Talks About

Here's the kicker: HTML is humanity's most successful API. It's been running in production for 30+ years. It's backwards compatible. It's forward compatible. It works on a 1990s browser AND on whatever apocalypse-proof quantum computer we'll have in 2050.

And we're treating it like a canvas for our CSS-in-JS finger painting.

Imagine if other protocols worked this way:

  • HTTP: "GET? POST? Nah, let's use YEET and FETCH_BUT_MAKE_IT_FASHION"
  • TCP/IP: "Packets are so limiting. What if we just sent vibes?"
  • SQL: "SELECT * FROM t1 JOIN x9k2p ON q.🤷‍♂️ = p.️❓"

So... What Does This Mean for Us?

[This is where I'm supposed to give you a 5-step action plan, but let's be real - if you've made it this far, you're already asking the right questions.]

The web gave us a beautiful contract. Elements with meaning. Structure with purpose. An interface that speaks to humans AND machines. One that doesn't require a small nuclear reactor to run.

Maybe it's time we started honoring that contract again? Your users' phone batteries (and the planet) will thank you.

What do you think? Are we overthinking this, or is HTML-as-interface the hill we should die on? Drop your hottest takes in the comments - bonus points if you can explain what sc-kDDrLX actually means. 😄

P.S. - I ran the calculations. The CO2 emissions from parsing JavaScript-heavy sites could power a small country. But sure, let's keep generating CSS at runtime because... reasons? 🌍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment