Perl.CodeCompared.To/JavaScript

JavaScript needs no use v5.38; preamble to opt into modern behavior — there is no equivalent "legacy mode" to escape from, since JavaScript engines simply keep adding syntax without ever changing the meaning of existing code. console.log() is the direct equivalent of Perl's say: both append a trailing newline (in the console) and both accept any value directly with no explicit stringification required.

Both languages are interpreted with no separate compile step, so node hello.js and perl hello.pl feel identical to run from a terminal. JavaScript has a genuine advantage in reach, though: the exact same code (minus any Node-specific globals) also runs directly inside every web browser's developer console with no installation of any kind, something Perl has no analog for at all.

JavaScript uses the familiar C-style comment syntax — // for a single line and /* ... */ for a genuine multi-line block comment. This is a small but real improvement over Perl, which has no true multi-line comment construct at all; Perl programmers either stack consecutive # lines or reach for the Pod =begin/=end markers borrowed from its documentation tooling.

JavaScript's console.log() is the direct equivalent of Perl's say — both append a trailing newline automatically and both accept a bare number with no explicit stringification. Suppressing the newline in Node.js requires dropping to the lower-level process.stdout.write(), the mirror image of Perl's print (no newline) versus say (with newline) being two separate functions; in the browser console, console.log is effectively the only option and this distinction rarely comes up.

JavaScript has no sigils at all: a string, an array, and an object are all referenced with a bare, unpunctuated name — the type is determined by what the variable holds, not by a leading $, @, or %. This eliminates an entire category of Perl syntax rules (element access uses $ even on an @array, interpolation context changes the sigil, and so on): in JavaScript the name never changes no matter how the value is used.

Modern JavaScript's let and const are genuinely block-scoped, just like Perl's my: an inner let count shadows an outer one exactly the way an inner my $count does. The historical var keyword, kept only for backward compatibility, is function-scoped and hoisted instead — it ignores block boundaries the way Perl's our ignores lexical scoping, and should never be used in new code. Prefer const by default and reach for let only when the binding needs to be reassigned.

Both languages let a variable hold a value of any type at any time — neither requires a type declaration. JavaScript's typeof operator plays a similar diagnostic role to Perl's ref(), though typeof reports "object" for both plain objects and arrays, so checking specifically for an array needs the dedicated Array.isArray() function rather than a single universal type-inspection call.

Perl's use constant pragma enforces immutability at compile time — reassigning a Perl constant is a compile error. JavaScript's const matches that guarantee directly for the binding itself: reassigning a const name throws a TypeError at runtime. The one caveat is that const only locks the binding, not the value — const list = [1, 2, 3]; list.push(4); is perfectly legal, since the array's contents are still mutable even though list itself can never be pointed at a different array.

JavaScript's truthiness diverges from Perl in the same sharp way Python's does: the exact string "0" is falsy in Perl but truthy in JavaScript, since JavaScript treats any non-empty string as truthy. JavaScript then goes a step further than Python by keeping empty collections truthy as well — an empty array [] and an empty object {} are both truthy in JavaScript, which trips up not only Perl programmers but Python programmers making the jump too. A Perl if ($value) check that relies on "0" being falsy needs an explicit rewrite when ported to JavaScript.

Both languages support list-style destructuring assignment and the classic temp-free swap idiom. JavaScript's rest element ...tail plays exactly the same role as Perl's @tail soaking up the remaining elements — one of the closer syntactic matches between the two languages — though JavaScript spells the destructuring target with square brackets ([first, second, third]) rather than Perl's parenthesized list, and needs no sigils to distinguish which name captures the rest.

Perl interpolates a bare $name directly inside a double-quoted string, but embedding an arbitrary expression like age + 1 requires the awkward @{[ expression ]} trick. JavaScript's template literals (backtick-delimited strings, `...`) require the backtick punctuation instead of ordinary quotes — plain "..." and '...' strings never interpolate at all — but once inside backticks, ${expression} accepts any expression directly, with no special-casing needed.

Perl's string operations are mostly standalone functions — length($text), uc($text), index($text, ...) — that take the string as an argument, and there is no built-in trim function at all (trimming needs a manual regex substitution). JavaScript's String type has built-in methods called directly on the string object: text.trim(), text.toUpperCase(). Reversing has no dedicated string method in JavaScript either — the idiomatic approach spreads the string into an array of characters, reverses the array, and joins it back — and substring membership uses the .includes() method rather than a function call.

JavaScript has no dedicated heredoc syntax; a template literal spanning multiple lines is the closest equivalent, and interpolation is always available inside it with no extra opt-in required. Unlike Perl's squiggly heredoc (<<~LABEL), a JavaScript template literal does not automatically strip common leading indentation — every line is taken completely literally, so the source usually cannot be indented to match the surrounding code without that indentation leaking into the string.

This is a genuine gap in JavaScript: unlike Perl's sprintf/printf (inherited from C) and Python's % operator, JavaScript has no built-in format-string function whatsoever. Formatting falls to a combination of number methods — .toFixed() for decimal places, .toString(16) for a different base — and general-purpose string padding methods, .padStart() and .padEnd(), introduced in ES2017. Node.js does ship a util.format() helper with limited %s/%d support, but it is not available in the browser and covers far fewer format specifiers than Perl's sprintf.

JavaScript's string.split(separator) and array.join(separator) map directly onto Perl's split/join, with the call target and separator swapped: Perl calls join($separator, @list) as a standalone function, while JavaScript calls list.join(separator) as a method on the array itself. Getting Perl's special-cased split ' ', $string whitespace-collapsing behavior in JavaScript needs an explicit .trim().split(/\s+/) — there is no single built-in call that both trims and collapses runs of whitespace the way Perl's bare-space form does.

Perl string scalars are always mutable — .= appends in place with no restriction. JavaScript strings are immutable by design and always have been — every operation that looks like mutation, including +=, actually creates a new string and rebinds the variable to it. This has real performance implications for a loop that builds up a string incrementally in a hot path; the idiomatic fix is collecting pieces in an array and calling .join("") once at the end, rather than repeated concatenation.

Both languages have exactly one general-purpose numeric type at the source level: Perl's scalar draws no distinction between integer and floating-point values, and JavaScript's number is always a 64-bit IEEE 754 double, whether it holds 42 or 3.14. Both also lose precision on very large integers in the same way — 2 ** 64 is not computed exactly in either language, since neither has arbitrary-precision integers built into its default numeric type. JavaScript does offer the separate BigInt type (42n) for exact large-integer arithmetic when it is explicitly needed, which Perl has no equivalent for.

Both languages' / always performs floating-point division regardless of operand types — getting a truncated integer result needs an explicit call, int(...) in Perl and Math.trunc(...) in JavaScript. The two languages disagree on the sign of % with a negative operand, though: Perl's modulo takes the sign of the right operand, so -7 % 3 is 2, while JavaScript's % is a true C-style remainder operator that takes the sign of the left operand, so -7 % 3 is -1. This is a genuine trap for a Perl programmer porting modulo-based logic (like wraparound indexing) without adjustment.

Both languages check parity and sign with inline comparison expressions — there is no dedicated even?-style predicate method in either. Perl's abs is a standalone built-in function, while JavaScript groups nearly all of its numeric functions under the Math namespace object — Math.abs(), Math.floor(), Math.max() — rather than exposing them as free-floating global functions. JavaScript has no native integer range syntax matching Perl's 0..2; the classic C-style three-part for loop is the idiomatic replacement for a fixed count of iterations.

Perl coerces strings to numbers implicitly in numeric context — "42" + 0 just works, with warnings if the string does not look numeric. JavaScript also coerces implicitly with +, but in the opposite direction from Perl for mixed operands: since + is overloaded for both addition and string concatenation, "42" + 0 in JavaScript produces the string "420", not the number 42 — the explicit Number("42") conversion is the safe, unambiguous choice. parseInt(string, radix) takes an explicit base argument, just like Perl has no dedicated hex()-equivalent single function; going the other direction, (number).toString(16) replaces Perl's sprintf("%x", ...).

This is one of the closer conceptual matches in the whole comparison. Perl arrays and JavaScript arrays are both heap-allocated, dynamically sized, and freely heterogeneous — a single JavaScript array can mix a number, a string, and another array with no wrapper needed, exactly like a Perl @array can mix a number, a string, and an array reference. The mechanical difference is sigil consistency: Perl declares an array with @numbers but reads a single element with $numbers[0], while JavaScript uses the same bare name numbers everywhere regardless of whether you are addressing the whole array or one element.

Perl supports negative indexing directly in ordinary bracket notation ($numbers[-1]), but bare bracket access in JavaScript does not: numbers[-1] silently returns undefined, since JavaScript treats -1 as an object property key rather than an offset from the end. The modern .at() method, added in ES2022, is the correct way to negatively index a JavaScript array. Slicing is where the two diverge as well: Perl's @numbers[1..3] range slice is inclusive on both ends, while JavaScript's .slice(1, 4) is half-open — the stop index is exclusive — so getting the same three elements (indices 1 through 3) requires writing 4, not 3, as the stop argument.

This is a rare case where the vocabulary matches exactly: JavaScript's array methods are named push, pop, shift, and unshift, the identical names Perl uses for the identical operations — a Perl programmer can guess these method names correctly without ever having seen JavaScript before. The only mechanical difference is that JavaScript calls them as methods on the array object (items.push(4)) rather than as standalone functions taking the array as an argument (push @items, 4).

Perl's sort defaults to string comparison — sorting numbers correctly requires the explicit { $a <=> $b } comparator block, a common beginner trap. JavaScript's .sort() has the exact same trap: with no comparator it also sorts as strings ([10, 9].sort() yields [10, 9] unchanged, since the string "10" sorts before "9"), so a numeric comparator function is just as necessary as Perl's. Both .sort() and .reverse() mutate the array in place in JavaScript, unlike Perl's sort/reverse which return new lists — spreading into a fresh array first ([...numbers]) avoids mutating the original. JavaScript has no built-in uniq either, but the Set constructor, which discards duplicates while preserving insertion order, is the idiomatic order-preserving de-duplication trick — no import needed, unlike Perl's CPAN-distributed List::Util.

Perl needs the CPAN-distributed core module List::Util to get reduce and sum0 — these are not built into arrays themselves. JavaScript's .reduce() is a genuine built-in Array method requiring no import at all, and it covers both use cases at once (there is no separate sum method — summing is simply .reduce() with an addition callback and an initial value of 0). Always pass an explicit initial value as the second argument to .reduce(); omitting it uses the array's first element as the seed instead, which silently changes behavior on an empty array.

Perl's map and JavaScript's .map() share both a name and a purpose, and Perl's grep is JavaScript's .filter() under a different name — the exact same two operations, just spelled differently for the filtering half. Perl's chained form reads right-to-left (the grep filter runs before the outer map transform, even though map is written first), while JavaScript's method-chaining syntax reads left-to-right in call order: .filter(...).map(...) filters first, then transforms, in the same order the code is written.

Just as with arrays, Perl declares a hash with the % sigil but reads an individual value with $scores{alice}, while JavaScript uses one bare name (scores) for the whole structure and either dot notation or bracket notation to reach inside it. JavaScript object literals use : between key and value where Perl's fat comma => plays the same visual role, and — like Perl since 5.18 randomized hash ordering for security — a plain JavaScript object's string-keyed properties preserve insertion order in modern engines, though counting keys always needs the explicit Object.keys(...).length rather than a direct property on the object.

Perl's exists checks for key presence without triggering autovivification. JavaScript's in operator plays the same role, checking a property name's existence on the object — including inherited properties from the prototype chain, which Object.hasOwn(config, "missing") excludes if that distinction matters. JavaScript's ?? nullish-coalescing operator (ES2020) mirrors Perl's // defined-or default pattern closely, though ?? only falls through on null/undefined rather than Perl's broader "undefined" check; accessing a missing key directly (config.missing) returns undefined rather than throwing, similar to how Perl silently returns undef.

Perl's keys and values functions have direct JavaScript equivalents (Object.keys(), Object.values()), though JavaScript calls them as static methods on the Object constructor rather than as free-floating functions. Where a Perl programmer loops with for my $key (keys %hash) and then looks up $hash{$key} inside the loop, Object.entries() yields both the key and value together as a two-element array in one step, unpacked directly via destructuring into [name, score] — no separate lookup needed.

Both Perl hashes and plain JavaScript objects share the same limitation: every key is silently coerced to a string, so a Perl programmer already knows to be careful using a reference as a hash key (it stringifies to its memory address, not something useful to compare later). JavaScript's dedicated Map class, introduced in ES2015, removes that limitation entirely — any value, including an object or an array, can be a key with no coercion and no collision, something Perl has no built-in equivalent for at all without reaching for a CPAN module like Hash::Util::FieldHash.

Perl's autovivification lets $word_count{$_}++ spring a missing key into existence and treat undef as 0 for the increment — implicit and occasionally surprising. JavaScript has no autovivification at all; incrementing a missing property needs the explicit ?? 0 nullish-coalescing default shown here, since undefined + 1 would otherwise produce NaN. The object spread operator { ...defaults, ...overrides } (ES2018) is the modern equivalent of Perl's (%defaults, %overrides) list-flattening merge, with later keys winning in both.

This is the single biggest conceptual difference between the two languages, and JavaScript has no trace of it whatsoever — the same is true when comparing Perl to almost every other mainstream language. In Perl, the same expression (@animals, or a parenthesized list) evaluates differently depending on whether it appears in a context that wants one value (scalar context) or many (list context) — assigning an array to a scalar silently gives you its length, but assigning a literal list (1, 2, 3) to a scalar gives you its last element, not its count. JavaScript expressions always evaluate to exactly one thing, and getting a count always means reading the explicit .length property. This eliminates an entire category of Perl surprises, but it also means JavaScript cannot express Perl's occasionally-useful "give me count here, list there" idiom without writing it out explicitly.

Perl's wantarray lets a subroutine inspect the context it was called in and return a different value (or even a different shape of value) depending on whether the caller wants a list, a scalar, or nothing (void context). JavaScript has no equivalent mechanism whatsoever — a function always returns the same value, and it is entirely up to the caller to decide what to do with it (index into it, read .length, or use the whole thing). This is simpler to reason about but means the same expressive trick Perl uses for dual-purpose subroutines must be written as two differently named functions in JavaScript.

Perl offers several implicit ways to coerce an array into its count — numeric context, string concatenation, or the explicit scalar() function all work. JavaScript offers none of these shortcuts: attempting to interpolate an array directly into a template literal prints its comma-joined contents (10,20,30,40), not its length, so items.length must always be read out explicitly, whether inside a template literal or anywhere else.

JavaScript spells the middle branch as two full words, else if, rather than Perl's single contracted keyword elsif — technically JavaScript has no elseif keyword at all; it is simply an if statement nested as the body of an else, which happens to read the same way. Braces and their placement work identically in both languages, and — unlike Python — indentation carries no syntactic meaning in either Perl or JavaScript, so this is one of the more comfortable, low-friction sections for a Perl programmer.

This is a real loss for a Perl programmer: JavaScript has neither an unless keyword nor a postfix statement-modifier form for if at all — Ruby borrowed both of these directly from Perl, but JavaScript never adopted either. Every conditional guard must be written as a full if (...) { } block, even for the simplest one-line guard clause that Perl would express as statement unless condition;. JavaScript does have a conditional (ternary) expression (condition ? valueIfTrue : valueIfFalse), but it produces a value for assignment rather than gating a statement, so it is not a substitute for the postfix-modifier idiom.

Perl's numeric range 1..5 has no single built-in JavaScript equivalent — Array.from({ length: 5 }, (_, index) => index + 1) is the standard workaround for generating a counting sequence, considerably more verbose than Perl's range syntax. Perl's character range "a".."e" has no JavaScript equivalent either: a character sequence must be built manually via .charCodeAt() (character to code point) and String.fromCharCode() (code point to character) — the same genuine ergonomic gap Python has, since neither language's range machinery understands characters the way Perl and Ruby's do.

Both languages have a while loop with the same semantics, and both keep C-style ++/-- increment and decrement operators (Ruby dropped these, but Perl and JavaScript both kept them). JavaScript has no until keyword at all (Ruby has one, borrowed from Perl, but JavaScript never adopted it) — "loop while some condition is false" must always be written as a negated while.

Perl once had an experimental given/when construct but removed it due to design problems with smart matching, leaving Perl programmers to fake it with a for ($topic) { if (...) { ...; last } } loop. JavaScript's switch statement is a direct, permanent equivalent, though it comes with one sharp trap of its own: cases fall through to the next case by default unless each one ends with an explicit break — stacking bare case labels (as with "east"/"west" here) is the idiomatic way to group several values under one branch, but forgetting a break anywhere else silently runs the following case's code too.

Perl subroutines receive all arguments bundled into the single array @_ and must manually unpack them with my ($number) = @_; — there is no way to name parameters in the signature itself in the widely-used, portable syntax. JavaScript functions declare named parameters directly (function square(number)), so there is no unpacking step — a large ergonomic win for a Perl programmer, though JavaScript still requires an explicit return statement (unlike Ruby, which implicitly returns the last expression) since JavaScript has no implicit-return convention for ordinary function declarations.

Perl's anonymous subroutine (sub { ... }) needs the explicit -> arrow to be called ($square->(7)), since a code reference is just another kind of reference requiring dereferencing. JavaScript's arrow function syntax (ES2015) is considerably terser for the common case of a single-expression callback — (number) => number * number needs no return keyword, no braces, and no explicit call-through-a-reference syntax; it is called exactly like an ordinary function, square(7). Arrow functions are also the idiomatic way to write the transform passed to .map(), playing the same role as Perl's { $_ * 2 } block passed to map.

Perl has no default-parameter syntax in the subroutine signature — the idiomatic approach is unpacking positionally from @_ and then using //= (defined-or assignment) to fill in a default for any argument left undef. JavaScript supports default values directly in the function signature (greeting = "Hello"), evaluated once per call whenever the argument is undefined — a genuinely simpler model than Python's equivalent feature, since JavaScript re-evaluates the default expression fresh on every call rather than once at function-definition time, avoiding Python's well-known mutable-default-argument trap.

Neither language has true keyword arguments as a core language feature the way Python does — both simulate them by accepting a single collection of key-value pairs and unpacking it. Perl unpacks a flat list into a hash (my (%args) = @_;); JavaScript instead accepts a single object parameter and destructures it directly in the function signature ({ name, age, city = "Unknown" }), which additionally allows a default value to be declared right at the destructuring site — a slightly more compact idiom than Perl's separate // default-fallback line for each key.

Since Perl subroutines already receive every argument in the flat list @_, "variadic" just means unpacking all of it into an array (or a hash, for key-value pairs) rather than a fixed number of named scalars. JavaScript's rest parameter syntax, ...items, makes the intent explicit in the signature itself and reuses the exact same triple-dot punctuation as the spread operator seen earlier — collecting every remaining positional argument into a genuine array. There is no dedicated keyword-argument-collecting rest syntax analogous to Perl's hash-unpacking idiom; passing a single object parameter, as in describe here, is the idiomatic JavaScript substitute.

Perl's hash slice, @person{qw(name city)}, pulls several values out of a hash in one expression, playing a similar role to JavaScript's object destructuring, { name, city } = person. JavaScript goes further by supporting renaming directly at the destructuring site ({ name: personName } binds the value of the name property to a differently-named local variable), something Perl's hash-slice syntax has no equivalent shortcut for — a Perl programmer would need a separate assignment line per renamed variable.

Perl has no destructuring syntax that reaches into nested data structures at all — pulling a deeply nested value out always means chaining explicit dereferences one level at a time ($response{data}{user}{name}), which is at least straightforward even if verbose. JavaScript's destructuring pattern can mirror the shape of a nested object directly, reaching straight through multiple levels in a single binding — genuinely convenient once the shape is memorized, though the deeply nested pattern syntax itself takes some getting used to and can become difficult to read past two or three levels.

This is a feature with no Perl equivalent whatsoever: Perl's string interpolation is always evaluated the same fixed way by the interpreter itself, with no hook to intercept or transform the pieces before they are joined. JavaScript's tagged templates let a function placed immediately before a template literal (escapeHtml`Hello, ${name}!`) receive the literal string segments and the interpolated values separately, before they are concatenated, and decide how to combine them — the mechanism behind libraries that auto-escape HTML or SQL injection risks directly in ordinary-looking template literal syntax.

This is the most consequential structural difference between the two languages, after context sensitivity. Perl distinguishes plain values from references explicitly: creating one needs the \ operator, and reading through one needs either the -> arrow or a sigil-based dereference like @$array_ref — the reference-ness of a variable is always visible in the syntax used to touch it. JavaScript has no separate reference type or reference-creation operator at all: every array and every object is a reference by nature, assignment never copies one, and reading or writing through it uses the exact same bracket or dot syntax as any other value — there is nothing that visually marks a variable as "a reference" the way Perl's sigils and arrows do.

This is where Perl's explicitness becomes a real safety feature: assigning one Perl array to another with @copy = @original always copies every element, and only an explicit reference assignment shares the underlying storage. JavaScript has no plain-value assignment mode for arrays or objects at all — const assigned = original always shares the same underlying array, full stop, since there is no non-reference way to hold one in the first place. A genuine copy requires an explicit operation, most commonly the spread operator ([...original]), and forgetting this is one of the most common sources of action-at-a-distance bugs for programmers arriving in JavaScript from a language with an explicit copy-by-default semantics like Perl's arrays.

Both languages can freely nest arrays inside hashes/objects and vice versa to arbitrary depth, and the reading syntax ends up looking almost identical ($company{employees}[0]{name} versus company.employees[0].name). The underlying mechanism is different, though: Perl's hash and array values are implicitly references the moment they are nested this way (an @array cannot literally live inside a %hash value slot — only a reference to one can), while every JavaScript array and object nests directly, since arrays and objects are always reference types in JavaScript with no separate reference-taking step ever required.

Both languages treat a regular expression as a genuine literal syntax, delimited by forward slashes, rather than a string that must first be compiled — a real similarity, since JavaScript inherited its regex literal syntax directly from Perl through the shared lineage of early web scripting languages. The mechanical difference is in how a match result is obtained: Perl's =~ binding operator matches in place and populates $1, $2, and so on with capture groups, while JavaScript's .match() method returns an array-like result object where the whole match is index 0 and captures follow at index 1, 2, and so on — no special variables involved.

Perl's s/pattern/replacement/g operator performs the substitution in place on a copy (the (my $replaced = $text) =~ s/.../ idiom copies first, then substitutes destructively). JavaScript's .replaceAll() method (ES2021) is a pure function that always returns a new string, leaving the original untouched — there is no destructive substitution operator in JavaScript at all, matching the language's general preference for immutable-feeling string operations. Counting matches has no dedicated syntax in JavaScript comparable to Perl's clever my $count = () = $text =~ /pattern/g; list-context assignment trick; the idiomatic JavaScript approach falls back to .match() with the global flag and reading the resulting array's .length.

Named capture groups are spelled identically in both languages — (?<name>...) — since JavaScript's regex engine (added in ES2018) directly copied Perl's named-capture syntax rather than inventing its own. The only real difference is where the captured values end up: Perl populates the special hash %+, accessed as $+{year}, while JavaScript attaches a .groups object directly onto the match result, accessed as match.groups.year — no separate global variable to remember.

Both split functions accept a regular expression directly as the separator, and the behavior is identical here — a genuine, low-friction similarity. Perl's split is a standalone function taking the string as its second argument, while JavaScript's .split() is a method called on the string itself, but otherwise the mental model transfers with no adjustment needed.

This is where a Perl programmer will feel real envy. Perl OOP is built manually from two separate primitives: a package to hold the namespace, and bless to associate a plain hash reference with that package so it is recognizable as an object — every constructor is hand-written. JavaScript has a genuine native class keyword (ES2015), which is syntax sugar over the same prototype-based object model underneath, but the sugar is thick enough that it reads almost like a class-based language: constructor() replaces Perl's hand-written new subroutine, and this.name = name replaces the manual bless { name => ... }, $class pattern.

Perl has no built-in accessor generation at all — every getter and setter is hand-written, often using the combined pattern shown here where the same method acts as both getter and setter depending on whether an argument was passed, and Perl has no true privacy either (a leading underscore is purely a naming convention that nothing enforces). JavaScript's public fields need no accessor methods whatsoever — direct property assignment, as with person.age = 31, works with no method call — while the #-prefixed private field syntax (ES2022) is a genuine language-enforced privacy mechanism, unlike Perl's underscore convention: accessing person.#name from outside the class is a hard SyntaxError, not merely bad manners.

Perl declares inheritance by populating the special array @ISA with parent package names (or, in modern Perl, the more readable use parent 'Animal'; pragma). JavaScript uses the extends keyword directly in the class definition — a single-inheritance declaration built into the syntax, closer to Ruby's < than to Perl's array-based mechanism. JavaScript's instanceof operator replaces Perl's isa method call for checking ancestry, and both languages support calling the parent's overridden method — Perl's SUPER::method, JavaScript's super.method().

JavaScript has no true operator-overloading protocol for a custom class at all — unlike Perl's use overload pragma, there is no way to make JavaScript's built-in + operator invoke a method on a custom object; addition between two Money instances must be an explicit method call like .add() rather than total + other. Where the languages do align is stringification: JavaScript's toString() method plays exactly the role Perl's '""' overload entry plays, and JavaScript needs no separate pragma to opt in — any class simply defining toString() is automatically called wherever the object is coerced to a string, such as inside a template literal.

die is Perl's throw; a bare eval { } block is the try-block equivalent of JavaScript's try/catch. JavaScript's error-handling ergonomics are a real improvement over Perl's global-variable-based approach: the caught error object is bound directly to a local variable at the point of the catch clause (catch (error)), with no equivalent of Perl's easy-to-forget or easy-to-accidentally-clear $@ global to check manually. JavaScript also permits throw-ing any value at all, not only an Error object, though throwing a proper Error (or a subclass of it) is always the idiomatic choice since it carries a stack trace.

Perl can die with a blessed object instead of a plain string, letting the catch-equivalent branch on ref($error) && $error->isa("ValidationError") to distinguish error types — a manual pattern with no dedicated exception-class hierarchy backing it. JavaScript's built-in Error class is designed to be subclassed directly: extends Error plus a super(message) call in the constructor produces a genuine exception type complete with a stack trace, and instanceof checks the class hierarchy natively rather than relying on Perl's isa method convention.

Perl has no dedicated cleanup block syntax — guaranteeing cleanup code runs whether or not die was called requires either careful manual bookkeeping (saving $@ immediately, since a later operation can silently clear it) or a module like Try::Tiny or core Feature::Compat::Try's finally block. JavaScript's try/catch/finally has a dedicated finally clause built directly into core syntax: code inside it always runs, whether the try block completed successfully, threw an exception that was caught, or even if the catch block itself returned or re-threw — no manual state-saving required.

This is a genuine, structural JavaScript advantage over Perl: JavaScript's Promise is a language-level primitive representing "a value that will be available later," with the entire runtime built around a single-threaded event loop that resolves promises as their underlying work completes. Perl has nothing comparable in the core language — asynchronous work in Perl means either blocking calls that stall the whole process, or reaching for a CPAN event-loop module like AnyEvent or IO::Async and structuring code around explicit callbacks, a strictly more manual and error-prone style than a built-in Promise.

JavaScript's async/await keyword pair (ES2017) lets asynchronous code read almost exactly like synchronous code, while still yielding control back to the event loop at every await point — Perl has no core-language equivalent whatsoever, and even CPAN's best event-loop modules require either nested callbacks or coroutine-style tricks to approximate the same readability. The immediately-invoked async arrow function wrapping the final call here is a common idiom for using await at the top level of a plain script, since node -e and older module systems do not permit a bare top-level await outside an async function.

Promise.all() runs every promise in the array concurrently and resolves once all of them have settled, returning their results in the same order they were passed in — a built-in primitive for "fan out several independent operations, then wait for all of them," with genuinely no Perl core-language equivalent. A Perl programmer would need a CPAN event-loop module such as Mojo::IOLoop or AnyEvent, each with its own bespoke API for the same pattern, whereas every JavaScript environment (browser or Node.js) ships Promise.all() as a language-level built-in with no import needed.

Perl opens a file handle with a three-argument open call and reads it line by line with the diamond operator <$file_handle> inside a while loop, closing it explicitly afterward. JavaScript has no built-in filesystem access in the browser at all — file I/O is only available in a server-side runtime like Node.js, via the node:fs module — and the modern idiomatic approach reads the whole file at once with a promise-based readFile() rather than streaming it line by line, then splits the result into lines afterward. Both sides assume a data.txt file already exists on disk, so neither can run in the sandboxed backends used by this page.

Perl opens the file handle in write mode with the > mode string, prints directly to the handle, and closes it explicitly. Node.js's fs/promises module collapses the open-write-close sequence into a single writeFile() call, which handles opening and closing the file descriptor internally — there is no separate handle object for the caller to manage or remember to close, at the cost of always writing the entire content in one call rather than streaming it incrementally.

Perl's @ARGV contains exactly and only the user-supplied command-line arguments, indexed from 0. Node.js's process.argv includes two extra leading entries — the path to the Node executable itself and the path to the script being run — so the equivalent of Perl's @ARGV is process.argv.slice(2), not the bare array; forgetting this offset is a common early mistake for a Perl programmer's first Node.js script.

Perl's %ENV hash and Node.js's process.env object play an identical role: both expose environment variables as a simple key-value collection, both support reading with a fallback default (Perl's //, JavaScript's ??), and both allow writing a new entry that is visible to child processes spawned afterward but never propagates back to the parent shell. There is no browser equivalent for process.env at all — environment variables are a Node.js-specific, server-side concept, since a web page has no access to the host operating system's environment.

CPAN (the Comprehensive Perl Archive Network) predates npm by roughly a decade and pioneered the idea of a central package repository with a dependency-declaration file — Perl's cpanfile and cpanm --installdeps plays the same role as npm's package.json and npm install. The biggest practical difference is scope: cpanm installs modules globally (or into a local::lib-managed directory) by default, while npm installs into a project-local node_modules directory by default, keeping each project's dependencies completely isolated from every other project on the same machine with no extra configuration needed.

Reproducible installs are a more recent, optional addition to the Perl ecosystem: Carton, modeled explicitly on Ruby's Bundler, generates a cpanfile.snapshot pinning exact resolved versions, but it is a separate tool a project must opt into. npm's package-lock.json is generated automatically by npm install with no separate tool required, and npm ci gives a genuinely stricter guarantee than Carton's workflow: it installs precisely what the lockfile specifies and fails outright if package.json and the lockfile have drifted apart, rather than silently resolving a new set of compatible versions.

Perl needs an explicit module — JSON::PP is bundled with core Perl since 5.14, but still requires an explicit use statement and function calls, encode_json/decode_json. JavaScript has JSON support built directly into the language with zero imports required at all: JSON.stringify() and JSON.parse() are global objects available everywhere JavaScript runs, a natural consequence of JSON's syntax having been derived directly from JavaScript object literal syntax in the first place (the "JS" in "JSON" is not a coincidence).