Introduction — Security Locks Get Better Over Time

Have you ever kept an old lock on your door even though newer, safer ones are available? Building websites can feel the same way. After a recent WordPress project, I realized we spend a lot of time supporting very old JavaScript versions that have known security limitations—like keeping an old lock “just in case” even though it’s easier to pick.

This article explains why, in 2025, you should target ES2020 (also called ES11) as your minimum JavaScript version. If you’re not a techie, don’t worry! I’ll use simple analogies and plain language throughout.

Summary:

Newer JavaScript versions have better security features that protect your site and visitors. ES2020 (from 2020) should be your minimum baseline in 2025.

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.


ES2020 (ES11): Security Features Built Into the Language

What is ES2020 (ES11)?

ES2020 (also called ES11) is a version of JavaScript from 2020 that includes important safety features. The two most important security improvements are:

  1. Optional Chaining (?.) — Prevents crashes when accessing data that might not exist
  2. Nullish Coalescing (??) — Safely handles missing or empty values

Why does this matter for security?

Many security vulnerabilities happen when code tries to access data that doesn’t exist or makes wrong assumptions about values. ES2020’s features prevent these common mistakes at the language level.

Security Analogy:

Think of ES2020 features like safety guards on power tools:

  • Old way (ES5/ES6): Like a table saw without a blade guard — you have to be very careful not to make mistakes
  • New way (ES2020): Like a modern table saw with automatic blade guards — the tool itself prevents common accidents

Over the last decade, devices and browsers have largely stabilized and toolchains have matured. That stability means teams can now focus on security-first development rather than maintaining compatibility hacks for outdated browsers.

Quick facts:

Most devices from 2020 and newer fully support ES2020 (ES11) features.

Device / Platform ES2020 Full Support Security Benefits
iPhone 12+ / iOS 14+ 2020 Optional chaining, nullish coalescing
Android 10+ (Chrome 80+) 2020 Full ES2020 security features
Google Pixel 4+ 2020 Complete ES2020 support
Samsung Galaxy S20+ 2020 All ES2020 safety features
Modern desktop browsers 2020 Chrome 80+, Firefox 74+, Safari 13.1+, Edge 80+

Tip: If you use a phone or computer from 2020 or newer, you have full ES2020 security features!

Security Coverage in 2025:

  • Devices from 2020-2025 (5 years): 95%+ of web users have ES2020 support
  • Devices from 2017-2019 (3 years): May need polyfills for some ES2020 features
  • Devices older than 2017: Represent less than 2% of users and have known security limitations

Summary: By requiring ES2020, you reduce security risks for 95%+ of your users while excluding only very old, potentially insecure devices.


Security Improvements: ES6 to ES2020 (Reducing Risk Exposure)

What is “risk exposure degrees”?

Think of it like layers of protection in your home:

  • One lock on the door = some protection
  • Deadbolt + chain lock + alarm = multiple layers = less risk

Each JavaScript version from ES6 to ES2020 added security layers. By skipping to ES2020, you get all those layers at once instead of the minimal protection of ES6.

Key Security Improvements by Version:

ES2016 (ES7) - Safer Array Checking:

  • Array.includes() — Safer than old indexOf() method
  • Security benefit: Prevents bugs from confusing -1 with valid array positions
  • Analogy: Like having a “yes/no” answer instead of checking if a number is “not -1”

ES2017 (ES8) - Better Error Handling:

  • async/await — Cleaner error handling for asynchronous code
  • Object.entries() / Object.values() — Safer object iteration
  • Security benefit: Easier to catch and handle errors properly; prevents accidental data leaks
  • Analogy: Like having airbags that deploy properly vs. hoping your seatbelt catches you

ES2018 (ES9) - Improved Promise Handling:

  • Promise.finally() — Ensures cleanup code always runs
  • Rest/spread for objects — Safer object copying
  • Security benefit: Resources are properly cleaned up even when errors occur
  • Analogy: Like making sure you lock the door even if you forget your keys

ES2019 (ES10) - Safer Object Operations:

  • Array.flat() / flatMap() — Prevents deeply nested data structure bugs
  • Object.fromEntries() — Safer object construction
  • Optional catch binding — Cleaner error handling
  • Security benefit: Reduces complexity that can hide security flaws
  • Analogy: Like organizing a messy closet so you can see what you have

ES2020 (ES11) - Critical Security Features:

  • Optional Chaining (?.) — Prevents runtime crashes from null/undefined access
  • Nullish Coalescing (??) — Safely handles missing values without false-positive bugs
  • BigInt — Prevents integer overflow vulnerabilities
  • Promise.allSettled() — Better error handling for multiple operations
  • Dynamic import — Code splitting reduces attack surface
  • Security benefit: Language-level protection against the most common JavaScript vulnerabilities
  • Analogy: Like having automatic brakes that stop your car when sensors detect danger

Real-World Security Example:

Old way (ES5/ES6) - Vulnerable:

// This can crash your app if user.profile is null
const name = user.profile.name;

// This treats 0 and "" as missing, causing bugs
const count = options.count || 10;

New way (ES2020) - Protected:

// Safely returns undefined instead of crashing
const name = user?.profile?.name;

// Only treats null/undefined as missing, not 0 or ""
const count = options.count ?? 10;

Why this matters for security: When apps crash or behave unexpectedly, attackers can exploit those moments to inject malicious code or access data they shouldn’t. ES2020 prevents these crashes at the language level.

Reducing Risk Exposure Degrees:

By requiring ES2020 instead of ES6, you eliminate 5 years of potential security gaps:

Support Level Risk Exposure Security Layers
ES5 (2009) Very High Basic only
ES6 (2015) High Basic + modules
ES2017 (ES8) Medium + error handling
ES2019 (ES10) Medium-Low + safer object operations
ES2020 (ES11) Low + crash prevention + null safety
ES2023+ Very Low + continued security enhancements

Security Analogy: Requiring ES2020 is like requiring modern seatbelts (3-point with airbags) instead of accepting old lap belts. Yes, old lap belts provide some protection, but modern safety features save lives.


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).
  • In 2021, WordPress 5.9 began supporting more ES2020 features in the block editor.
  • As of 2025, WordPress 6.5+ fully supports ES2020 (ES11) in block themes and modern plugins.
    • WordPress supported ES5 JavaScript since around version 2.8 (2009), which enabled compatibility with older browsers and classic themes for many years.
    • Security recommendation for 2025: New WordPress sites should target ES2020 as the minimum to take advantage of built-in security features.

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 Security-First Proposal

Practical advice for 2025:

  1. Target ES2020 (ES11) as your minimum — Use optional chaining (?.) and nullish coalescing (??) to prevent common security bugs.
  2. Use modern web tools (ES2020 modules, block themes) for new projects — they have security features built in.
  3. Exchange content as Markdown documents — they’re easier to move into target pages and reduce formatting drift.
  4. Limit multiple nesting, colors, or inline styles in text — this improves accessibility and keeps documentation structures easy to manage.
  5. Keep classic themes for legacy sites only — but update the JavaScript to ES2020 where possible.
  6. If you must support very old browsers (pre-2020), create a basic fallback version with reduced functionality—don’t compromise security for 5% of users.
  7. Use browser analytics to understand your actual audience before making support decisions.

Security-specific recommendations:

  • Always use optional chaining when accessing nested properties: user?.profile?.name
  • Always use nullish coalescing for default values: count ?? 0
  • Use Promise.allSettled() instead of Promise.all() for better error handling
  • Implement dynamic imports to reduce the attack surface: only load code when needed
  • Use BigInt for financial calculations to prevent overflow vulnerabilities

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 — Security Is Not Optional

We’re not abandoning anyone. We’re choosing to protect the 95%+ of users who have modern, secure browsers. By requiring ES2020 (ES11) as your minimum JavaScript version in 2025, you:

  • Reduce security vulnerabilities by using language-level safety features
  • Prevent common bugs with optional chaining and nullish coalescing
  • Improve error handling with modern promise methods
  • Reduce attack surface with dynamic imports and code splitting
  • Protect user data with safer type handling (BigInt)

Modern browsers and phones make it easier to build fast, accessible, secure, and enjoyable websites for everyone. The small percentage of users on very old devices (pre-2020) can use a basic fallback version or should upgrade for their own security.

Final analogy: You wouldn’t install a lock from 2009 on your door today. Don’t use JavaScript from 2009 (ES5) or even 2015 (ES6) when 2020 (ES2020) provides better security for the same effort.

— Multiple drafts. Security-focused. Definitely caffeinated.