PHP.CodeCompared.To/JavaScript

JavaScript writes to the console with console.log, which always appends a newline (like PHP's print plus \n) and accepts multiple arguments separated by spaces. There is no <?php tag — a .js file is JavaScript throughout — and statements may end with a semicolon, though they are mostly optional thanks to automatic semicolon insertion.

JavaScript runs in two homes: the browser (its origin) and Node.js on the server — the role PHP traditionally owned. Unlike PHP, where each request starts a fresh process, a Node server is one long-lived process handling many requests on a single event loop, so global state persists between requests and blocking the thread blocks everyone.

For inspecting structures, console.log already prints objects and arrays readably — it is the everyday equivalent of print_r, with no true second argument needed to get a string back. console.table renders arrays of objects as a grid, and console.dir with { depth: null } expands deeply nested data that console.log would otherwise truncate.

JavaScript has no $ sigil but it does require a declaration keyword: const for bindings that never change and let for those that do. Prefer const by default and reach for let only when you reassign — a discipline PHP does not enforce. Avoid the old var, which has confusing function-wide scope.

JavaScript's typeof is coarser than gettype. There is a single number type — no integer/double split — so 42 and 3.14 report the same. And typeof [1,2] is "object", since arrays are a kind of object; use Array.isArray() to test for an array specifically.

A real adjustment: JavaScript splits PHP's single null into two. undefined means "never assigned" (a missing property or unset variable), while null means "deliberately empty". They are distinct (null !== undefined), but the nullish coalescing operator ?? treats both as absent, so x ?? fallback behaves like PHP's ?? against either.

PHP wisely uses . for concatenation and + only for math, so it never guesses. JavaScript overloads +: if either side is a string, it concatenates; otherwise it adds. This is the source of countless bugs — 5 + "3" is "53" but "5" - 1 is 4, because - has no string meaning and forces numeric conversion.

const is JavaScript's constant, but with one caveat PHP's const shares: it freezes the binding, not the value. A const array or object can still be mutated in place; only reassigning the variable itself is forbidden. To make the contents immutable too, wrap them in Object.freeze().

JavaScript interpolates only inside template literals — strings written with backticks (`...`), not the usual quotes. The placeholder is ${ ... } and, like PHP's {$...}, it accepts any expression. Ordinary "..." and '...' strings do not interpolate at all, so a stray "$user" stays literal.

As in many modern languages, PHP's global string functions become methods on the string. Note length is a property (no parentheses), while the rest are methods. replace swaps the first match and replaceAll swaps every one — unlike PHP's str_replace, which always replaces all.

JavaScript's split and join mirror explode and implode, but the receiver flips to match where the data lives: you split a string and join an array. split takes the separator (a string or a regular expression) as its argument, and join defaults to a comma if you pass nothing.

A template literal spans multiple lines as-is — no heredoc syntax needed. Every line break and space between the backticks is preserved literally, so unlike PHP's heredoc you control indentation by where you place the text, and there is no closing-label rule. Template literals also power "tagged templates", a metaprogramming hook PHP has no analogue for.

A plain JavaScript array is the integer-indexed half of PHP's array. You append with push rather than [], read the size from the length property, and — crucially — keys are only ever sequential integers. The string-keyed half of a PHP array becomes a separate object or Map, shown next.

The string-keyed PHP array maps to a plain object literal { }, whose keys you read with dot or bracket notation. Iterating needs Object.entries() to get key/value pairs. For a true dictionary — any key type, guaranteed order, a real .size, and safe iteration — use a Map (new Map([["Alice", 30]])), which avoids the prototype pitfalls of using objects as hash tables.

These are methods on the array, so they chain and always put the collection first — no more recalling whether the callback or the array is the first argument as in array_map vs array_filter. And filter returns a clean re-indexed array, sparing you PHP's array_values() dance after array_filter leaves gaps in the keys.

JavaScript destructures both arrays (positionally, with [ ]) and objects (by key, with { }) — the latter is more concise than PHP's ["name" => $name] form because matching variable names are implied. Defaults (const { role = "guest" } = user) and renaming ({ name: fullName }) make it a workhorse for unpacking function arguments and API responses.

JavaScript's spread operator is the same ... as PHP's, and it works for both arrays and objects — { ...base, port: 5432 } is the idiomatic way to clone-and-extend an object, with later keys winning. It is the standard tool for non-mutating updates, which matters because JavaScript objects are reference types (see the Gotchas section).

For arrays, includes replaces in_array. For objects, the in operator replaces array_key_exists, and Object.keys() / Object.values() / Object.entries() give you the keys, values, and pairs. Reading a missing object property returns undefined rather than emitting a warning as PHP does for a missing array key.

Conditionals are nearly identical — both keep the parentheses and braces. The one syntactic difference is the chained keyword: JavaScript writes else if as two words, where PHP fuses them into elseif. (PHP actually accepts else if too, but elseif is its convention.)

PHP 8's match is genuinely nicer than JavaScript's switch: it is an expression that returns a value, has no fall-through, and uses strict === comparison. JavaScript only has the older switch statement — it falls through unless you write break, does not produce a value, and groups multiple values by stacking empty case labels. Many JS developers reach for an object lookup or if/else if instead.

The C-style for is the same. PHP's foreach ($array as $value) becomes for (const value of array) — note of, which iterates values. Beware its sibling for...in, which iterates keys (and inherited ones) and is almost never what you want for an array; use for...of or array.forEach().

The falsy sets overlap but differ in two traps. In JavaScript, "0" is truthy (a non-empty string), whereas PHP treats it as falsy — a classic bug when checking form input. And an empty array [] is truthy in JavaScript (objects are always truthy), while it is falsy in PHP. JavaScript adds undefined and NaN to the falsy list.

The function keyword and explicit return are the same; JavaScript simply drops the type annotations (those return when you adopt TypeScript). A function declaration like this is "hoisted" — usable before its definition appears in the file — unlike a function assigned to a const, which is not.

Default parameter values look identical to PHP's. One bonus: a JavaScript default can be any expression, including one that references earlier parameters (function f(a, b = a * 2)) — PHP restricts defaults to constant expressions. A default applies whenever the argument is omitted or explicitly undefined.

JavaScript has no named-argument syntax like PHP 8's admin: true. The established idiom is to accept a single options object and destructure it in the parameter list, which gives the same order-independent, self-documenting call site. Defaults go right in the destructuring pattern, as shown.

JavaScript's rest parameter uses the same ... token PHP adopted, collecting extra arguments into a real array (so you immediately get map, reduce, and the rest). Spreading an array at the call site with sum(...values) works identically. There is no array_sum; reduce is the general-purpose fold.

JavaScript's arrow function n => n * n is the direct counterpart of PHP's fn($n) => .... A single-expression body returns implicitly; a braced body needs an explicit return. Beyond brevity, arrow functions differ from regular functions in one important way — they do not bind their own this — which the Closures section covers.

JavaScript closures capture lexical variables automatically — there is no use ($factor) clause. And because they close over the live binding (not a copy), changing factor afterward is visible inside the closure. This is the same behavior as PHP's use (&$factor) by-reference form, but it is the default rather than opt-in.

In JavaScript functions are values from the start — there is no callable type hint and no (...) first-class-callable syntax, because a function name already is a reference to the function. You pass increment, store it, and return it like any other value, which is why callbacks feel so lightweight.

Here is the practical reason arrow functions exist. A regular JavaScript function gets its own this determined by how it is called, so inside a map callback a plain function would lose the object and this.base would break. An arrow function has no this of its own and inherits the enclosing method's — giving you the predictable behavior PHP's $this always has.

JavaScript's class will feel familiar: the constructor is named constructor, members are reached through this. (a dot, not ->), and you instantiate with new. There is no constructor property promotion, so you assign this.name = name by hand. Under the hood this is syntax sugar over prototypes, but day to day it reads like PHP OOP.

Class fields are declared directly in the body, like PHP's typed properties but without a visibility keyword — fields are public by default. For real privacy, JavaScript uses a # prefix (#balance): unlike PHP's private, which is enforced softly, a # field is genuinely inaccessible from outside the class, even via bracket notation.

Inheritance uses the same extends keyword. To call a parent constructor or method you write super(...) / super.speak() rather than PHP's parent::. One rule to remember: a subclass constructor must call super() before it touches this, because the parent is responsible for initializing the instance.

JavaScript marks both static methods and static fields with the static keyword, and you access them through the class name with a dot — MathUtil.square(5) — not PHP's :: scope-resolution operator. JavaScript has no separate const for class constants; a static field fills that role.

JavaScript has built-in get and set accessors: a method prefixed with get is invoked by reading temp.fahrenheit as if it were a plain field — no parentheses. This is cleaner than PHP's convention of getFahrenheit() methods or its __get magic method, and the matching set fahrenheit(value) intercepts assignments.

JavaScript modules are explicit about what crosses file boundaries: you export specific names and import exactly what you need, rather than PHP's require that pulls in a whole file and relies on namespaces to avoid collisions. Each module has its own scope — nothing is global by accident. This example cannot run in the single-file sandbox here, but it is the backbone of every real project.

Alongside named exports, a module can have a single default export that the importer may name anything — common for "the one main thing" a file provides. Dependencies are installed from npm (the registry analogous to Packagist) into a local node_modules folder, with package.json playing the role of composer.json.

The structure is the same — try / catch / finally — but JavaScript's catch does not filter by exception type the way PHP's catch (InvalidArgumentException $e) does. You catch every error in one block and inspect it (error instanceof TypeError, error.message) to decide what to do. The message is on .message, not ->getMessage().

Custom errors subclass the built-in Error. Two conventions matter: call super(message) so the message and stack trace are set up, and assign this.name so the error prints with the right label. Because catch is untyped, you select your error with instanceof and re-throw anything you did not mean to handle.

Unlike PHP, which only permits throwing objects implementing Throwable, JavaScript lets you throw any value — a string, a number, an object. This is a trap: a thrown non-Error has no .message or .stack, so defensive code must handle the possibility. The rule of thumb is simple — always throw an Error (or a subclass).

This is the deepest model difference. PHP executes top to bottom and blocks on I/O — a database call pauses the whole script until it returns. JavaScript runs on a single-threaded event loop: I/O is non-blocking, and callbacks (timers, network responses) are queued to run after the current synchronous code completes. Understanding this ordering is essential to everything that follows.

Where a PHP function blocks and hands back the finished value, an asynchronous JavaScript function hands back a Promise immediately — a placeholder for a value that will exist later. You register what to do on completion with .then(callback) (and failures with .catch). The script does not wait; it moves on and runs your callback when the result is ready.

The async/await syntax lets asynchronous code read like the synchronous PHP beside it: await a Promise and you get its resolved value on the next line, as if it had blocked. It did not — the function yields control to the event loop while waiting. An async function always returns a Promise, and await is only valid inside one (hence the wrapping IIFE here).

This is where the event loop pays off. In synchronous PHP, two slow calls run back to back and you wait for both in sequence. In JavaScript, kick off both Promises and await Promise.all([...]) — they progress concurrently on the single thread (the I/O overlaps), so the total wait is the slowest one, not the sum. Promise.allSettled is the variant that does not reject on the first failure.

Here PHP is clearly ahead: its first-class enum (8.1) has cases, backing values, and helpers like ::from(). JavaScript has no enum type at all. The common substitute is an object of constants wrapped in Object.freeze() to prevent accidental modification — adequate, but without the type safety, exhaustiveness, or methods PHP enums provide. (TypeScript adds a real enum.)

PHP enums can carry methods directly on each case — behavior and value travel together. JavaScript's frozen-object enums are plain data, so associated behavior lives elsewhere: a companion lookup object (as here) or a standalone function. When the behavior grows substantial, a full class with static instances is the closer structural match.

JSON is native to JavaScript — it is JavaScript object syntax — so JSON.stringify and JSON.parse need no array-vs-object flag like json_decode($json, true): objects parse to objects and arrays to arrays, exactly as written. JSON.stringify(value, null, 2) pretty-prints with two-space indentation, the equivalent of JSON_PRETTY_PRINT.

Both operators carried over almost verbatim. ?? supplies a fallback only when the left side is null or undefined (not for 0 or ""), and the optional chaining operator ?. is JavaScript's ?->: it short-circuits to undefined the moment a link in the chain is nullish, instead of throwing. They pair naturally, as shown.

A genuine trap: JavaScript's default sort converts elements to strings, so [10, 2, 33, 4] sorts to [10, 2, 33, 4] lexicographically — "10" before "2". For numbers you must supply a comparator, (a, b) => a - b. Like PHP's sort, it mutates the array in place and returns it (there is no separate non-mutating sort until toSorted).

JavaScript has two string-to-number paths: parseInt/parseFloat read a leading number and ignore trailing junk (like PHP's intval), while Number() is strict and yields NaN for "42px". There is no number_format; toLocaleString handles grouping and locale, and toFixed rounds to a fixed number of decimals (returning a string). JavaScript has no spaceship operator.

Both languages have a loose == and a strict ===, but their coercion tables do not match — 0 == "" is false in PHP 8 yet true in JavaScript, and null == false flips the other way. Do not assume your PHP intuition transfers. The universal advice is the same in both: always use === and never reason about == at all.

A major trap coming from PHP, whose arrays copy on assignment. JavaScript objects and arrays are reference types: copy = original makes both names point at the same object, so mutating one mutates both. To copy, spread into a new literal ({ ...original } or [...list]) for a shallow clone, or structuredClone(original) for a deep one. Primitives (numbers, strings, booleans) still copy by value.

JavaScript has a single IEEE-754 double number type, so 7 / 2 is 3.5 (use Math.trunc or Math.floor for integer division — there is no intdiv). The float-rounding surprise 0.1 + 0.2 !== 0.3 exists in PHP too, but JavaScript shows the full 0.30000000000000004 rather than hiding it on display. For exact large integers, JavaScript adds a separate BigInt type (10n).

In PHP $this is permanently the object. In JavaScript this is determined by how the function is called, not where it was defined — so pulling a method off its object (const loose = counter.show) detaches this, and calling loose() fails. Fixes: call methods as obj.method(), .bind() the receiver, or use an arrow function (which has no this of its own). This trips up every PHP developer at least once.

PHP variables live for the whole function body regardless of the block they were set in. JavaScript's let and const are block-scoped: a variable declared inside an if or loop does not exist outside those braces. This is usually safer, but it is a real behavioral change — declare the variable in the outer scope if you need it there. (The legacy var is function-scoped like PHP, another reason to avoid it.)