TypeScript.CodeCompared.To/PHP

A file that is nothing but PHP omits the closing ?> by convention, because whitespace after it is sent to the browser and breaks a later header() call. There is no build step: the engine parses and runs the file each request, so where you would run tsc and ship JavaScript, you ship the source itself.

A bare $name works; anything more complex needs braces, as in "{$user['name']}" or "{$order->total}". Concatenation is . rather than +, and using + on two strings is a TypeError in PHP 8 — a small mercy after JavaScript's "1" + 1. The trailing \n only works in double quotes, since single-quoted strings do not process escapes either.

var_export($value, true) returns the text instead of printing it, which makes it the right choice for putting a value inside a sentence — and the reason to prefer it over var_dump when the output sits beside another language's. gettype is typeof, and array_is_list (PHP 8.1) is Array.isArray's nearest relative, because a PHP array is a list only when its keys happen to be 0, 1, 2 — the arrays section returns to this.

TypeScript checked double's signature when you compiled it and then erased it, so at run time there is nothing left to check: JSON.parse returns any, the call compiles, and you get NaN propagating into the rest of the program. PHP checks the declared parameter type on every call, and with declare(strict_types=1) it refuses even a string that looks like a number. The bug surfaces at the boundary, named, with a stack trace — rather than three functions later as a NaN.

In coercive mode — the default — "41" is silently converted to 41 and a float is truncated to an int, which is the behaviour that gave PHP's type declarations their weak reputation. In strict mode only an exact type is accepted, with one exception: an int is still accepted where a float is declared. Put the declaration at the top of every file you write; it is the closest thing PHP has to "strict": true, and unlike tsconfig it is per-file rather than per-project.

The TypeScript column prints number from a function whose signature says string, because a single any anywhere in the chain disables the check — which is exactly how a wrong type from an API response spreads through a codebase. PHP checks the value on its way out of the function, so the error names the function that lied rather than the caller that trusted it. The available return types include void, never, static and mixed, all of which a TypeScript reader will recognise.

PHP has no equivalent, and it needs none — the way to say "this data is a User" is to construct one, and the constructor's parameter types do the checking. That is the shape to adopt: parse into an array at the edge, build typed objects immediately, and let a TypeError reject bad input at the boundary. The TypeScript ecosystem reaches the same place with Zod or Valibot, which exist precisely because as does not check; PHP's version is the language.

Type checking moves to PHPStan or Psalm, run in CI rather than as a build step. Type enforcement moves into the engine, at run time. And emitting is gone: the .php file you write is the file the server executes, so there is no source map, no build cache and no "did I forget to rebuild". Opcache keeps compiled bytecode in memory between requests, which is a deployment concern rather than a development one.

Because nothing is declared, a typo creates a new variable; PHP 8 at least warns when you read one that was never set. The scoping is the bigger surprise: PHP has no block scope and no closure over enclosing locals. A variable set inside an if is visible after it, and a function cannot see the surrounding function's variables unless you list them in a use clause. File-level const declares a genuine constant and takes no dollar sign.

That @var comment is invisible to the engine and load-bearing for PHPStan and Psalm. The consequence for a TypeScript reader is that the type information lives at function boundaries rather than flowing through every expression: annotate the signature well and the analyser infers the rest, exactly as tsc does — but a wrong @var is a lie nothing at run time will catch.

So function half(int $value): float is a meaningful declaration, and in strict mode passing 7.5 where int is declared throws. 7 / 2 still gives 3.5, because division promotes to float; intdiv is the integer division and % is integer-only. Past PHP_INT_MAX an integer silently becomes a float and starts losing precision — the same class of quiet failure as JavaScript above Number.MAX_SAFE_INTEGER. Note the printing: plain echo rounds to 14 digits and hides the classic 0.1 + 0.2, while var_export shows it.

Narrowing works the same way and by the same means: is_int, is_string and instanceof are typeof and instanceof, and PHPStan understands them exactly as tsc understands a type guard. What PHP unions cannot contain is literal types — there is no "active" | "retired", which is the TypeScript idiom this reader uses most. That role belongs to an enum, two rows down. Intersection types (Countable&Iterator) exist too, for interfaces only.

That buys things the TypeScript version cannot have: methods, interface implementations, constants, and a value that cannot be a typo because it cannot be constructed. A backed enum (the : string) carries a scalar for the database or JSON, with from to convert in — it throws on an unknown value, and tryFrom returns null instead. It costs the ergonomics of a bare string: every use is Status::Active, and serialising needs ->value.

The closest shape is an abstract base class with final subclasses, matched with instanceof. match throws UnhandledMatchError when nothing matches, so an unhandled case fails loudly at run time rather than being caught by the compiler — a weaker guarantee than never, and a real one. PHP has no sealed classes, so nothing stops a third subclass appearing; PHPStan can be told the class list with a @phpstan-sealed-style annotation, which is again the analyser doing the compiler's job.

It is an expression, so it returns a value and needs no return per branch; there is no fall-through, so no break; and it compares with ===, so match("1") does not hit the 1 arm. An unmatched value with no default throws UnhandledMatchError rather than silently doing nothing — which is the behaviour the never trick simulates in TypeScript. match(true) with boolean arms is the idiomatic replacement for an if/else ladder.

That collapses a distinction you have been maintaining: "absent" and "present but empty" are the same value here, and the two questions are asked with different functions rather than different constants. isset() means "set and not null", array_key_exists() means "the key is there even if its value is null", and empty() is the trap — it is true for 0, "0", "" and [] as well. ?? behaves exactly as it does in TypeScript, including not falling back on 0.

?string is shorthand for string|null and the two are interchangeable. This is the one place PHP's runtime types give you something close to strictNullChecks — a function that says string genuinely cannot hand back null, checked on every return rather than at compile time. Note that array as a parameter type says nothing about what is in the array; that gap is what the generics and PHPStan sections are about.

The arrow is -> rather than a dot, so it is ?->. It works for method calls as well as properties, and — unlike TypeScript's ?. — it may not be used for array access or as ?.(); array reads use ?? null instead. Combining it with ?? as above is the idiom, and it is one of the few places where PHP code and TypeScript code look identical.

TypeScript's is erased: the assignment is a compile error, the emitted JavaScript performs it happily — the column prints 99 — and one cast is all it takes to get there, which is why Object.freeze exists as the run-time version. PHP's readonly (8.1) throws an Error on any write after initialisation, from inside the class as well as outside. It is per-property rather than per-object, applies only to typed properties, and PHP 8.2 added readonly class to mark them all at once. There is no as const and no readonly array type.

So the type declaration array tells you almost nothing — not the element type, not whether it is a list, not what keys it has. That is the single biggest gap for a TypeScript reader, and the whole reason PHPStan's array<string, User> and list<int> docblocks exist. One consequence to watch immediately: json_encode emits […] for a list and {…} for anything else, so removing one element from the middle of a list changes the shape of your API response.

So a function that appends to an array parameter changes nothing the caller can see, unless the parameter is declared &$items. The copy is lazy underneath — PHP copies on write — but the semantics are a full copy, which means the defensive [...items] spread you write in TypeScript is unnecessary here. Objects go the other way and behave exactly as in TypeScript: $b = $a gives two names for one instance, and clone makes a shallow copy.

Watch the argument order, which is genuinely inconsistent: array_map(callback, array) puts the callback first, while array_filter(array, callback) and array_reduce(array, callback, initial) put the array first. And array_filter preserves keys, so filtering a list can leave keys 1, 3, 5 and turn your next json_encode into an object — wrap it in array_values(). This is the row where PHP is plainly worse than TypeScript, and knowing it in advance saves the surprise.

There is no rest element in a destructuring assignment: [$first, ...$rest] is a parse error, so the tail comes from array_slice. Everything else carries over: nested patterns, foreach ($pairs as [$left, $right]), spread with string keys (PHP 8.1+), and ... in a parameter list for variadics. Spreading into a function call spreads a keyed array into named arguments, which has no TypeScript equivalent at all.

Pass true and mean it. array_search returns the key, or false when nothing matched, so compare with !== false rather than truthiness — key 0 is falsy. There is no find: filter and take the first. And note the false friend on this row — TypeScript's in tests keys while PHP's in_array tests values; the key test is array_key_exists or isset.

The argument order is the famous part. str_replace($search, $replace, $subject) puts the subject last while strpos($haystack, $needle) puts it first, and the inconsistency is historical and permanent. The modern additions are consistent and worth preferring: str_contains, str_starts_with and str_ends_with (PHP 8.0) take the haystack first and return real booleans, replacing the old strpos(...) !== false dance.

There are no literal types, no template literal types, no keyof, no mapped or conditional types, and no type-level computation of any kind — in the language or in PHPStan. What replaces them is a run-time guard at the boundary, as above, or a value object whose constructor validates once so the rest of the code can take the type's word for it. PHPStan does understand a few value types in docblocks (positive-int, non-empty-string, class-string), which is a narrow but genuinely useful slice.

JavaScript strings are UTF-16 code units, which has its own emoji-shaped problems, but at least "naïve".length is 5. In PHP strlen says 6, and substr($word, 0, 3) can cut a character in half and produce invalid UTF-8. The rule: for user-facing text use the mb_* family and set mb_internal_encoding('UTF-8'). Byte functions are correct only when you genuinely mean bytes. mb_* lives in the mbstring extension, which is not compiled into every PHP build — extension_loaded('mbstring') is worth checking before you rely on it.

That de-indenting rule is the one thing a template literal cannot do — a TypeScript multi-line string carries whatever leading spaces the source had, which is why dedent libraries exist. Use <<<'TEXT' with quotes around the marker for the nowdoc form: no interpolation, no escapes. There is no tagged-template mechanism, so nothing corresponds to sql`...` or css`...`.

Any parameter may be passed by name, in any order after the positional ones, and each one keeps its own declared type — which the options object gives up unless you write the type literal out. The new obligation is that a parameter name is now part of your public signature, so renaming one is a breaking change. Variadics are ...$rest in the signature, and spreading a keyed array at a call site fills in named arguments.

use ($count) captures the value at the moment the closure is created, so the counter would return 1 forever; use (&$count) captures the variable by reference, which is what a TypeScript closure always does. Arrow functions (fn() => ...) capture automatically by value and are limited to a single expression — so a multi-statement closure still needs the long form and its use list.

So the signature lives in a docblock, where PHPStan and Psalm read it and the engine does not — a wrongly-shaped callback is a TypeError inside the callback, at the moment it runs. The Closure type is narrower (a closure specifically, not a string function name or an array method reference) and is worth preferring for parameters you will invoke. First-class callable syntax — strlen(...), $object->method(...), PHP 8.1 — turns any of those forms into a real Closure, checked where it is written rather than where it is called.

The engine can only say int|string, so the caller has to narrow. What fills the gap is a PHPStan conditional return type in a docblock — the ($value is string ? int : string) above is real PHPStan syntax and gives the analyser the same information the overloads gave tsc. Nothing at run time uses it. The everyday alternative is two differently-named functions, which is usually clearer anyway.

The syntax has no * — the presence of yield is what makes it a generator. yield $key => $value produces keys, yield from delegates, and $generator->send() passes values back in, exactly like TypeScript's. Spreading needs iterator_to_array rather than [...]. Generators are the standard way to stream a large database result or file without holding it in memory, and they are also how Laravel's lazy collections work.

The differences are all in what happens after compilation. private in TypeScript is erased — the emitted JavaScript has an ordinary property, which is why #private fields were added — while PHP's private is enforced by the engine. $this-> is the arrow, not a dot, and $this is mandatory: a bare $balance inside a method is a local variable. Marking a class final is common practice in modern PHP, since there is no sealed and inheritance is otherwise open.

Reading it throws Error: Typed property Config::$host must not be accessed before initialization, which is a far better failure than TypeScript's undefined leaking into the program from a definite-assignment assertion nobody rechecked. The lesson to carry over: give every property a value in the constructor, or declare it ?string $host = null and mean it. Property types are checked on every write, so assigning the wrong type to a public property throws at the assignment.

The alternative is the __get magic method, which intercepts reads of properties that do not exist — that is how Laravel's Eloquent models expose database columns, and it is invisible to static analysis unless you annotate the class with @property. Property hooks (public float $area { get => ...; }) arrived in PHP 8.4, so a codebase on 8.4 or later has the syntax; this page targets 8.3, where a method is the answer.

Inside the class, self:: means the class the code was written in and static:: the class actually being called — late static binding, which matters as soon as you subclass. parent::method() is super.method(). Note the inconsistency you will mistype at least once: a static property keeps its $ after the colons (Counter::$created) while a const does not.

A trait is compiler-level copy-and-paste: its methods and properties are inserted into the using class, so there is no extra class in the chain and no complicated type gymnastics to keep the analyser happy. Conflicts between two traits are an error you resolve explicitly with insteadof, where a mixin chain silently takes the last one. A trait cannot be used as a type — declare an interface alongside it and implements that, which is the standard pairing.

That is the deepest structural difference between the two type systems, and it changes how code is designed. The anonymous object literal has no equivalent as a parameter — every value that crosses a typed boundary is an instance of a named class. Retroactive conformance is impossible: you cannot make a third-party class implement your interface, so the pattern is an adapter class that wraps it. In exchange, an interface name means one specific contract rather than any object that happens to have the right members.

A one-field wrapper class in place of type UserId = number looks heavy, and it buys something the alias does not: UserId and OrderId become genuinely different types that cannot be swapped, which is what a TypeScript author simulates with branded types. For pure shapes, PHPStan's @phpstan-type and Psalm's @psalm-type declare a reusable alias understood by the analyser — including array{ok: bool, value: string}, which is as close as anything gets to an object type literal.

The narrowing functions are is_int, is_string, is_array, is_callable and friends rather than typeof, and analysers understand all of them. What has no counterpart is the user-defined type guard — function isUser(value: unknown): value is User. PHPStan's replacement is a docblock: @phpstan-assert-if-true User $value on a boolean-returning function tells the analyser the same thing, and again the engine ignores it.

@template T, @param T and @return T are read by PHPStan and Psalm, which check the calls, infer Box<string> through the code, and report an error if you put an int in and call a string method on the way out. It is genuinely comparable to tsc, with one difference that matters: nothing at run time enforces it, and mixed is what the engine actually sees. Generics in the language have been proposed repeatedly and are blocked on the cost of run-time checking; do not wait for them.

The vocabulary is worth learning because it is more precise than TypeScript's in one respect: list<User> means sequential integer keys from zero, array<int, User> means integer keys that may have gaps, array<string, User> is a map, and non-empty-list<User> exists too. array{id: int, name: string} describes a keyed array with exactly those keys — TypeScript's object type literal, in a comment. The engine checks only that an array arrived.

Every write goes through add(string $name), which the engine checks — so the collection's element type is enforced at run time, not merely analysed. That is worth the boilerplate for a type that matters, and it is why Doctrine, Laravel and most domain-driven PHP codebases are full of small collection classes. static as a return type is the equivalent of TypeScript's this type and is what makes the fluent chain keep the subclass's type.

PHPStan has ten levels, and the number tells you a great deal about the code: level 0 catches undefined functions, level 5 checks argument types, level 8 checks nullability, and level 9 refuses to let mixed pass unchecked. Psalm is the alternative, with errorLevel counting the other way (1 is strictest) and a stronger taint-analysis story. Both read the same docblock vocabulary, both have baseline files for adopting them on a legacy codebase, and both are dev dependencies rather than part of the runtime.

The ones you will use daily are list<T>, array<K, V>, array{...} and class-string<T>; the last is how a factory or a container is typed, and it is checked much better than TypeScript's new () => T. @template declares a generic, @phpstan-assert declares a type guard, and @phpstan-type declares an alias. What is missing is everything computed: no keyof, no mapped types, no conditional types beyond the single return-type form.

At low levels mixed flows anywhere unchecked, exactly like any. At level 9 it must be narrowed before use, exactly like unknown — which is the strongest argument for running level 9 on new code. The run-time half is unchanged either way: mixed as a declared type accepts everything, so the checking really is the analyser's job here. Everything arriving from json_decode, a database driver or a superglobal starts as mixed, which makes the boundary the place to spend your validation effort.

Several catch blocks may follow one try, and a single block can list alternatives (catch (AException|BException $error)). TypeScript types the caught value as unknown under useUnknownInCatchVariables, which is the right default and the reason for the ladder — anything can be thrown in JavaScript. PHP can only throw an object implementing Throwable, so the caught value always has getMessage(), getCode(), getFile(), getLine() and getPrevious().

TypeError, ValueError, DivisionByZeroError and ArgumentCountError are all Errors, so catch (Exception $e) — which looks like a catch-all and is the reflex from other languages — will not catch a type failure. Catch \Throwable when you genuinely mean everything. For your own exceptions, extend RuntimeException or LogicException rather than Exception directly; the SPL hierarchy is shallow and conventional.

The difference is who reads it. TypeScript's @throws is understood by editors and by nothing else. PHPStan and Psalm do read PHP's, and both can be configured to report a call that ignores a documented exception — Psalm's checkThrows and PHPStan's exceptions rules turn it into something close to a checked exception, opt in per project. It is one more example of the pattern on this page: the run-time behaviour is the same, and the analyser is where the rigour lives.

Reading a missing array key is a warning and the value is null. The second line is where the two languages diverge dangerously: adding one gives NaN in JavaScript, which is at least visibly wrong, and 1 in PHP, because null converts to 0 and a wrong answer looks exactly like a right one. Two habits: use ?? to read anything that might be absent, and configure a set_error_handler that throws ErrorException — which every framework does for you. The @ operator suppresses diagnostics for one expression and is almost always the wrong tool.

A Node process stays up between requests, so module-level state keeps accumulating until you redeploy. A PHP request starts a fresh interpreter, runs your file, sends the output and throws everything away: the next request sees visit 1 again. Anything that must survive goes to a session, Redis or the database. The upside is that a leak or a crash costs one visitor rather than every visitor; the downside is that there is no warm cache and no long-lived connection pool without an extra layer. /javascript/php owns this story in full.

That removes function colouring entirely: any function may call any other, and no library needs an async variant. It also removes Promise.all — concurrent work becomes curl_multi_exec for HTTP, a queue worker for anything slow, or an event-loop runtime (ReactPHP, Amp) if you are willing to run your application differently. Fibers (8.1) are the machinery those runtimes use; you will almost certainly never write new Fiber yourself.

$_GET, $_POST, $_SERVER, $_COOKIE, $_FILES and $_SESSION are visible in every scope without being passed or imported, because there is only ever one request in the process. Every value in them is attacker-controlled text with no schema and, to the analyser, type mixed — so they are exactly where validation belongs. Frameworks wrap them in a PSR-7 Request object precisely so code can be tested and typed.

That is the opposite of an ES import: use App\Http\Client; only says "when I write Client, I mean that one", and the file is found later by the autoloader. So there is no import-time side effect, no circular-import problem and no tree shaking to think about. The separator is a backslash, which is why it must be escaped in double-quoted strings; a leading one means the global namespace (\strlen(), \Throwable). PSR-4 is the convention tying App\Http\Client to src/Http/Client.php.

There is no module loader, so every entry point begins with require __DIR__ . '/vendor/autoload.php';, after which every installed class is available by name with no further imports. And there is no build: the source is the artifact, so what a TypeScript project spends on bundling, a PHP project spends on opcache configuration instead. Trees are an order of magnitude smaller, because the standard library covers strings, arrays, dates, hashing, HTTP and databases. composer.lock is committed and composer install honours it; composer update is the one that changes it.

PHP's ecosystem converged: PHPUnit is the test runner almost everywhere (Pest is a friendlier layer on top of it), PSR-12 is the formatting standard almost everywhere, and PHPStan or Psalm is the checker. Composer scripts play the role of npm scripts. What has no counterpart is the bundler question, because there is nothing to bundle — and php -S gives you a development server with no dependency at all, which is a small pleasure after configuring vite.