DEV Community: Michael Mathews

Clickable Card Patterns and Anti-Patterns

Michael Mathews — Tue, 16 Dec 2025 13:04:18 +0000

A frequent design requirement is to maximize the interaction area by making an entire card container clickable, for example, linking to a detail page.

However, when this approach is combined with card text that itself may contain links (such as to an author's profile, category tags, or action buttons), it creates a conflict that violates HTML semantics and could compromise accessibility.

The Problem

The core of the problem lies in attempting to nest interactive content. Consider the following structure used to make a card fully clickable:

<!-- ⚠️ Don't do this -->
<a href="/article/card-detail">
  <div class="card">
    <p>Author: <a href="/authors/jamil">Jamil</a>.</p>
  </div>
</a>

This structure is problematic for at least two reasons:

The HTML Specification: A hyperlink (an <a> element that has an href attribute) is interactive content. According to the HTML Living Standard, an interactive element must not contain other interactive or focusable elements as descendants, which effectively prohibits a hyperlink from containing elements like <button>, <input>, or another <a href="…">.
Assistive Tech Trip-Ups: For users relying on screen readers or keyboard navigation, this nesting creates confusion and redundancy. Assistive technologies encounter two different links with overlapping hit areas. Tabbing behavior becomes unpredictable, and the link name (as read out by screen readers) becomes the card's entire contents. Not great!

Use the Stretched Link Pattern

The recommended approach to achieving a fully clickable card—while maintaining semantic validity and good accessibility—is to use the Stretched Link Pattern, which leverages CSS positioning and stacking context (z-index).

The goal is to ensure that only the primary element (e.g., the card title) is wrapped in the "more information" link, and then use CSS to expand its hit area to cover the entire card, deliberately positioning other interactive elements above it.

1. Semantic HTML Structure

The recommended structure keeps the primary link and secondary interactive elements separate and non-nested.

<div class="card">
  <!-- 💁‍♂️ Use this as the primary link for the whole card. -->
  <a href="/article/card-detail" class="card__main-link">
    <h3>Article Title</h3>
  </a>

  <img src="article-thumb.jpg" alt="Article Thumbnail">

  <!-- 👇 More links may be in the body of the card. -->
  <p>Author: <a href="/authors/jamil">Jamil</a>.</p>
</div>

2. CSS Implementation: Stacking Context Management

We use position: absolute and z-index to manage layer order, ensuring the stretched link remains visually active while internal links retain interaction priority.

Element	Key CSS Properties	Function
`.card`	`position: relative;`	Establishes the stacking context for absolute children.
`.card__main-link::after`	`content: '';` `position: absolute;` `inset: 0;` `z-index: 1;`	Stretches the (invisible) link across the whole card to act as the primary click target.
Inner Interactive Elements (`a`, `button`)	`position: relative;` `z-index: 2;`	Lifts these elements above the stretched link's hit area, preserving their intended functionality and focus order.

/* 1. The parent element context */
.card {
  position: relative; 
  /* Other styles (border, padding, etc.) */
}

/* 2. The stretched click area */
.card__main-link::after {
  content: '';
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  z-index: 1; /* Less than the inner interactive elements */
  pointer-events: auto; 
}

/* 3. Priority for Internal Interactive Elements */
.card p a,
.card button {
  position: relative;
  z-index: 2; /* Above the stretched click area */
}

Conclusion

Using the Stretched Link Pattern resolves the conflict between design intent (making the card itself fully clickable) and technical compliance (avoiding nested interactive elements).

By prioritizing correct HTML semantics and managing the stacking context, developers and designers can ensure that components are robust, fully accessible, and provide a predictable user experience.

Photo by gabby-k

Who Needs CSP?

Michael Mathews — Mon, 01 Dec 2025 11:04:50 +0000

You've probably heard about Content Security Policy (CSP) in the context of web security. But what is CSP for, and is it appropriate for your project?

What is Content Security Policy (CSP)?

At its core, CSP is a set of security practices and a standard that can be used to tell browsers which resources your website will be allowed to load and execute. Think of it as a security guard standing at the front door of your web page—it only lets scripts, styles, and other resources inside if they are on the guest list.

The way you tell the web browser which resources are considered safe to allow in is with a Content-Security-Policy HTTP header. An example CSP configuration heading might look like this:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com

This configuration tells the browser: "By default, only load resources from my own domain (self), and any scripts must come from my domain or Google's API server." It also blocks any inline CSS and JS from running.

The Security Problem CSP Solves

CSP is primarily intended to protect against XSS (Cross-Site Scripting) attacks. This class of attack occurs when a hacker injects malicious code into your web page.

For example, without CSP, if a baddie injects <script>stealAllYourUserData()</script> into your web page's source code, the browser will execute it, the same as if you wrote that code yourself. But with CSP, the browser must first check whether the script originated from a pre-approved source; if not, it blocks it, preventing the hacker's code from running.

XSS Examples

There are lots of ways that a user could (intentionally or not) inject JS or CSS into an unprotected webpage. XSS is a possibility in any place where a user can submit content that is later displayed on your page. Some examples include:

Comment sections, forum posts, and reviews where HTML or markdown is not filtered effectively/escaped.
User profiles with custom bios, display names, or avatars that allow HTML/JS.
File uploads where SVGs (which can contain script) or text files are served as HTML.

CSP Benefits and Trade-offs

You may say, "But if I'm already super careful about not allowing arbitrary user code to appear in my web page, why do I need CSP as yet another layer of security?" It's a fair question.

Think of CSP like seatbelts in cars. Even if you drive carefully (secure coding), maintain your vehicle (input validation), and follow traffic rules (authentication), you still wear a seatbelt (CSP) because accidents sometimes happen for reasons beyond your control. Using CSP adds another safety net in case something goes wrong unexpectedly.

Do You Need CSP for Your Website

Likely yes if your website:

Handles sensitive data, such as financial, medical, and personal information
Allows user-generated content, for example, comments, posts, rich text editors
Uses many third-party scripts, such as analytics, ads, widgets
Is a high-value target, such as e-commerce, banking, social platform

Maybe not if your website:

Is a simple static site, for example, a static blog, portfolio, or documentation site
Has no user-generated content, never displays user comments, for example
Has no third-party included content, for example, analytics, font, or ad services
Are building internal tools with limited exposure
Are early in development, such as a prototype, and you intend to reassess your vulnerabilities before moving to production

But honestly, there aren't many good reasons not to take security as seriously as possible these days. My advice is to be smart and be safe!

Getting Started

The basic goal of CSP is to use the HTTP header to authorise the resources your web page is allowed to use. So you will need to configure your web server to add a Content-Security-Policy header to your HTML response.

1. Start Simply

The following policy allows the page to load and execute resources (including scripts and styles) only from the same origin (domain) as the HTML document. It blocks inline scripts and styles unless you explicitly relax it with additional unsafe directives such as script-src 'unsafe-inline' or style-src 'unsafe-inline'.

Content-Security-Policy: default-src 'self'

It's (very) possible to accidentally exclude legitimate resources with a CSP header, so be sure to thoroughly test your site before publishing security restrictions.

2. Use Report-Only Mode First

Deploy in monitoring mode to see what would break:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-reports

3. Gradually Add More Complex Restrictions

Once you've identified and fixed any initial issues, switch to enforcement mode and slowly add more complex rules.

4. Focus on the Biggest Risks

Prioritize script-src and style-src directives first since these are where most XSS vulnerabilities happen.

A Basic Starter CSP

Content-Security-Policy: 
  default-src 'self';
  script-src 'self';
  style-src 'self';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self'

What this does:

Allows resources only from your own domain ('self')
Blocks any inline scripts and styles (which could be injected via XSS attacks)
Allows images from your domain, data URLs, and any HTTPS source
Prevents connections to any external APIs except your own

Handling Inline CSS/JS

Adding default-src 'self' not only blocks any external domains—such as popular CDNs, analytics, fonts, etc.—it also blocks all inline CSS and JS code. If you need to allow inline CSS or JS, there are two possible approaches: hashes (best for static sites) or nonces (for dynamically generated sites).

💁‍♂️ Technically, you could add script-src 'unsafe-inline' to, for example, allow any inline JS to execute, but that would completely defeat the whole purpose of CSP, so obviously, don't do that.

Option 1: Using Hashes (Best for Static Sites)

First, identify your critical inline code:

<!-- Critical above-the-fold CSS -->
<style>
.hero { background: #fff; color: #333; }
.button { padding: 1rem 2rem; }
/* ... more critical styles */
</style>

<!-- Essential initialization script -->
<script>
window.APP_CONFIG = { apiUrl: '/api', theme: 'dark' };
initializeApp();
</script>

Calculate the SHA-256 hashes for each inline code and include them in your CSP header:

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'sha256-abc123...';
  style-src 'self' 'sha256-def456...';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self'

Remember, once you generate a hash for a string of CSS or JS, changing even a single character of the code requires you to regenerate the hash and update the header again. If you rarely modify inline code or have an automated system to handle it for you, this might not be a problem, but it does introduce a footgun that might surprise someone (in a bad way) later on when they "just need to make a quick change" to your code.

How to generate hashes

Assuming you have decided to add a hash to your CSP header to authorize some inline JS, you can use any tool capable of making sha256 hashes of strings, such as openssl.

# For a script: <script>alert('Hello');</script>
echo -n "alert('Hello');" | openssl dgst -sha256 -binary | openssl base64

This produces the hash gKHd+pSZOJ3MwBsFalomyNobAcinjJ44ArqbIKlcniQ=.

You would then add the following to your CSP header to allow the browser to run it:

script-src 'self' 'sha256-gKHd+pSZOJ3MwBsFalomyNobAcinjJ44ArqbIKlcniQ=';

Ideally, this would be set up to happen automatically during your build process.

Option 2: Using Nonces (Dynamic Sites)

Using a nonce makes more sense if you have blocks of inline code you want to allow, but that may change frequently, are dynamic, or differ on every page, and generating a hash for every page is too onerous.

Instead, you could configure your server to generate a unique nonce, any hard-to-guess string that is different for each request. Your server would add that value to each <style> or <script> tag you want to safelist (regardless of its contents), and include the nonce in the HTTP headers.

<style nonce="cryptoR4nd0m123">
  /* Any CSS in here to be considered safe */
</style>

<script nonce="cryptoR4nd0m123">
  // Any JS in here to be considered safe
</script>

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'nonce-cryptoR4nd0m123';
  style-src 'self' 'nonce-cryptoR4nd0m123';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self'

Remember, a nonce is not just hard to guess (like a password); it must also be unique for every single page view. Otherwise, a hacker could just hit "view source", copy whatever nonce they find, and inject their baddie code with that same nonce value. By making the value unique per view, knowing an already-used nonce is useless to the hacker.

The nonce approach is arguably more straightforward and performant than hashes because there is no hash generation involved, but having to modify the <script> or <style> with a unique nonce attribute for every page view will destroy any server-side caching strategy you may have in place. It also means you cannot serve static web pages at all, since, by definition, a nonce is never repeated from one page view to the next.

When you need server-side caching or static HTML, the hash method is your better option.

More Examples

Basic Protection

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'

Add Some External Resources and Inline Resources

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'sha256-abc123...' https://www.google-analytics.com https://cdnjs.cloudflare.com;
  style-src 'self' 'sha256-def456...' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https: https://www.google-analytics.com;
  connect-src 'self' https://api.example.com

Move to Stricter Protection

Content-Security-Policy: 
  default-src 'none';
  script-src 'self' 'sha256-abc123...';
  style-src 'self' 'sha256-def456...';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none'

Development vs Production

You will likely find that you need different security policies when developing than when in production.

Development (more permissive):

Content-Security-Policy-Report-Only: 
  default-src 'self';
  script-src 'self' 'unsafe-eval';  # For hot reloading
  style-src 'self' 'unsafe-inline'; # For development convenience
  report-uri /csp-reports

Production (more restrictive):

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'sha256-abc123...';
  style-src 'self' 'sha256-def456...';
  img-src 'self' data: https:;
  font-src 'self'

Example: Adding CSP to an AWS CloudFront Response Headers Policy

This is a basic, straightforward approach if you are using CloudFront content distribution caching.

Step 1: Create a Response Headers Policy

AWS Console → CloudFront → Policies → Response headers
Click "Create response headers policy"
Configure a basic CSP that says only CSS and JS from files on the same domain are allowed:

  Name: my-awesome-csp-policy
  Headers:
    - Content-Security-Policy: 
        Value: "default-src 'self'; script-src 'self'; style-src 'self'"
        Override: true

Note that this will tell the browser not to run any inline CSS or JS, and to allow such resources only from files hosted on the same domain.

Step 2: Attach Policy to Specific Cache Behaviors

CloudFront → Distributions → Your Distribution
Go to the Behaviors tab
Edit the specific path pattern (e.g., /*, /secure/*, or /checkout)
In Response headers policy, select your CSP policy, "my-awesome-csp-policy" in this example
Save changes

Result: Only requests matching that path pattern will get the CSP header.

Is CSP a Silver Bullet to Prevent All XSS?

Nope. There are still plenty of ways a user could inject code to run in your web page if you aren't careful. For example, if you assume that strings in a browser cookie, in the url, or from an API endpoint are "safe" and evaluate them or write them to the document with JavaScript, congratulations: you've just opened a door to XSS that CSP can't protect you from.

The point is, adding CSP defences doesn't mean you can stop thinking about XSS. It's still a hard problem, and it's still your responsibility.

Summary

Determine whether your specific use case requires CSP and whether the trade-offs are justified. Consider CSP another layer of your website defence strategy; don't neglect other methods to prevent unauthorized content injection. For your first effort using CSP, begin with a minimal configuration that blocks inline scripts and styles. If you need inline code (for performance reasons, for example), use hashes for specific, verified content. This approach will give you 80% of the security benefits at 20% of the complexity.

photo credit: Rulo Davila

Do You Need A Cookie Notice If You Don't Use Cookies?

Michael Mathews — Tue, 18 Nov 2025 16:25:19 +0000

Ever wondered, "If my website doesn't use cookies, do I actually need a cookie notice?" The answer to that is maybe.

It's a myth that the EU Privacy and Electronic Communications Directive, also known as the ePrivacy Directive (ePD), applies only to cookies. It's much more comprehensive than that.

It’s not (only) about cookies

Firstly, don't call it the "cookie law." The ePD is not a law, and the original text did not even mention cookies.

As a directive, the ePD is not directly enforceable. Instead, it directs EU Member States to meet a set of specific goals without dictating how they do so; It is up to each EU country to pass its own laws to comply with the ePD's requirements.

Storing or accessing information in the user's terminal equipment

The section of the original directive that applies to the subject of this article does not mention cookies; it states only that…

"… the storing of information, or the gaining of access to information already stored, in the terminal equipment [such as web browsers or mobile devices] of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information…"

In 2009, the ePD was amended to specifically mention cookies and "similar tracking technologies," but it was not only about cookies.

The ePD works alongside the General Data Protection Regulation (GDPR), which concerns the protection of users' privacy. If you are storing or transmitting personally identifiable information, that regulation may apply to you as well.

While the use of cookies is the most well-known target of ePD-related regulations, they apply to any technology that stores or accesses information on a user’s device.

This includes:

Tracking Pixels: Using invisible images to include information that instructs the user's device (browser or email client) to send data (e.g., an email open, page view, or IP address) to a remote server.
Local/Web Storage: Storing and/or accessing data in the user's browser, such as with localStorage via JavaScript.
Device Fingerprinting: Compiling a unique(ish) identifier by reading the user's device characteristics (like browser plugins, hardware specs, screen resolution, installed fonts, etc.), typically used to track that ID across web pages or sites.

Not all data is the same

If your site accesses or stores user data for analytics, marketing, or personalization, you need explicit prior consent from the user, even if you never drop a single cookie.

But the law recognizes different categories of data, based on their purpose.

Data Type	Purpose	Example
Strictly Necessary	Required for core website functionality	Keeping you logged in as you move between web pages or remembering items in your shopping basket.
Analytics	Track website usage	Recording how often you visit the site, possibly with device and location characteristics.
Marketing	Show relevant ads	Displaying an ad for a product you recently viewed on a different site.
Personalization	Remember your settings	The site remembers and uses your language or currency settings each time you visit.

If your website only stores and accesses data on the user's machine for strictly necessary reasons—meaning to deliver the core service the user requested—you do not need a cookie consent banner.

Examples of data access and storage that generally do not need consent:

Session management (e.g., keeping a user logged in as they move around your website).
Security tokens (e.g., protecting the user from fraud during checkout).
Remembering what is in a shopping cart.
Saving the user’s preference regarding their consent to the privacy notice itself.

However, if you use products such as Google Analytics (even in cookieless mode), Facebook Pixels, or YouTube embeds, you are processing data beyond "strictly necessary." In these cases, you must first alert the user and obtain their consent.

What if my website is not in the EU?

The ePD applies based on the user's location, not the website. If you offer any services, process data, or allow sign-ups within the EU, you must comply, regardless of where your servers or your company are based.

Quick compliance checklist for 2025

To ensure your site is compliant with applicable data tracking requirements, follow these steps:

Audit your stack: Identify every script running on your site, including third-party plugins.
Block by default: Ensure all non-essential tracking (Analytics, Ads) is paused until the user clicks "Accept."
Categorize consent: Offer granular options (Analytics vs. Marketing, for example) rather than a single "Accept All" button.
Avoid "Dark Patterns": Do not use pre-ticked boxes. Acceptance by default does not constitute consent.
Enable easy withdrawal: Ensure users can revoke consent (a "Reject" or "Manage Settings" button) as easily as they gave it.

This might all change

In November of 2025, some insiders are reporting that the rules governing how websites confirm user consent may be changing.

"European Union is on a route to simplify the notorious rule that is annoying every EU citizen. Namely, the ever present "consent popups". You know them for sure as most people need to go through lots of clicks that are simply a waste of time."

The idea is that the web browser should record the user's consent (or rejection) and make that information available to each website.

In short

"Cookieless" is not a loophole. If the user is in the EU and you store or access data on their device for purposes that are not strictly necessary, you must get their consent; whether you use cookies or not.

photo credit: Jill Wellington

HTML Meta Tags to Improve Sharing of your Webpages (and SEO)

Michael Mathews — Fri, 07 Nov 2025 15:25:16 +0000

If the (example) metadata about your website was:

{
  "title": "The Ultimate Guide to Making Sourdough Bread",
  "description": "Learn the step-by-step process of creating a beautiful, crusty loaf of sourdough bread from scratch. We cover starters, folding, and baking.",
  "pageUrl": "https://your-site.com/blog/sourdough-guide",
  "imageUrl": "https://your-site.com/images/sourdough-guide-1200x630.jpg",
  "imageWidth": "1200",
  "imageHeight": "630",
  "imageAlt": "A golden-brown, freshly baked loaf of sourdough bread on a cutting board.",
  "type": "article",
  "siteName": "The Bread Kitchen",
  "twitterCardType": "summary_large_image",
  "twitterHandleSite": "@BreadKitchen",
  "twitterHandleAuthor": "@ChefJane"
}

The template you could use to generate the optimal HTML would be:

<head>
  <title><%= data.title %></title>

  <meta name="description" content="<%= data.description %>" />

  <meta property="og:title" content="<%= data.title %>" />
  <meta property="og:description" content="<%= data.description %>" />
  <meta property="og:type" content="<%= data.type %>" />
  <meta property="og:url" content="<%= data.pageUrl %>" />
  <meta property="og:site_name" content="<%= data.siteName %>" />
  <meta property="og:image" content="<%= data.imageUrl %>" />
  <meta property="og:image:width" content="<%= data.imageWidth %>" />
  <meta property="og:image:height" content="<%= data.imageHeight %>" />
  <meta property="og:image:alt" content="<%= data.imageAlt %>" />

  <meta name="twitter:card" content="<%= data.twitterCardType %>" />
  <meta name="twitter:site" content="<%= data.twitterHandleSite %>" />
  <meta name="twitter:creator" content="<%= data.twitterHandleAuthor %>" />
  <meta name="twitter:title" content="<%= data.title %>" />
  <meta name="twitter:description" content="<%= data.description %>" />
  <meta name="twitter:image" content="<%= data.imageUrl %>" />
  <meta name="twitter:image:alt" content="<%= data.imageAlt %>" />
<!-- other HEAD content here... -->
</head>

Let's break that down.

Standard SEO Tags

Tag	Purpose & How It's Used
`<title>`	Sets the title in the browser tab. It's also the main headline used by Google in search results listings.
`<meta name="description">`	This is the snippet of text shown below the title in Google search results. It doesn't affect social cards, but it's crucial for SEO.

Open Graph (OG) Tags (Used by Facebook, LinkedIn, Pinterest)

Tag	Purpose & How It's Used
`og:title`	The headline of your share card. This is what users see first. If missing, platforms might grab your page's `<title>`.
`og:description`	The summary text shown below the headline in the card. It's your "sales pitch" for the click.
`og:type`	The type of content you're sharing (e.g., `article`, `website`, `video.movie`). This tells the platform how to categorize it in their system.
`og:url`	The canonical (one-and-only official) URL for the page. All shares and "likes" for this page will be grouped under this single URL.
`og:image`	This is the URL for the image that will appear in the card.
`og:image:width`, `og:image:height`	Tells the platform the exact dimensions of your image. This helps them render the card faster and prevents the image from being cropped weirdly. (1200x630 is the standard).
`og:image:alt`	Provides an accessible text description of the image for users with screen readers.
`og:site_name`	Specifies the name of your overall website (e.g., "The Bread Kitchen"). It often appears as a small "via..." line on the card.

Twitter Card Tags (Used by X/Twitter)

Tag	Purpose & How It's Used
`twitter:card`	Defines the card type. `summary_large_image` is the most popular, featuring a big image. `summary` provides a small thumbnail.
`twitter:site`	The `@username` of your website's main Twitter account (e.g., `@BreadKitchen`). This gets linked in the card.
`twitter:creator`	The `@username` of the content author (e.g., `@ChefJane`). Great for giving credit to individual writers.
`twitter:title`	The headline for the Twitter card. Overrides `og:title` if present.
`twitter:description`	The summary text for the Twitter card. Overrides `og:description` and should be kept under about 200 characters.
`twitter:image`	The image for the Twitter card. Overrides `og:image`.
`twitter:image:alt`	An accessible text description of the image specifically for Twitter.

Creating Share Links

An example template is shown below. Replace the placeholders with URL-encoded values for your web page.

<div id="shareLinks">
  <a 
    href="https://twitter.com/intent/tweet?url=[ENCODED_URL]&text=[ENCODED_TITLE]&via=[ENCODED_VIA]"
    target="_blank" rel="noopener">
    Share on Twitter
  </a>

  <a 
    href="https://www.facebook.com/sharer/sharer.php?u=[ENCODED_URL]"
    target="_blank" rel="noopener">
    Share on Facebook
  </a>

  <a 
    href="https://www.linkedin.com/shareArticle?mini=true&url=[ENCODED_URL]&title=[ENCODED_TITLE]"
    target="_blank" rel="noopener">
    Share on LinkedIn
  </a>

  <a 
    href="mailto:?subject=[ENCODED_TITLE]&body=Check%20out%20this%20article:%20[ENCODED_URL]">
    Share via Email
  </a>
</div>

Use target="_blank" and rel="noopener" on your share link tags to open them in a new tab securely.

What We Mean When We Say "Native TypeScript Support"

Michael Mathews — Wed, 27 Aug 2025 14:30:40 +0000

If you’re using Node.js v23.6 or later, you probably know that you can now run TypeScript files directly, without having to apply tsc, Babel, or other separate transpilation steps first.

Some earlier versions of node could do the same when you used flags like --experimental-strip-types, but as of v23.6, the following will just work, no flags required:

node my-awesome-typescript-code.ts

At first glance, this appears to be Node.js gaining "native TypeScript support", and in a way, it has. However, that only means it can convert TypeScript into JavaScript on its own. It does not mean Node understands or enforces TypeScript types at runtime.

What Node Is Actually Doing

When you run a .ts file in Node 23.6+, here’s what happens:

Node removes TypeScript-specific syntax like : string, : number, interface, etc.
What remains is plain old JavaScript.
That JavaScript is what is actually executed.

So, for example, this TypeScript:

function greet(name: string): string {
  return "Hello, " + name;
}

Is effectively turned into this before it gets executed:

function greet(name        )         {
  return "Hello, " + name;
}

As a result, the runtime will never see the : string annotations in your original source code.

Static Types vs Runtime Behaviour

The core purpose of TypeScript is to add static type checking to the JavaScript developer experience. In other words, to help you and your tools (such as your IDE or the TypeScript compiler tsc) understand and enforce type intentions in your code before it runs. This feature never happens during execution.

This distinction matters because it’s easy to assume: “If Node can now run TypeScript, then TypeScript’s type checking must be happening inside Node.”

Nope.

TypeScript’s type checking is always compile-time only. It happens when you use tsc or your editor’s language server, and its purpose is to catch mistakes during development.

When the code is actually running, whether in Node.js or Deno, there are no type annotations and no type-checking.

For example:

function add(a: number, b: number): number {
  return a + b;
}

console.log(add("hello" as any, 3)); // compiles fine with "as any"

In Node 23.6+, this runs without complaint, accepting the string "hello" as an argument annotated with :number, and the output is:

hello3

A Little Nuance

Okay, while it's true that type annotations are effectively stripped out at compile time, it's also true that some TypeScript language features do make it into the runtime code. That's because TypeScript is more than just a type checker; it's also a transpiler that can convert some TypeScript-supported syntax into the equivalent JavaScript.

Take the enum, or enumerated type syntax as an example. In TypeScript, enums are supported; you can write:

enum Colour {
  Red,
  Green,
  Blue
}

console.log(Colour.Red);

But not in JavaScript, so the TypeScript compiler will emit some equivalent JavaScript like this:

"use strict";
var Colour;
(function (Colour) {
  Colour[Colour["Red"] = 0] = "Red";
  Colour[Colour["Green"] = 1] = "Green";
  Colour[Colour["Blue"] = 2] = "Blue";
})(Colour || (Colour = {}));

console.log(Colour.Red);

Notice that the JavaScript that gets executed now has an enum shim added to it. This shim will do nothing to enforce types at runtime, however. It’s just syntactic sugar sprinkled in to support the TypeScript enum in your source code.

What About Deno?

Deno has long supported .ts files directly, too, but the same story applies there: Deno removes type annotations before execution. It doesn’t enforce type safety at runtime either.

As of v23.6, Node.js is essentially catching up to Deno’s convenience feature of having TypeScript transpilation built in and enabled by default.

When You Do Need Runtime Type Safety

If you’re writing code that interacts with other systems outside of your code, the biggest type-safety risk probably isn’t your own functions calling each other — TypeScript already helps with that at dev time. The more likely risk is unvalidated input from sources that TypeScript can't see:

Responses from HTTP requests
JSON payloads
Database queries
Data returned from external API calls

In those cases, TypeScript won’t protect you; you’ll need runtime validation libraries like Zod.

For example, with Zod:

import { z } from "zod";

const UserSchema = z.object({
  id: z.string(),
  age: z.number(),
});

function handleUser(input: unknown) {
  // ↓ throws an error if input is not valid
  const validated = UserSchema.parse(input); 
  console.log(validated.id, validated.age);
}

Now, if an API client returns { id: 42 }, Zod's runtime check will throw instead of silently letting a number through where a string is expected.

The Bottom Line

Node 23.6+ saves you from having to run a separate transpiler, but it doesn’t change what TypeScript is or does; Once your code is running, it’s still just plain old JavaScript.

TypeScript is intended to be, and remains, a development-time safety net, not a runtime one.

What is the Impact of AI on Coding? What the METR Study Doesn't Show

Michael Mathews — Sun, 13 Jul 2025 11:24:21 +0000

There is something especially ironic about social media posts making blanket statements that are critical of people who make blanket statements about the usefulness of AI in coding. But we know that blanket statements are simplifications, and reality is never as cut-and-dried as a single eye-catching headline.

In the wake of the recently published METR study [Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR (Model Evaluation & Threat Research). https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf], the oversimplified statement that AI will always increase coding productivity is widely being countered by the oversimplified statement that AI cannot increase productivity. My position is that neither claim is true. While that does not make for a very click-baity headline, I'd just like to ask that people consider some of the critically relevant details included in the METR study itself before they make up their minds.

Applies to experienced and highly-skilled developers only

The study authors intentionally decided to "focus on highly skilled open-source developers" by "recruiting experienced engineers with years of expertise in the target repositories." They chose this focus, they said, because "there has been relatively less research in this setting." [METR, page 3]

But, as the study authors themselves caution, "our results are consistent with small greenfield projects or development in unfamiliar codebases seeing substantial speedup from AI assistance." [METR, page 12]

If you are a novice in the coding language or the project you are working on, then these study results do not apply to you.

Does not apply to tasks the authors considered "unrepresentative of most software development work"

The authors cite studys that found that for tasks that are, what I would call, fairly boilerplate, where the core effort is in actually remebering and physically typing the code, and where there is likely to be "a large amount of LLM training data," the use of AI showed a "65% increase in the rate of task requirements satisfied." [METR, page 3]

If the task you are working on is mostly about grinding out a lot of boilerplate code, then these study results do not apply to you.

What's the goal?

A significant problem I have in this whole discussion is the definition of the goal, what the study authors call "developer productivity." Time to passing unit tests, measured in billable minutes, is obviously quite important in a setting where the goal is to ship features as fast (and, in the case of commercial projects, as economically) as possible. In that case, if you had a few novice developers tasked with churning out a lot of boilerplate code, then "Yay! AI!"

On the other hand if your thinking were a little longer term, and you actually considered the skill growth of your developers to be as valuable as next week's profit margins, maybe you want your team to spend longer manually researching well-known coding patterns and typing them out by hand; this could lead to deeper understanding, better future recall, and improved longer term performance of the developer as a contributor to your enterprise.

This is just one example, but my point is that we could draw opposite conclusions based on whether we are taking a shorter or longer-term view of how we define success. Using or not using AI could be considered equally good, depending on your goals.

Was there bias?

A potential problem with the study was the author's stated goal of using "realistic" coding tasks to measure the effect of AI usage. To this end, they asked the developers themselves to select the tasks.

"Each developer provides a list of real issues in their repository to work on as part of this study. Issues are typically bug reports, feature requests, or work items used to coordinate development. They range from brief problem descriptions to detailed analyses and represent work ranging from minutes to hours."
-- METR, page 5

This, according to at least one of the (only 16) developers who participated in the study, influenced the types of tasks they selected, with the developer giving consideration to how the tasks might be affected by AI usage.

"There was a selection effect in which tasks I submitted to the study. (a) I didn't want to risk getting randomized to "no AI" on tasks that felt sufficiently important or daunting to do without AI assistence. [sic] (b) Neatly packaged and well-scoped tasks felt suitable for the study, large open-ended greenfield stuff felt harder to legibilize, [sic] so I didn't submit those tasks to study even though AI speed up might have been larger"
-- Bloom, R. (@ruben_bloom). (2025, July 11). X.com post. https://x.com/ruben_bloom/status/1943536052037390531

This may or may not have skewed the results to some degree—I genuinely don't know—but it seems odd that in a study that took pains to carefully randomise some things, the pool of tasks for developers to work from was not better protected from possible bias.

What's next?

I'm glad to see work like the METR study being published. Having data to refer to when evaluating claims about the impact of AI on productivity in real-world scenarios is a nice change. But this is a start. It would be useful to go further:

Does the outcome track based on the experience of the coder with the language and project?
Does the complexity/creativity of the task have an effect; is AI more or less useful with tasks that are straightforward versus those that are more novel or require creative thinking?
Is there a tradeoff where the developer benefits less from using AI, even if the work is completed more quickly? For example, when does the developer gain a lower level of understanding of the coding techniques provided by the AI?

Working with JavaScript Symbols

Michael Mathews — Fri, 30 May 2025 10:48:09 +0000

JavaScript Symbols represent a unique primitive data type introduced in ES6.

What Are JavaScript Symbols?

A JavaScript symbol is a primitive data type, like numbers, strings, and booleans. However, symbols have the following distinguishing characteristic: each value returned from Symbol() is guaranteed to be unique within that runtime context (e.g., the window, iframe, worker thread, or VM instance).

Useful properties of symbols include:

Are Unique: Every symbol is unique within its runtime context.
Are Non-Enumerable: By using a symbol for the name when adding a property to an object, you don't need to worry that the property will suddenly appear in any existing for in loops.
Won't be Automatically Type Converted: JavaScript will throw an Error if you accidentally use a symbol in a way where, for example, it would be automatically converted to a string.
Are Immutable: Like all JavaScript primitives, once a symbol value is created, that value cannot be changed.

When to Use Symbols

Symbols excel in several scenarios:

Unique Property Keys to Avoid Naming Conflicts

When building a library or working with legacy codebases, you might want to add new properties to existing objects without risking conflicts with existing (or future) properties added by users. Symbols, due to their inherent uniqueness, are perfect for this.

const tag = Symbol("tag");

function setTag(obj, tagName) {
  obj[tag] = tagName;
}

const user = { id: 1, name: "Alice" };
setTag(user, "admin");

console.log(user.id);   // 1
console.log(user[tag]); // admin

// if a regular property "tag" is added it won't clash
user.tag = "loggedIn";
console.log(user.tag); // loggedIn
console.log(user[tag]); // still "admin"

Creating Non-Enumerable Properties

Properties that use symbols for their keys do not appear in for...in loops or Object.keys() results by default. This allows you to "hide" properties, perhaps for adding internal metadata, that shouldn't be part of an object's public interface.

const idSymbol = Symbol("id");
const statusSymbol = Symbol("status");

let obj = {
  name: "Test Object",
  [idSymbol]: "xyz123",
  [statusSymbol]: "active"
};
obj.regularProperty = "I am enumerable";

for (const key in obj) {
  console.log(`  ${key}: ${obj[key]}`);
}
// name: Test Object
// regularProperty: I am enumerable

console.log(Object.keys(obj)); // [ 'name', 'regularProperty' ]

Unique Values for Constants

Since symbols are guaranteed to be unique in their runtime context, they are perfect for defining keys to be used as constants where the actual value doesn't matter as much as its uniqueness.

const LogLevel = {
  DEBUG: Symbol(),
  INFO:  Symbol(),
  WARN:  Symbol(),
  ERROR: Symbol()
};

function logMessage(message, level) {
  if (level === LogLevel.ERROR) {
    console.error(`Critical Error: ${message}`);
  } else if (level === LogLevel.INFO) {
    console.info(`Info: ${message}`);
  }
  // ... other log levels
}

logMessage("Something went wrong!", LogLevel.ERROR);
logMessage("Application started.", LogLevel.INFO);

Creating Symbols

Creating symbols is straightforward using the global Symbol() function, optionally with a description for better debugging. The description is particularly helpful as it appears when logging symbols.

const mySymbol = Symbol("This is a description");
console.log(mySymbol); // Symbol(This is a description)

Using Symbols as Object Property Keys

Just as when using any non-literal string value as a key for an object property, when using symbols as keys, you must use bracket notation. Dot notation, object.propertyName, doesn't work for symbol keys because property names accessed via dot notation are treated as literal strings.

const nameSymbol = Symbol("name");
const person = {
  [nameSymbol]: "Alice", // Using bracket notation to define the property
  age: 30
};

// Accessing the property using the symbol
console.log(person[nameSymbol]); // "Alice"

// Dynamically adding a property with a symbol key
const emailSymbol = Symbol("email");
person[emailSymbol] = "alice@example.com";
console.log(person[emailSymbol]); // "alice@example.com"

Converting Symbols to Strings

Unlike other value types in JavaScript, a symbol cannot be automatically converted to another type. For example:

const arr = ["world"];
const sym = Symbol("world");

console.log("hello " + arr); // hello world (arr was converted to a string)
console.log("hello " + sym); // TypeError: Cannot convert a Symbol value to a string

Converting symbols to a string requires explicit use of the toString() method or the String() constructor. The description property (available in ES2019+) directly returns the description string provided during creation.

const sym = Symbol("hello");

console.log(sym.toString());  // "Symbol(hello)"
console.log(String(sym));     // "Symbol(hello)"
console.log(sym.description); // "hello"

This requirement for explicit conversion is one of the symbol's strengths; it prevents a whole class of bugs from arising from values being unintentionally converted to a different type in operations like concatenation.

Hidden Properties

A useful feature of JavaScript symbols is their ability to create object properties that remain hidden from the usual object inspection methods. When you use symbols as property keys, for example, these properties don't appear in:

Object.keys()
Object.getOwnPropertyNames()
for...in
JSON.stringify()

This hidden nature allows developers to safely use symbols to attach metadata, internal state, or utility methods to objects without polluting the regular property namespace.

const myObject = {
  name: "Public Name",
  value: 42,
  [Symbol("id")]: "12345",
  [Symbol("status")]: "inactive"
};

console.log(Object.keys(myObject)); // [ 'name', 'value' ]

That said, this feature is more about preventing unintentional access; symbols don't create private properties in the true sense of the word. Anyone can explicitly interrogate an object for property symbols if they really wish.

const myObject = {
  name: "Public Name",
  value: 42,
  [Symbol("id")]: "12345",
  [Symbol("status")]: "inactive"
};

const symbolKeys = Object.getOwnPropertySymbols(myObject);

symbolKeys.map(symKey => {
  console.log(`${symKey.toString()}: ${myObject[symKey]}`);
});
// Symbol(id): 12345
// Symbol(status): inactive

Global Symbol Registry

The global symbol registry provides a way to share symbols across different parts of your application. The global registry allows you to create and retrieve symbols using string keys, granting access to the same key again when it is needed in multiple locations.

`Symbol.for()` and `Symbol.keyFor()`

While Symbol() creates a unique symbol every time, Symbol.for(keyString) searches for an existing symbol with the given keyString in the global symbol registry. If found, it returns that symbol; otherwise, it creates a new symbol with keyString, stores it in the global registry, and returns it.

Symbol.keyFor(symbol) does the reverse: it retrieves the string key associated with a global symbol from the registry.

// Creating or retrieving a global symbol
const globalSym1 = Symbol.for("app.uid");
const globalSym2 = Symbol.for("app.uid");
console.log(globalSym1 === globalSym2); // true

const newSym = Symbol("app.uid");   // not `for` so a brand new symbol
console.log(globalSym1 === newSym); // false

console.log(Symbol.keyFor(globalSym1)); // "app.uid"
console.log(Symbol.keyFor(newSym));     // undefined, not in the registry

This global functionality is useful when you need consistent symbol references across different modules or even different execution contexts (e.g., iframes).

Well-Known Symbols

Well-known symbols are predefined symbols built into JavaScript that allow developers to customize how objects interact with core language features and operations. These symbols act as hooks into JavaScript's internal mechanisms, enabling you to define custom behavior for operations like iteration, type conversion, and instance checking.

JavaScript includes a set of predefined well-known symbols. These are static properties of the Symbol object (e.g., Symbol.iterator, Symbol.toPrimitive, Symbol.hasInstance). They allow developers to customize how objects behave with built-in JavaScript operations and methods.

For example, Symbol.iterator specifies the default iterator for an object, making it compatible with for...of loops. Symbol.hasInstance allows customization of the instanceof operator.

Here's an example of how to customize the instanceof operator with Symbol.hasInstance:

/** An array of strings. */
class List {
  constructor(...items) {
    if (!List.#isListish(items)) {
      throw new TypeError('List must be initialized with an array of strings');
    }
    return [...items];
  }

  static #isListish(obj) {
    // duck typing to decide if obj is a List
    return Array.isArray(obj) && obj.every(i => typeof i === 'string');
  }

  // implement the instanceof protocol
  static [Symbol.hasInstance](obj) {
    return List.#isListish(obj);
  }
}

const arr1 = new List("red", "blue");
const arr2 = ["one", "two"];
const arr3 = [1, 2, 3];
const obj = {};

console.log(arr1 instanceof List); // true
console.log(arr2 instanceof List); // true (array of strings)
console.log(arr3 instanceof List); // false (array items are not strings)
console.log(obj instanceof List);  // false (not an array)

More Use Cases and Patterns

Symbols enable sophisticated programming patterns beyond basic property hiding.

Implementing Custom Iterators with `Symbol.iterator`

The Symbol.iterator is a well-known symbol that allows you to define custom iteration behavior for your objects, making them compatible with for...of loops and the spread syntax (...).

class Range {
  constructor(start, end) {
    this.start = start;
    this.end = end;
  }

  // implement the iterator protocol
  [Symbol.iterator]() {
    let current = this.start;
    const end = this.end;

    return {
      next: () => {
        if (current <= end) {
          return { value: current++, done: false };
        } else {
          return { value: undefined, done: true };
        }
      },
    };
  }
}

const myRange = new Range(1, 4);

// using for...of
for (const num of myRange) {
  console.log(num); // 1, 2, 3, 4 (on separate lines)
}

// using spread syntax
const numbersArray = [...myRange];
console.log(numbersArray); // [ 1, 2, 3, 4 ]

Metaprogramming

Symbols are useful in metaprogramming scenarios, particularly with Proxies or decorators. They provide stable, unique identifiers for storing metadata or internal logic that won't clash with regular object properties. This separation is crucial for frameworks or libraries that add functionality to user objects without visible side effects.

Registries and Caching

Symbols can create unique, hidden keys for caching mechanisms or registry patterns. By using symbols as keys (e.g., in WeakMaps or as property names for cache storage), developers can create data structures isolated from user code but accessible to the implementing library. This offers stronger encapsulation than convention-based private property naming (like _cacheKey).

JavaScript Variable Scope by Example

Michael Mathews — Thu, 29 May 2025 21:34:57 +0000

Variable scope is a fundamental concept that must be mastered in JavaScript. Knowing how var, let, and const behave, and how hoisting and closure affect access to variable values will allow you to write more fluent and predictable code.

What Is Scope?

In JavaScript, scope refers to the current context of execution in which values and expressions are "visible" or accessible.

In JavaScript, there are two main types of scope:

Global scope: Variables declared at the "top-level," outside any function or block.
Local scope: Variables declared inside a function or block.

JavaScript also has the concept of lexical scoping, which means that a function's access to variables is determined by where it is written in the code, not where it's called from. Inner functions can access variables from their outer (enclosing) functions, creating a nested "scope chain."

`var`, `let`, and `const`

JavaScript provides three keywords for declaring variables: var, let, and const. Each has distinct scoping behaviors.

`var`: Function Scope and Hoisting

var is function-scoped, which means it can be accessed anywhere within the function in which it is declared (even before its value is initialized). Or if it is used outside of a function, it is global. It is also hoisted, meaning the code acts as if the declaration were moved to the top of its scope at runtime (but not the assignment).

function f() {
  console.log(x); // undefined (not ReferenceError)
  var x = 10;
  console.log(x); // 10
}

f();
console.log(x); // ReferenceError: x is not defined

In the above code, the declaration of x is hoisted to the top of the function, so the first console.log doesn’t throw an error, even though the value assignment hasn’t happened yet. Outside of the function, x does not exist, so it will throw an error.

`let` and `const`: Block Scope and Temporal Dead Zone

let and const are block-scoped, meaning they are only accessible within the nearest set of {} braces.

Unlike var, which hoists the variable declaration to the top of its scope, const and let follow a model called The Temporal Dead Zone (TDZ). This refers to the scope between the start of a block and the point where the variable is declared. During this period, the variable exists but cannot be accessed; any attempt to do so will throw a ReferenceError

function demonstrateTdz() {
  console.log(x); // undefined
  console.log(y); // ReferenceError: Cannot access 'y' before initialization
  var x = 1;
  let y = 2;

  console.log(x, y); // 1 2
}

demonstrateTdz();

Using let or const helps avoid confusion caused by hoisting, making code more predictable.

Block Scope Example

{
  let a = 1;
  {
    const b = a + 1; // a is accessible here
    var c = b + 1;
  }
}

console.log(typeof a); // undefined
console.log(typeof b); // undefined
console.log(c);        // 3

In this example, a and b are block-scoped, so they are not available outside their enclosing block. a is available to the inner scope, however. c is declared with var, so it's scoped to the function it is declared in or, as in this case, the global scope.

Closures

A closure is a function scope that maintains access to the variables available in whatever scope it was defined in, regardless of where it is called from.

function makeCounter() {
  let count = 0;

  return function () {
    count++; // from the outer scope
    return count;
  };
}

const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2

Closures are fundamental in JavaScript and commonly used in web development, particularly in event handlers and asynchronous code.

Summary

var is function-scoped or globally scoped and hoisted.
let and const are block-scoped and do not behave as if hoisted (TDZ).
Use const or let to limit the scope of your variables and avoid hoisting.
Scope and closures are key to many JavaScript patterns, including modules and callbacks.

Understanding Primitives in JavaScript

Michael Mathews — Thu, 29 May 2025 15:48:11 +0000

In JavaScript, every value is either a primitive or an object.

Primitives are immutable, passed by value, and cannot have properties.
Objects are everything else, including arrays, functions, dates, and regular objects. These are mutable and passed by reference. Objects can have properties and methods.

Meet the primitives

The latest ECMAScript standard (ECMAScript 2024 / ES15) defines seven primitive types.

Undefined

A variable that has been declared but not assigned a value has the undefined value:

let x;
console.log(x); // undefined

Null

The null literal signifies the intentional absence of any value:

let reason = null;   // there is no reason
console.log(reason); // null

Boolean

Two Boolean literals represent logical truth values:

true
false

Number

All numeric values (including integers, floats, NaN, and Infinity) are of the Number type:

let a = 42;       // integer
let b = 3.14;     // float
let c = NaN;      // yes, the "not a number" value is a number
let d = Infinity; // and beyond!

String

A sequence of characters, such as some words or text:

let greeting = "Hello";
let name = 'World';
let message = `Hi, ${name}!`;

BigInt

Represents integers of arbitrary length, created by appending n to the end of an integer literal:

let big = 1234567890123456789012345678901234567890n;

Symbol

A unique (within the runtime environment) value that can be used as object property keys:

let sym = Symbol("id");

What's your type?

The typeof operator returns a string indicating the operand type. There are seven possible return values for primitive types.

console.log(typeof undefined);         // undefined
console.log(typeof true);              // boolean
console.log(typeof 42);                // number
console.log(typeof 9007199254740991n); // bigint
console.log(typeof "hello");           // string
console.log(typeof Symbol());          // symbol

// and then there's null... read more below
console.log(typeof null);              // object?

`null` is a special case

I want to call attention to a common point of confusion in JavaScript: the null value. However, it is not an object and has no object wrapper. However, it blatantly lies and claims to be an object when you use the typeof operator on it.

let nope = null;
console.log(typeof nope);     // object (no, it's not)

console.log(nope.toString()); // TypeError: Cannot read properties of null (reading 'toString')
nope.x = 1;                   // TypeError: Cannot set properties of null (setting 'x')

Brendan Eich, the Creator of JavaScript, admitted that typeof null === "object" is a bug, but fixing it would break a lot of code on the web. So, we must always work around this bug.

// randomly assign either an object or null
const value = Math.random() < 0.5 ? {} : null;

// don't forget to check for null
if (typeof value === "object" && value !== null) {
  console.log("The value is a (real) object.");
}

Dressing primitives up like objects

Primitive values are not objects. They are immutable and cannot have methods or properties. You might be surprised by this statement, after all, it's pretty standard to see code that appears to call methods on and get/set properties on primitive values.

console.log("hello".length);         // 5
console.log("hello".toUpperCase());  // HELLO
console.log(10.0.toFixed(2));        // 10.00
console.log(true.toString());        // true

What's happening here? The primitive types in the preceding example each have a corresponding object wrapper they can climb into whenever they need to do object-like things. For example, you can wrap a string primitive in a String object by calling new String("hello"). Think of the resulting object as a box with the primitive inside. You can always get the primitive value back by calling valueOf on the object.

JavaScript performs automatic "boxing" for you by temporarily wrapping any String, Number, or Boolean values in an object whenever you try to access properties or methods. For example, "hello".toUpperCase() works because JavaScript creates a String object behind the scenes before calling its toUpperCase method.

Wrapping primitives

JavaScript doesn't always wrap primitives in Objects for you. For example, undefined and null can't be wrapped.

undefined.toString(); // TypeError: Cannot read properties of undefined (reading 'toString')
null.toString();      // TypeError: Cannot read properties of null (reading 'toString')

If you try to force them into object boxes explicitly, their values disappear.

Object(null);      // returns an empty object {}
Object(undefined); // returns an empty object {}

Strings, Numbers, and Booleans have dedicated object wrappers you can call yourself if you wish. In practice, there are very few reasons for doing this, but you might find some APIs that require objects when all you have are primitives, for example, when creating an entry in a WeakMap that requires an object for the key.

const s = new String("hello");

console.log(typeof s);            // "object"
console.log(s instanceof String); // true
console.log(s.valueOf());         // "hello" (gets the primitive value)
console.log(s);                   // calls valueOf for you

Similarly, you can explicitly wrap numbers and booleans.

const n = new Number(42);
const b = new Boolean(true);

The last two primitives don't have their own dedicated object wrapper but can be objectified using the Object() function if you need to.

const big = Object(123n);
console.log(typeof big);            // "object"
console.log(big instanceof BigInt); // true
console.log(big.valueOf());         // "123n" (gets the primitive value)
console.log(big);                   // [BigInt: 123n] (calls toString)

const sym = Object(Symbol("key"));
console.log(sym);                   // [Symbol: Symbol(key)]

Counting Stars with JavaScript: Using the BigInt Type

Michael Mathews — Tue, 27 May 2025 16:21:05 +0000

JavaScript's native Number type is a 64-bit floating-point value (IEEE 754 double-precision). While this gives you a massive range, JavaScript integer Numbers are still limited. In JavaScript, integer values are only precise up to 2⁵³ - 1.

The number 2⁵³ represents the result you get when you multiply the number 2 by itself, 53 times in a row. So the maximum safe integer number is 2**53 - 1 or 9,007,199,254,740,991, about nine quadrillion, give or take a few trillion.

But don't bother trying to remembering that number; JavaScript has helpfully given it an easy-to-recall name: Number.MAX_SAFE_INTEGER.

console.log(Number.MAX_SAFE_INTEGER); // 9007199254740991

As the name implies, once you start working with integer Numbers larger than Number.MAX_SAFE_INTEGER, you can't safely assume the accuracy of any result.

There is also a corresponding Number.MIN_SAFE_INTEGER value. It represents JavaScript's smallest safe integer value, or -(2⁵³ - 1).

console.log(Number.MIN_SAFE_INTEGER); // -9007199254740991

By "safe," we mean:

Accurately represented: A safe integer won't get rounded to a different value due to insufficient precision.
Correctly compared: Comparisons between safe integers will yield mathematically correct results.

To illustrate, let's try something with a couple of unsafe values and see how it can go mathematically wrong:

const x = Number.MAX_SAFE_INTEGER;

console.log(x + 1 === x + 2); // true! (but not correct)

What's the point?

You might think, I'll just stick to numbers smaller than nine quadrillion -- it's a plenty big-enough number after all. That's true. In fact, if you ever tried to count up to 9 quadrillion, even at one number per second and without any breaks, it would take you about 285 million years!

While working with such massive numbers is not typical, it wouldn't be inconceivable. Here are a few examples of real integer values where Number.MAX_SAFE_INTEGER isn't big enough.

Genes in the human body

The estimated number of gene copies in an adult human body (spread across our 30 to 40 trillion cells) is about 2 × 10¹⁸ (2 quintillion). MAX_SAFE_INTEGER is 222 times too small to represent the number of gene copies in the human body.

Milliseconds since the Big Bang

The universe's age is about 13.8 billion years, or about 4.4 × 10²⁰ milliseconds (440 quintillion ms). MAX_SAFE_INTEGER is about 50,000 times too small to represent the number of milliseconds since the dawn of time.

Stars in the observable universe

The estimated number of stars in the observable universe is between 10²² and 10²⁴ (1 septillion). MAX_SAFE_INTEGER is about 100 million times too small to represent the number of stars in the observable universe.

So while Number.MAX_SAFE_INTEGER is big, it's not big enough for some values in astronomy, geography, genetics, cryptography, or large financial systems. That's when we reach for the BigInt primitive type. BigInt can handle values way beyond Numbers's 64-bit limit.

Meet `BigInt`

BigInt is a primitive type introduced in ES2020 that can represent integers with arbitrary precision. That means you can work with much larger integer values. There is no upper maximum specified for BigInt; the implementation of the JavaScript engine you use and the available memory on your machine are the only practical limits.

A BigInt value is created by appending the letter n to the end of an integer literal or calling the BigInt() function and giving it an integer or string value.

Here's how it works:

const x = BigInt(Number.MAX_SAFE_INTEGER);
console.log(x + 1n === x + 2n); // false, now works correctly

Key characteristics

Literal syntax: Append n to create a BigInt literal (123n).
Distinct Type: It's one of the built-in primitive types in JavaScript (typeof 1n returns "bigint").
No decimals: BigInt can only represent whole numbers (integers) (BigInt(1.1) throws a RangeError).

Considerations

There are several limitations you must keep in mind when working with BigInt values.

JSON serialization

BigInt values aren't supported in JSON.

JSON.stringify({ value: 123n }); // TypeError: Do not know how to serialize a BigInt

Integers only

As the "Int" in the name implies, BigInt is for integers (whole numbers) only. If you forget about this limitation you might be surprised.

console.log(10n / 1n); // 10n
console.log(10n / 3n); // 3n (but not correct)

Don't mix

BigInt values cannot be combined with regular Number values (1n + 1 is a TypeError, but 1n + 1n is okay).

Watch your speed

Expect code that uses BigInt values to be at least slightly slower than the same code using ordinary Numbers. This is because floating-point arithmetic (used by Number) is implemented directly in the computer hardware, while arbitrary-precision arithmetic, used by BigInt, is implemented in software. Your computer hardware is far faster than any software!

What about TypeScript?

The bigint type is fully supported in TypeScript, just like any other primitive type. However, you must set the "target" property inside the "compilerOptions" object in your tsconfig.json file, to "ES2020" or later.

let x: bigint;

x = 1234567890123456789012345678901234567890n; // OK
x = BigInt("1234567890123456789012345678901234567890"); // OK

x = 12345; // ERROR Type 'number' is not assignable to type 'bigint'.

Fun fact

Reading long numerical values can be confusing for humans, if not for computers. By convention, we tend to add digit grouping characters to make them more readable. For example, a comma separates the thousands in long numbers in English-speaking countries, like "1,000,000". Other countries use different symbols; you might see that written as "1’000’000" in Switzerland and Liechtenstein, "1.000.000" in other European countries, or even "1 000 000" in some scientific settings.

JavaScript supports using an underscore character to group digits. So while your computer has no problem understanding 1000000, you can write 1_000_000 instead if it's easier to read.

Using Tuples in TypeScript

Michael Mathews — Tue, 27 May 2025 11:39:13 +0000

In TypeScript, a tuple allows you to describe a structured array, where the position of each element is meaningful and dictates what type each is expected to be.

For example, you might use a tuple to store the data associated with a User type. You could declare this type mandating that the first value in a User tuple must be a number (representing the user's id), and the second a string (representing their displayName).

// Declaring a User type consisting of an array with
// a number at `[0]` followed by a string at `[1]`
type User = [number, string];

const Alice: User = [123, 'Alice']; // OK
const Bob: User = ['Bob']; // ERROR Type 'string' is not assignable to type 'number'.

try in playground

You could make this more explicit by using named tuple elements in your type declaration. While the names make no functional difference, they will give you better hints in your IDE when you refer to an element in a tuple. For example, with named tuple elements, TypeScript can tell you that Alice[1] refers to the displayName.

type User = [id: number, displayName: string];

const Alice: User = [123, 'Alice']; // OK
console.log(Alice[1]); // (property) 1: string (displayName)

try in playground

Why Use Tuples?

You might wonder why anyone would use an array to hold structured data like this; wouldn't an object be a more natural choice?

const Alice = { id: 123, displayName: 'Alice' };

While objects with explicit keys and values are generally considered more readable, there are legitimate use cases for using structured arrays instead. For example, if user data were read from a database or file, working with whatever format it was returned in might be more efficient rather than converting it to an object.

Tuples are particularly useful for representing a small set of related, ordered values.

Coordinates: [latitude: number, longitude: number]
RGB color values: [red: number, green: number, blue: number]
API responses: [status: number, message: string]

Example Uses of Tuples in TypeScript:

Named Tuple Elements

type User = [id: number, displayName: string];

let user: User = [123, "Alice"]; // OK

console.log(user[0]); // (property) 0: number (id)
console.log(user[1]); // (property) 1: string (displayName)

user = ["Alice", 123]; // ERROR Type 'string' is not assignable to type 'number'.
user = [456, "Bob", true]; // ERROR Type '[number, string, boolean]' is not assignable to type 'User'. Source has 3 element(s) but target allows only 2

try in playground

Optional Tuple Elements

You can make elements in a tuple optional by appending a ? to their type. Optional elements must come after any required elements.

type Person = [firstName: string, lastName: string, age?: number];

const person1: Person = ["John", "Doe"]; // OK
const person2: Person = ["Jane", "Doe", 42]; // OK

const person3: Person = ["Jack", 12]; // ERROR Type 'number' is not assignable to type 'string'.

try in playground

Rest Elements in Tuple Types

Rest elements allow you to define a tuple with some fixed elements at the beginning, followed by an unknown number of elements of a specific type.

type LogEntry = [
  timestamp: number,
  level: 'INFO' | 'WARN' | 'ERROR',
  ...messages: string[], // NOTE Can be zero or more messages.
];

const entry1: LogEntry = [Date.now(), 'INFO', 'User logged in'];
const entry2: LogEntry = [
  Date.now(),
  'ERROR',
  'Failed to connect to database',
  'Network error',
  'Retry attempts: 3',
];

try in playground

Readonly Tuples

You can make a tuple immutable using the readonly modifier. This prevents modification to the tuple's elements (e.g., push, pop, direct assignment to an index).

type Point = readonly [x: number, y: number];

let p: Point = [0, 0];

p[0] = 1; // ERROR Cannot assign to '0' because it is a read-only property.
p.push(5); // ERROR Property 'push' does not exist on type 'Point'.

try in playground

Manage Multiple Versions of PHP with Homebrew

Michael Mathews — Sat, 15 Oct 2022 22:09:12 +0000

Using Homebrew is a handy way to install multiple versions of PHP on MacOS. For example, to have both php 7.4 and 8.0 installed, use the brew install command.

First install the 7.4 version, like so:

% brew install php@7.4

The syntax for specifying a specific version of a package with Homebrew is brew install <packageName>@<version>. In this case the package name is php and the version is 7.4 (defaulting to 7.4.32 as of this writing). If you leave off the @<version> part entirely, Homebrew will install whatever the latest version available is (8.1 as of this writing).

To check that version 7.4 of php is correctly installed:

% /opt/homebrew/opt/php@7.4/bin/php -v  
  PHP 7.4.32 (cli) (built: Sep 29 2022 10:45:51) ( NTS )
  Copyright (c) The PHP Group
  Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.32, Copyright (c), by Zend Technologies

Ideally we would like to refer to /opt/homebrew/opt/php@7.4/bin/php simply as php on our command line. This requires another step:

% brew link --force --overwrite php@7.4
  Linking /opt/homebrew/Cellar/php@7.4/7.4.32... 812 symlinks created.

  If you need to have this software first in your PATH instead consider running:
  echo 'export PATH="/opt/homebrew/opt/php@7.4/bin:$PATH"' >> ~/.zshrc
  echo 'export PATH="/opt/homebrew/opt/php@7.4/sbin:$PATH"' >> ~/.zshrc

As a result of running brew link we can now find the linked version of php at this path: /opt/homebrew/bin/php.

% ls -l /opt/homebrew/bin/php
  lrwxr-xr-x  1 myuser  admin  32 15 Oct 18:34 /opt/homebrew/bin/php -> ../Cellar/php@7.4/7.4.32/bin/php
% /opt/homebrew/bin/php -v
  PHP 7.4.32 (cli) (built: Sep 29 2022 10:45:51) ( NTS )
  Copyright (c) The PHP Group
  Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.32, Copyright (c), by Zend Technologies

The output of running brew link has a suggestion that we append two lines to the end of our ~/.zshrc file to tell our terminal that when we refer to php it should look for it first in the /opt/homebrew/opt/php@7.4/bin folder. You can do this but every time you brew link to a different version of php you will have to edit those lines. Instead I will take a slightly modified approach:

% echo 'export PATH="/opt/homebrew/sbin:/opt/homebrew/bin:$PATH"' >> ~/.zshrc
% source ~/.zshrc

Now our terminal will find the linked version of php at /opt/homebrew/bin first whenever we refer to php.

% which php    
  /opt/homebrew/bin/php
% php -v
  PHP 7.4.32 (cli) (built: Sep 29 2022 10:45:51) ( NTS )
  Copyright (c) The PHP Group
  Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.32, Copyright (c), by Zend Technologies

Now that we have php version 7.4 installed we can continue by installing php version 8.0 too.

% brew install php@8.0

Now we tell brew to link to the new version of php:

% brew link --force --overwrite php@8.0
  Unlinking /opt/homebrew/Cellar/php@7.4/7.4.32... 328 symlinks removed.
  Linking /opt/homebrew/Cellar/php@8.0/8.0.24... 232 symlinks created.

In the output from this command we again see the suggestion to run two commands containing the command export PATH... but due to the steps we took above, this won't be necessary.

% which php    
  /opt/homebrew/bin/php
% php -v
  PHP 8.0.24 (cli) (built: Sep 30 2022 08:39:20) ( NTS )
  Copyright (c) The PHP Group
  Zend Engine v4.0.24, Copyright (c) Zend Technologies
    with Xdebug v3.1.5, Copyright (c) 2002-2022, by Derick Rethans
    with Zend OPcache v8.0.24, Copyright (c), by Zend Technologies

Now we can switch from versions of 7.4 to 8.0 by relinking from one to the other: brew link --force --overwrite php@7.4 or brew link --force --overwrite php@8.0 for example.

If you're not sure what versions are available to link to, try this command:

% brew ls --versions | grep '^php[ @]'
  php@7.4 7.4.32
  php@8.0 8.0.24

Finally, below is the source code of a more full featured script that I call phpswitch. This script can be set to be executable and then run from the terminal like phpswitch 8.0 or phpswitch 7.4.

#!/bin/bash

if [ $# -ne 1 ]; then
    echo 1>&2 "USAGE: $0 <phpVersion>"
    exit 2
fi

INSTALLED_VERSIONS=`find /opt/homebrew/opt | grep 'php@' | sed 's/\/opt\/homebrew\/opt\/php@//'`

if [[ ! -f /opt/homebrew/opt/php@${1}/bin/php ]]; then
    echo 1>&2 "/opt/homebrew/opt/php@${1}/bin/php was not found"
    printf 'valid options:\n%s\n' "${INSTALLED_VERSIONS[*]}"
    exit 2
fi

for VERSION in ${INSTALLED_VERSIONS[*]}; do
    brew unlink php@$VERSION > /dev/null 2>&1
    brew services stop php@$VERSION > /dev/null 2>&1
done

brew link --force --overwrite php@$1 > /dev/null 2>&1
brew services start php@$1 > /dev/null 2>&1

DEV Community: Michael Mathews

Clickable Card Patterns and Anti-Patterns

The Problem

Use the Stretched Link Pattern

1. Semantic HTML Structure

2. CSS Implementation: Stacking Context Management

Conclusion

Who Needs CSP?

What is Content Security Policy (CSP)?

The Security Problem CSP Solves

XSS Examples

CSP Benefits and Trade-offs

Do You Need CSP for Your Website

Likely yes if your website:

Maybe not if your website:

Getting Started

1. Start Simply

2. Use Report-Only Mode First

3. Gradually Add More Complex Restrictions

4. Focus on the Biggest Risks

A Basic Starter CSP

What this does:

Handling Inline CSS/JS

Option 1: Using Hashes (Best for Static Sites)

How to generate hashes

Option 2: Using Nonces (Dynamic Sites)

More Examples

Basic Protection

Add Some External Resources and Inline Resources

Move to Stricter Protection

Development vs Production

Example: Adding CSP to an AWS CloudFront Response Headers Policy

Step 1: Create a Response Headers Policy

Step 2: Attach Policy to Specific Cache Behaviors

Is CSP a Silver Bullet to Prevent All XSS?

Summary

Do You Need A Cookie Notice If You Don't Use Cookies?

It’s not (only) about cookies

Storing or accessing information in the user's terminal equipment

Not all data is the same

What if my website is not in the EU?

Quick compliance checklist for 2025

This might all change

In short

HTML Meta Tags to Improve Sharing of your Webpages (and SEO)

Standard SEO Tags

Open Graph (OG) Tags (Used by Facebook, LinkedIn, Pinterest)

Twitter Card Tags (Used by X/Twitter)

Creating Share Links

What We Mean When We Say "Native TypeScript Support"

What Node Is Actually Doing

Static Types vs Runtime Behaviour

A Little Nuance

What About Deno?

When You Do Need Runtime Type Safety

The Bottom Line

What is the Impact of AI on Coding? What the METR Study Doesn't Show

Applies to experienced and highly-skilled developers only

Does not apply to tasks the authors considered "unrepresentative of most software development work"

What's the goal?

Was there bias?

What's next?

Working with JavaScript Symbols

What Are JavaScript Symbols?

When to Use Symbols

Unique Property Keys to Avoid Naming Conflicts

Creating Non-Enumerable Properties

Unique Values for Constants

Creating Symbols

Hidden Properties

Global Symbol Registry

Symbol.for() and Symbol.keyFor()

Well-Known Symbols

More Use Cases and Patterns

Implementing Custom Iterators with Symbol.iterator

Metaprogramming

Registries and Caching

JavaScript Variable Scope by Example

What Is Scope?

var, let, and const

`Symbol.for()` and `Symbol.keyFor()`

Implementing Custom Iterators with `Symbol.iterator`

`var`, `let`, and `const`

`var`: Function Scope and Hoisting

`let` and `const`: Block Scope and Temporal Dead Zone

`null` is a special case

Meet `BigInt`