<!-* prettier-ignore-start –>

  • TOC

<!-* prettier-ignore-end –>

Introduction — A Short Story About a Long Browser

Have you ever kept an old appliance around “just in case”? Building websites can feel the same way. After a recent WordPress project, I realized we spend a lot of time making sure very old browsers still work—like keeping the heat on for a guest who never leaves.

This article is a friendly, slightly cheeky look at why, in 2025, it’s okay to use modern web tools and let go of outdated habits. If you’re not a techie, don’t worry! I’ll use simple analogies and plain language throughout.

Summary:

Modern web tools make websites easier to build and maintain. It’s okay to move on from old ways.

Release years for context:

  • Microsoft Windows: first released in 1985.
  • Apple Macintosh: first released in 1984.
  • “The Year of the Web” * 1995

Windows & Apple/iOS at a glance (selected years):

  • 2003 — Windows: Windows XP era (widely used). Apple/iOS: pre-iPhone (Mac OS X 10.3 Panther released 2003).
  • 2009 — Windows: Windows 7 released (2009). Apple/iOS: iPhone OS 3.0 (2009).
  • 2015 — Windows: Windows 10 released (2015). Apple/iOS: iOS 9 (2015).
  • 2019 — Windows: Windows 10 (ongoing updates; 2019 builds). Apple/iOS: iOS 13 (2019).
  • 2025 — Windows: Windows 11 is the modern baseline (released 2021; current in 2025). Apple/iOS: modern iOS releases (varies by device and year — check device settings for exact version in 2025).

Note: mobile OS versions (iOS, Android) and Windows builds vary by device and update cadence. Use analytics to understand what versions your audience actually uses before changing support policies.


ES6 Modules: The New Streetlights Everyone Can See

What JavaScript actually does (plain language):

JavaScript is the language that makes web pages move, respond, and change without reloading. It listens for clicks and typing, updates what you see on the page, runs small animations, fetches data from servers, and can even run on servers themselves (for example, with Node.js). Without JavaScript most sites would be static documents — useful, but less interactive and less helpful for modern tasks.

JavaScript standards explained:

  • ES5 (ECMAScript 5) was released in 2009 and became the standard for browser compatibility for many years.
  • ES6 (ECMAScript 2015) was released in 2015, introducing modules and many modern features now widely supported.

Short ECMAScript timeline:

  • First edition: ECMAScript 1 (1997).
  • 2003: ES3-era (ECMAScript 3 was published in 1999; there was no new edition in 2003).
  • 2009: ES5 (ECMAScript 5) — broad compatibility baseline for many years.
  • 2015: ES6 (ECMAScript 2015) — modules, modern syntax and features.
  • 2022: ECMAScript 2022 (ES2022) — newer yearly updates with incremental features.

What is ES6?

ES6 (also called ECMAScript 2015) is a newer version of JavaScript, the language that powers most websites. ES6 modules are a way to organize code into neat, reusable pieces—like putting ingredients into labelled jars.

Why does this matter?

Most modern phones and computers (made after 2019) understand ES6 modules. This means websites can be built in a cleaner, more organized way.

Over the last decade, devices and browsers have largely stabilized and toolchains have matured. That stability means a lot of the painful, device-specific complexity has been abstracted away by platforms and build tools, so teams can focus on crafting and publishing targeted experiences instead of maintaining dozens of small compatibility hacks. The old tools and fallbacks still exist for edge cases, but modern workflows make it much easier and faster to build custom, device-aware experiences for Edge, Chrome, Safari, and newer mobile browsers.

Analogy:

ES6 modules are like labelled jars in your kitchen. Instead of dumping everything into one pot and hoping for the best, you can grab exactly what you need.

Quick facts:

The iPhone 12 (2020) and most phones since 2017 support ES6 modules.

Device / Platform Approx. Year ES6 Support Became Widely Available
—————————–_ ———————————————–_
iPhone / Mobile Safari ~2016–2018
Android phones (Chrome) ~2017
Google Pixel series ~2017
Samsung Galaxy (modern models) ~2017–2018
Firefox for Android ~2017–2018

Tip: If you use a phone or computer made in the last five years, you’re probably fine!

Summary: Modern devices support new web features. You don’t need to worry about most old browser problems anymore.


WordPress Classic Themes: A Gracious Retirement Plan (But People Keep Inviting Them to Parties)

Quick laugh-out-loud clarification:

Jekyll and WordPress are not the same thing! Jekyll is a static site generator that turns Markdown files into a website with the speed of a postal worker on roller skates. WordPress, on the other hand, is a dynamic site builder (with PHP under the hood) that can be customized with classic themes, plugins, and a whole lot of button clicking. If you ever tried to use both at once, you probably laughed, cried, and then reached for more coffee.

Static vs dynamic (plain English):

A site built with Jekyll is typically rendered once at build time — the generator creates static HTML files you upload to a server or CDN. Those files don’t change unless you rebuild and redeploy. WordPress usually builds pages at runtime on the server, so content, layouts, or user-specific data can change instantly without rebuilding the whole site. In short: static = one-time render; dynamic = runtime changeable.

What is a WordPress theme?

It’s the design and layout for your website. “Classic themes” are older styles that were officially retired in 2022, but some sites still use them for old content.

Developer control vs built-in styles: Classic themes and custom PHP give developers full control over templates, markup, and styles — you can build anything, but you also maintain everything. In contrast, WordPress’s newer block themes and built-in style settings let editors adjust appearance and layout through the UI without code. That trade-off is why some teams start with classic themes for total control and later migrate to block themes for easier editing and consistency.

Why keep them?

Some organizations have important archives or old sites that need these classic themes. But for new projects, using modern themes saves time and effort.

In some projects I built a classic theme and then enabled block-theme compatibility using a classic engineering approach — this lets the site continue to support older browsers (including IE in constrained cases) while allowing us to gradually target new audiences on Edge, Chrome, and modern Safari.

WordPress timeline:

  • WordPress first launched in 2003.
  • In 2019, WordPress was at version 5.2, which introduced broader ES6 support and the block editor (Gutenberg).
  • As of 2025, WordPress is at version 6.5+, with even stronger ES6 and block theme support, plus many modern features.
    • WordPress supported ES5 JavaScript since around version 2.8 (2009), which enabled compatibility with older browsers and classic themes for many years.

Block themes and the Gutenberg project: design objectives

What is Gutenberg? Gutenberg is a new way to build WordPress sites using “blocks”—like LEGO pieces you can mix and match. This makes editing easier and less technical.

Where JavaScript goes in a block theme:

In block themes JavaScript lives alongside the theme or block assets and is explicitly registered so WordPress knows when to load it. Developers typically place scripts in the theme’s assets/js/ folder or inside a block’s build output, and then declare them in block.json (using editorScript / script) or enqueue them with wp_enqueue_script() for front-end behaviour. In plain terms: put your JS with the theme or block assets and declare it so WordPress loads it in the editor or on the page when needed.

Key goals:

  • Build pages from reusable blocks (like LEGO)
  • Edit headers, footers, and layouts visually
  • Use modern web technology for speed and accessibility
  • Make sure designs work for everyone, including people with disabilities

Analogy: Editing with Gutenberg is like swapping pieces in a brochure, not reprinting the whole thing.

Summary: Modern WordPress tools make editing easier for everyone. Classic themes are for old sites; new sites should use blocks.

Object Management Group (OMG) & Model-Driven Architecture (MDA)

You may have heard of the Object Management Group and Model-Driven Architecture (MDA) from the early 2000s. At its heart MDA is a simple idea: describe your application in a platform-independent way (a recipe), then transform that description into platform-specific code (the version that runs on a particular server or device). The two key concepts are the Platform-Independent Model (PIM) and the Platform-Specific Model (PSM).

Why this matters for WordPress and block themes: many of the same patterns appear in modern CMS work. Block metadata (block.json), theme metadata (theme.json), and the way blocks declare their scripts, styles, and render behaviour act like small, platform-specific models. Developers author blocks and templates in a general way (the PIM-ish recipe) and build toolchains produce the final assets and declarations the platform loads (the PSM-ish outputs). In plain terms: MDA-style separation—describe once, generate for the platform—helps block-enabled theme delivery by keeping content models, presentation, and platform wiring distinct.

Analogy: Think of MDA as writing a single recipe that can be transformed into a version for a gas oven, an electric oven, or a microwave. WordPress block metadata is the recipe; the theme assets and registered scripts are the oven-specific instructions.


Jekyll, Markdown, and a Brief Timeline

What is Markdown? Markdown is a simple way to write text that turns into a website. It was created in 2004.

What is Jekyll? Jekyll is a tool (from 2008) that takes Markdown files and builds a website automatically. It’s used by many writers and small teams.

Jekyll provides its own platform-specific implementation using Ruby and front matter: authors write simple front-matter metadata and Markdown, and Jekyll (Ruby) transforms that into the site output. In spirit this mirrors how WordPress uses PHP and block.json/theme metadata to describe and produce platform-specific assets.

Analogy: Writing in Markdown is like writing a clear letter. Jekyll is the postal worker who delivers it online.

Summary: Markdown and Jekyll make website writing simple and friendly, even for non-technical people.


Templating Exceptions, Noscript Fallbacks, and ES5 Support in 2025 — Why We Should Stop Stalling

What does this mean? In the past, developers added lots of special rules (“exceptions”) to make websites work for very old browsers. This made websites harder to build and test.

Why stop?

  • Every extra rule means more testing and more chances for mistakes
  • New people have to learn old, confusing code
  • It slows down improvements for accessibility and usability

Summary: Don’t add lots of old-browser rules unless you really need them. Focus on making your site work well for most people.


Accessibility Wins by Letting Go

What is accessibility? Making sure everyone—including people with disabilities—can use your website.

Why does modern code help? Clean, simple code is easier to make accessible. You can focus on things like keyboard navigation and clear labels.

Summary: Using modern tools helps everyone, especially those who need accessible websites.


A Modest Proposal

Practical advice:

  1. Use modern web tools (ES6 modules, block themes) for new projects.
  2. Exchange content as Markdown documents — they’re easier to move into target pages and reduce formatting drift.
  3. Limit multiple nesting, colors, or inline styles in text — this improves accessibility and keeps documentation structures easy to manage.
  4. Keep classic themes for legacy sites.
  5. If you really need to support very old browsers, make a special version—don’t complicate your main site.

What does this mean for you?

If you’re not a developer:

  • You can expect websites to work well on your phone or computer if it’s not ancient.
  • Editing and updating sites is easier than ever—no need to call a developer for every change.
  • Accessibility is improving, so sites are more usable for everyone.

If you manage a website:

  • Ask your developer to use modern tools unless you have a special reason not to.
  • Don’t worry about supporting very old browsers unless your audience needs it.

Conclusion — Progress Is Not Personal

We’re not abandoning anyone. We’re choosing to spend our time and care where it helps most. Modern browsers and phones make it easier to build fast, accessible, and enjoyable websites for everyone.

— Multiple drafts. Slightly opinionated. Definitely caffeinated.