DEV Community: MO Slah

Using `userAgent` in Next.js App Router — Device, Browser, OS & Bot Detection

MO Slah — Fri, 03 Apr 2026 21:29:21 +0000

Server-side user-agent parsing without the manual string gymnastics.

Ever needed to redirect mobile users or block bots before the page even renders? Next.js has a built-in helper for exactly that: userAgent. Instead of manually parsing raw header strings, you get a clean structured object with everything you need, right inside Middleware or a Route Handler.

What is userAgent?

userAgent is a helper exported from next/server. Pass it the incoming NextRequest and it returns a parsed object with structured client data — no regex required.

import { userAgent } from 'next/server'

Basic Usage

Here's a minimal example inside middleware:

import { NextRequest, NextResponse, userAgent } from 'next/server'

export function middleware(request: NextRequest) {
  const { device, browser, os, isBot } = userAgent(request)

  console.log(device)   // { type: 'mobile', model: 'iPhone', vendor: 'Apple' }
  console.log(browser)  // { name: 'Safari', version: '17.0' }
  console.log(os)       // { name: 'iOS', version: '17.0' }
  console.log(isBot)    // false

  return NextResponse.next()

What You Get

device

Attribute	Sample Values
`type`	mobile, tablet, console, smarttv
`model`	iPhone, Galaxy S21
`vendor`	Apple, Samsung, Google

if (device.category === 'mobile') {
  return NextResponse.redirect(new URL('/m', request.url))
}

browser

Attribute	Sample Values
`name`	Chrome, Safari, Firefox
`version`	Major version string

if (browser.identifier === 'Safari') {
  // implement fixes or headers specific to Safari
}

Attribute	Sample Values
`name`	iOS, Android, Windows, macOS
`version`	OS version string

if (os.platform === 'iOS') {
  // manage behaviors specific to iOS
}

isBot

A boolean. Returns true if the request originates from a recognized crawler. Useful for delivering streamlined, SEO-optimized responses or skipping analytics pings entirely.

if (isAutomated) {
  // bypass heavy JS hydration, deliver static HTML only
  return NextResponse.rewrite(new URL('/seo-version', request.url))
}

cpu

Reveals the CPU architecture — useful when serving distinct WASM bundles for arm versus amd64 devices.

const { cpu } = userAgent(req)
console.log(cpu.arch) // 'arm', 'amd64', etc.

Practical Everyday Applications

Send mobile users to /m before the layout loads
Serve simpler static HTML to bots to improve SEO performance
Apply server-side response headers tailored to specific browsers
Skip analytics pings for crawlers
Deliver CPU architecture-specific WASM bundles

A useful starting point — reroute mobile users before the layout even loads:

export function middleware(req: NextRequest) {
  const { device } = userAgent(req)

  if (device.category === 'mobile') {
    return NextResponse.redirect(new URL('/m', req.url))
  }

  return NextResponse.next()
}

Key Things to Remember

Server-exclusive. You can use userAgent in Middleware and Route Handlers — not in Client Components. On the client side, use navigator.userAgent instead.
It makes your route dynamic. Using userAgent opts your route out of full static generation. Next.js won't cache it at build time since the response depends on the incoming request. Keep that in mind for performance-sensitive pages.
Not entirely reliable. The user-agent string comes from the client and can be spoofed or modified. Use it for progressive enhancement decisions, not hard security gating.

Feature	`userAgent` (Next.js)	`navigator.userAgent`
Runs on	Server (Middleware / SSR)	Client only
Parsing	Built-in, structured	Manual (string)
Use case	Redirect, rewrite, SSR logic	Client-side UI logic
Bot detection	`isBot` included	Manual regex
Spoofable	Yes	Yes

Summary

To understand your users at the request level in Next.js, userAgent is the right tool. It provides structured data about devices, browsers, operating systems, and bots — without depending on client-side APIs.

A practical starting point: use it in middleware to direct mobile users to /m while keeping desktop traffic on the main layout — no client-side JavaScript, no layout shift for the user.

🚀Understanding JavaScript Strict Mode: Why You Should Always Use It

MO Slah — Wed, 19 Nov 2025 21:19:23 +0000

When ES5 was released, JavaScript introduced a new feature called "Strict Mode", designed to make the language safer, cleaner, and more predictable. While it might seem like a small thing, "use strict" can make a huge difference in the quality and stability of your code.

Let’s dive into what strict mode is, why it exists, and why you should always use it in your programs.

What Is Strict Mode?

Strict Mode tightens JavaScript’s rules and removes some of the language’s silent errors. It helps you write better, more reliable code by enforcing stricter parsing and error handling.

In short, strict mode:

Prevents the use of undeclared variables

Throws more meaningful errors

Disables dangerous or confusing features

Helps the JavaScript engine optimize performance

As Kyle Simpson mentions in You Don’t Know JS: Types & Grammar:

“Strict mode is a big win for code, and you should use it for all your programs.”

How to Enable Strict Mode

You can enable strict mode globally or per function, depending on where you place "use strict".

Global Strict Mode

When you place it at the top of your file, the entire file runs in strict mode:

"use strict";

function foo() {
  // strict mode is active here
  function bar() {
    // strict mode is active here too
  }
}

Function-Level Strict Mode

You can also enable strict mode inside an individual function:

function foo() {
  "use strict";
  // only this function runs in strict mode

  function bar() {
    // not in strict mode
  }
}

What Happens When You Use Strict Mode

Strict mode makes JavaScript behave in a more predictable and professional way. Here are some of the biggest improvements:

No Implicit Global Variables

Without strict mode, assigning a value to an undeclared variable automatically creates a global variable — a common source of bugs.


function foo() {
  a = 10; // creates a global variable (bad!)
}
foo();
console.log(a); // 10

With strict mode:


function foo() {
  "use strict";
  a = 10; // ❌ ReferenceError: a is not defined
}
foo();

This forces you to declare variables properly with let, const, or var.

Prevents Silent Failures

In non-strict mode, some operations fail silently. For example, assigning a value to a read-only property doesn’t throw an error — it just fails quietly.

Strict mode changes that:

"use strict";

const obj = {};
Object.defineProperty(obj, "x", { value: 42, writable: false });

obj.x = 9; // ❌ TypeError

Disallows Duplicate Parameter Names

Strict mode doesn’t allow you to use the same parameter name more than once — which avoids confusion and improves readability.

"use strict";
function sum(a, a, c) { // ❌ SyntaxError
  return a + a + c;
}

Prevents this from Being Global

In non-strict mode, if you call a function without a context, this defaults to the global object (window in browsers).

function showThis() {
  console.log(this); // window
}
showThis();

But in strict mode, this stays undefined — which is safer and prevents accidental global variable leaks.

"use strict";
function showThis() {
  console.log(this); // undefined
}
showThis();

Why You Shouldn’t Avoid Strict Mode

If turning on strict mode makes your code break, that’s a good thing — it means strict mode is revealing potential issues in your program.

“If strict mode causes issues in your program, it’s almost certainly a sign that you have things you should fix.”
— You Don’t Know JS: Types & Grammar

Fixing these issues will make your code cleaner, more maintainable, and more future-proof.

🛠️ Strict Mode and Modern JavaScript

If you’re using ES6 modules (import / export), you don’t need to manually enable strict mode — it’s automatically applied.

// This module is always in strict mode
export function greet() {
  message = "Hello!"; // ❌ ReferenceError
}

So modern JavaScript essentially encourages best practices by default.

Final Thoughts

Strict mode isn’t just a “developer annoyance” — it’s a tool for writing better JavaScript.

It catches common mistakes early
It improves performance
It aligns with the modern direction of JavaScript

So don’t delay — make "use strict" (or ES modules) your default. Your future self will thank you.

Why typeof null === "object" in JavaScript? A Deep Dive into a Quirky Bug

MO Slah — Sat, 17 May 2025 23:28:46 +0000

If you’ve ever played around with JavaScript and used typeof, you may have stumbled upon this strange behavior:

typeof null; // returns "object"

Wait—what? Shouldn’t typeof null return "null"?

This is one of the most well-known and long-standing oddities in JavaScript. Let’s take a deep dive into why this happens, how it originated, and why it will likely never be fixed.

What Is typeof in JavaScript?

The typeof operator in JavaScript returns a string that represents the type of the operand:

typeof 42; // "number" typeof "hello"; // "string" typeof true; // "boolean" typeof undefined; // "undefined" typeof {}; // "object" typeof function(){}; // "function" typeof Symbol(); // "symbol"

But then:
typeof null; // "object"
That looks... wrong.

Why Does typeof null Return "object"?

This dates back to the early days of JavaScript, in the 1990s. JavaScript was designed in a hurry—literally in just 10 days—and the internal implementation details left some quirks behind.

Here’s the technical reason:

Internally, JavaScript values were represented using a type tag in their binary form.

The type tag for objects was 000, and null also happened to be represented with a binary value of all zeroes (0x00).

As a result, the typeof operation interpreted null as an object.

So it’s essentially a bug in the original implementation that got locked into the language.

Why Can’t This Be Fixed?

It seems simple—just fix the bug so that typeof null returns "null", right?

Not quite.

Here’s the problem: JavaScript is the most widely used programming language in the world, and it’s embedded in billions of websites and applications. Changing the return value of typeof null now would break backward compatibility for existing codebases that depend on it returning "object".

In fact, this issue is so well-known that Brendan Eich (the creator of JavaScript) addressed it himself, admitting it’s a bug but also saying it’s too late to fix.

Here’s a relevant quote:

“typeof null === "object" is a bug, but fixing it would break a lot of code on the web.”

— Brendan Eich, Creator of JavaScript

Summary

typeof null returns "object" — a historical bug.
It originated from early binary representations of types.
It’s too risky to fix now because it would break too much existing code.
Use strict equality to check for null.

Final Thoughts

JavaScript is full of quirks, and this one is a classic example. While it might seem strange at first, understanding these “gotchas” helps us write more robust and reliable code.

The Evolution of LiveScript: The Precursor to JavaScript

MO Slah — Mon, 23 Dec 2024 22:03:39 +0000

When we think about web development, JavaScript is one of the first technologies that comes to mind. It’s hard to imagine a time when JavaScript wasn’t the backbone of interactivity on the web. But did you know that JavaScript wasn’t always called JavaScript? Its roots trace back to a language called LiveScript, and its journey is a fascinating chapter in programming history.

The Birth of LiveScript

In 1995, Netscape Communications Corporation was at the forefront of web innovation. As the internet grew in popularity, there was a pressing need for a lightweight scripting language to make web pages more dynamic. This led to the creation of LiveScript, a scripting language designed to work within the browser.

LiveScript was developed with a simple goal: to make web pages interactive without requiring extensive programming knowledge. It allowed developers to write small scripts directly in HTML to handle events like button clicks or form submissions. This simplicity made LiveScript an attractive option for web designers who wanted to add interactivity without delving into complex programming paradigms.

LiveScript Becomes JavaScript

In December 1995, shortly after its initial release, LiveScript underwent a significant rebranding. Netscape partnered with Sun Microsystems, the company behind the popular programming language Java. To capitalize on Java's growing popularity and marketing appeal, LiveScript was renamed to JavaScript.

Despite the shared name, JavaScript and Java have very little in common. The renaming was primarily a marketing move, leading to some confusion that persists even today. While Java is a statically typed, object-oriented programming language, JavaScript is a dynamically typed, prototype-based scripting language.

Features of LiveScript

LiveScript introduced several features that became foundational to JavaScript:

Lightweight Syntax: Designed to be easy to use for web designers and developers alike.

Event Handling: Allowed developers to respond to user actions like clicks, form submissions, and more.

Browser Integration: Scripts could be embedded directly into HTML, making it accessible and straightforward.

These features laid the groundwork for JavaScript’s role as a key player in web development.

The Legacy of LiveScript

The transformation of LiveScript into JavaScript marked the beginning of one of the most significant developments in programming history. JavaScript has since evolved into a versatile, full-fledged programming language capable of:

Powering dynamic user interfaces with frameworks like React, Vue, and Angular.

Enabling server-side development with tools like Node.js.

Supporting mobile and desktop applications through frameworks like React Native and Electron.

But the influence of LiveScript doesn’t stop there. Its legacy reminds us of the importance of simplicity and accessibility in programming. By lowering the barrier to entry, LiveScript paved the way for countless developers to start their journey in web development.

Bonus: A Modern Twist

Interestingly, there’s another language called LiveScript, released in 2011, which is unrelated to the original LiveScript. This modern LiveScript is a functional programming language that compiles to JavaScript, inspired by CoffeeScript. While it’s not the same as the 1995 version, it’s a testament to how JavaScript’s ecosystem continues to inspire new ideas.

Conclusion

The story of LiveScript is a reminder of how technology evolves and adapts to meet the needs of its time. From its humble beginnings as a simple browser scripting language to its transformation into JavaScript, LiveScript played a crucial role in shaping the modern web.

Whether you’re a seasoned developer or just starting out, understanding the history of LiveScript can give you a deeper appreciation for the tools we use today. So the next time you write a piece of JavaScript code, take a moment to reflect on the journey that started with LiveScript over two decades ago.