Swift.CodeCompared.To/JavaScript

The difference is what happened before it ran. The Swift line was type-checked and compiled; the JavaScript line was parsed and executed. Everything else on this page follows from that, including the parts where JavaScript is genuinely more convenient. Semicolons are optional in both — Swift ignores them and JavaScript inserts them for you, which is occasionally not where you meant.

A template literal uses backticks and \${…}; an ordinary "…" or '…' string does not interpolate at all, so forgetting the backticks gives you the literal text rather than an error. console.log takes several arguments and joins them with a space, matching print. Number formatting is the awkward one in both: String(format: "%.2f", value) becomes value.toFixed(2), and there is no equivalent of a format specifier inside the interpolation.

There is no compile, so a change is visible immediately, and the browser or a watcher reloads it for you — where a clean Xcode build of a mid-sized app is minutes. The cost is the one this whole page is about: nothing was checked, so a misspelled property name, a wrong argument count, and a value of entirely the wrong type all reach production and fail on the line that happens to use them. Most JavaScript teams buy some of that back with TypeScript, which is why /swift/typescript exists; this page is about the runtime underneath it, which is the same either way.

Both mark a suspending function async and require await at every call to one, so the function-coloring problem is identical and a Swift developer's habits transfer straight over. Two mechanical notes for this page. Swift has no sleep that takes milliseconds, and JavaScript has no sleep at all — setTimeout wrapped in a promise is the idiom, and you will write it constantly. And every asynchronous example here is wrapped in an async IIFE, (async () => { … })(), because Node's -e mode has no top-level await. What differs underneath is the whole rest of this section.

A synchronous loop in JavaScript blocks everything: no timer fires, no promise settles, no event is handled, and in a browser the page does not repaint or respond to a click. await does not help — it yields at suspension points, and a tight loop has none. So CPU work goes to a Web Worker (or a worker_thread in Node), which is a separate JavaScript realm communicating by message passing, with no shared memory except a SharedArrayBuffer. That is closer to a Swift actor than to a Swift thread. The practical rule: in Swift, async buys concurrency and parallelism; in JavaScript it buys only concurrency.

async let is Promise.all over two already-started calls, since calling a JavaScript async function starts it immediately — the same as Swift, and unlike Rust's inert futures. The difference is structure. async let is a child task: it cannot outlive the scope that declared it, and if the scope exits early the child is cancelled. A JavaScript promise has no scope and no parent; nothing waits for it and nothing cancels it. Calling an async function and not awaiting the result gives you a floating promise that runs unobserved, and if it rejects you get an unhandled-rejection warning at best. Linters flag it (no-floating-promises) because the language will not.

A Swift Task has cancel(), cancellation propagates to every child, and Task.checkCancellation() or Task.isCancelled is how a loop cooperates — the same cooperative model, with the plumbing supplied. In JavaScript a promise is a value representing a result that will arrive; there is nothing to cancel, because the work is not owned by the promise. AbortController is the convention: you create one, pass its signal to everything that should observe it, and each operation checks or listens. fetch and most modern APIs accept a signal; anything you wrote yourself has to check it itself, exactly as above.

An actor serializes access to its own state and the compiler enforces it by making every access from outside async — that is why the calls above need await. JavaScript gets the same serialization for free from the single thread: a synchronous run of statements cannot be interleaved, so value += 1 is atomic in the only sense that matters. The genuine hazard that replaces the data race is the interleaving bug: any await is a point where other code runs, so state you read before an await may be stale after it. Swift has exactly the same hazard — actor reentrancy — so this instinct transfers; what does not transfer is worrying about torn reads or memory ordering.

JavaScript has an async generator: async function* with yield, which is a function containing the logic rather than a continuation you must remember to finish(). Swift has no async generator syntax, so producing a stream means AsyncStream and a continuation, and forgetting finish() hangs the consumer forever. Where Swift is ahead is the operator library: AsyncSequence has map, filter and prefix built in, while an async generator has no methods at all and you write the loop or reach for a library.

Every "why did my array change" bug a Swift developer has been protected from is available again. A JavaScript object is a reference and assignment copies the reference, so first and second are two names for one thing; arrays and every built-in container behave the same way. Note also that const is not let: it prevents reassignment of the binding and says nothing about the contents, so const first above still allowed the mutation. Swift's let on a struct freezes the whole value. The closest JavaScript comes is Object.freeze, which is shallow and silent — it ignores writes rather than rejecting them, unless the file is in strict mode.

Spread ({ ...original }) and Object.assign are shallow: they copy the top-level properties, so any nested object is still shared and mutating through the copy is visible through the original. That is the trap, and it is the default. structuredClone, available in every modern runtime, is a genuine deep copy and handles cycles, Map, Set and dates — but not functions or class identity. A Swift struct copies deeply and for free because everything inside it is also a value; here you choose, per copy, and the cheap choice is the wrong one more often than not.

The two columns are the same two lines and the first one disagrees, which is the whole row. There is no structural equality operator and no Equatable to conform to — comparing two objects by value means comparing the fields yourself, or serializing both (which is order-dependent and silently wrong for anything non-JSON), or using a library such as lodash's isEqual. The consequence reaches further than it looks: array.includes(someObject), Set membership and Map keys all use identity, so two structurally identical objects are two different Set entries. Always use === rather than ==, which converts its operands first and produces results nobody defends.

Object.freeze prevents adding, removing and changing top-level properties, and it is shallow, so a nested object is still mutable. It also fails silently outside strict mode — the assignment does nothing and no error appears, which is worse than either alternative; inside a module or a class body, which are always strict, it throws. The pattern the ecosystem settled on instead is convention: never mutate, always produce a new object with spread ({ ...frozen, x: 99 }), and let a linter enforce it. That is what React state and every Redux-shaped store require, and it is why a Swift developer's value-semantics instincts are a genuine asset in modern JavaScript even though the language does not help.

undefined is what you get from a property that was never set, a missing argument, or a function with no return. null is a value someone assigned deliberately to mean "nothing here". The convention most codebases settle on is to produce null yourself and treat undefined as "absent", but nothing enforces it and JSON has only null, so both appear. Crucially there is no String?: the annotation is gone, the compiler is gone, and calling .length on either throws TypeError: Cannot read properties of undefined at the point of use — the error a Swift developer has not seen since they stopped writing Objective-C.

?. short-circuits the whole chain to undefined — note undefined, not null, whichever the left side was — and it works on calls (obj.method?.()) and indexes (array?.[0]) as well as properties, which Swift does not need because a missing method is a compile error. ?? is the nil-coalescing operator and fires only on null or undefined, so it matches Swift exactly. The trap is ||, which fires on any falsy value — 0, "", NaN, false — and was the only option before ?? shipped in 2020, so older code is full of defaults that trigger on a legitimate zero.

There is no unwrapping, because there was no wrapper: name is the value or it is null, and the if is a check rather than a bind. What is worth stealing is the == null comparison, which is the one place == is genuinely preferable to ===: loose equality treats null and undefined as equal to each other and to nothing else, so value == null is exactly "is this one of the two nothings". Writing if (!name) instead is the common mistake, because it also fires on "" and 0.

Integer division must be written out (Math.trunc(a / b) or a / b | 0), because / always produces a fraction. Integers are exact only up to Number.MAX_SAFE_INTEGER — 2⁵³−1, about 9 quadrillion — and past that they silently lose precision rather than overflowing, which is why the second-to-last line prints an even number. BigInt (the n suffix) is the arbitrary-precision escape hatch and does not mix with ordinary numbers in arithmetic. On the other side, there is no overflow trap: a Swift Int overflow crashes the process, and a JavaScript number simply becomes Infinity.

+ means concatenation if either side is a string and addition otherwise, so "3" + 3 is "33" while "3" - 3 is 0, because - has no string meaning and coerces instead. The defense is the same in every codebase: convert explicitly with Number(…), String(…) and parseInt(…, 10), and use === everywhere so comparison never coerces. This is the single most-mocked part of the language and it is also entirely avoidable in code you write; where it bites is code you did not write.

typeof returns one of a small set of strings and famously reports "object" for null — a bug preserved since 1995 for compatibility — and also for arrays, which is why Array.isArray exists as a separate function. instanceof checks the prototype chain and works for classes, but fails across realms (an array from an iframe is not instanceof Array there). There is no as?, because there is nothing to cast: an object either has the property you are about to use or it does not, and asking is "name" in value or value.name !== undefined. That is duck typing, and the protocols section is where it really shows.

JSONDecoder validates against the declared type and throws on a missing or mistyped field, so a decoded value is a value you can trust. JSON.parse validates only that the text is JSON; the result is a plain object with whatever the server sent, and a missing field is undefined that surfaces as a TypeError three functions later. The idiomatic answer is a runtime validation library — Zod, Valibot, ArkType — which is a schema you declare and call, doing at run time what Codable does at compile time. Two smaller notes: JSON has no date type, so Date round-trips as an ISO string and needs a reviver; and JSON.stringify silently drops undefined values and functions.

Months are zero-based and days are not, so new Date(2026, 7, 19) is August. A Date is mutable, so setUTCDate changes the object in place and a shared one is a bug waiting to happen — hence the explicit copy above. And a Date is an instant with no time zone attached; the local zone leaks into every non-UTC method and into the string constructor, which parses some formats differently across runtimes. Intl.DateTimeFormat is the good part and is what DateFormatter corresponds to. The successor is Temporal, which brings immutable types with explicit calendars and zones — much closer to Foundation's model — and is shipping in runtimes now.

The Swift version cannot compile with a case missing and cannot be handed a value that is neither. The JavaScript version compiles nothing, accepts { kind: "typo" } without complaint, and reaches the default at run time — and if you forget the default it returns undefined and fails somewhere else entirely. The discriminant field is conventionally called kind or type; nothing requires either. If the project uses TypeScript this becomes a real discriminated union with exhaustiveness checking, which is the single strongest argument for adopting it and is covered on /swift/typescript rather than here.

Object.freeze stops the constants being reassigned, which is the only guarantee available. Iteration is Object.entries rather than allCases; the reverse lookup that Priority(rawValue: 3) does is a find over the keys; and behavior attached to a case becomes a free function taking the value, since the value is a plain number with no identity of its own. Nothing prevents a caller passing 7 where a Priority was expected. The other common idiom is a bare string union — passing "high" directly — which is cheaper to write, prints readably, and offers exactly as much protection.

There is nothing to declare and nothing to conform to: an object with a speak works, and one without it throws TypeError: thing.speak is not a function when the loop reaches it — which may be in production, on the third element, after two side effects have already happened. That is the whole trade. What duck typing buys is real flexibility: any object can be made to satisfy any expectation after the fact, no adapter type is needed, and there is no equivalent of the any Speaker versus some Speaker distinction because there is no static dispatch to choose. Testing is where it shows most — a fake is an object literal with the three methods the code touches.

A method lives on the prototype object, and an instance delegates to it at lookup time — so a method added to Animal.prototype later is immediately available on every existing instance, which is the monkey-patching Swift extensions were designed to make safe. There is no override keyword, so a misspelled method name silently defines a new one rather than failing to compile, and no final. Fields prefixed with # are genuinely private — a real hard error from outside — where the older underscore convention was documentation. There is no protocol to implement and no multiple inheritance; the mixin idiom is copying methods onto a prototype.

Pull a method off an object and call it on its own — pass it as a callback, hand it to setTimeout, use it as an event handler — and this is no longer the object; in a class body, which is strict mode, it is undefined and the call throws. The fix is either an arrow function, which has no this of its own and closes over the surrounding one (which is why makeIncrementer works above), or .bind(this), or defining the method as a class field holding an arrow. Arrow functions are the reason this problem is largely historical in new code, and knowing the rule is still necessary to read anything older.

A Swift extension is resolved statically and is scoped by import, so two libraries adding isPalindrome to String cannot collide. Patching String.prototype changes the string type for the entire program, permanently, including every library in it — and if a future JavaScript version adds a method with your name, your version silently wins and breaks code written against the standard one. That has happened; Array.prototype.flatten had to be renamed to flat because a popular library had taken the name. The accepted answer is a free function, which is why the right column reads the way it does.

A computed property maps directly onto a get accessor, and a set accessor is the same idea with the incoming value named value rather than newValue. Swift's willSet and didSet have no counterpart: to observe a change here you must convert the field into a getter/setter pair with a private backing field, which is the shadow dance Swift removed. Note also that a getter is defined on the prototype, so it is shared by every instance, and that a plain object literal can carry one too ({ get area() { … } }). The Proxy object is the general-purpose interception mechanism, and it is far more powerful and far slower than any of this.

Duck typing does the work generics do: the function uses >, so it works on anything > works on, which is everything, because > coerces. That is why the third call returns an answer rather than an error, and the answer is meaningless — 3 > "apple" is false because the string converts to NaN. Swift's Comparable constraint is exactly what prevents that call from existing. There is also no some/any distinction and no monomorphization, because there is one compiled function and it does not know or care what it was given. TypeScript adds generics back at the type layer, which is /swift/typescript's subject rather than this page's.

JavaScript uses a tracing collector, so a cycle is collected as soon as nothing outside it is reachable. There is no weak, no unowned, no [weak self] in a closure, and no retain cycle to find in Instruments — the entire category is gone. What you lose is deinit: there is no deterministic destructor, no hook that runs when an object dies, and nothing you can rely on to close a file or cancel a subscription. FinalizationRegistry exists and the specification explicitly does not guarantee it ever runs. So cleanup becomes an explicit method somebody has to call, which is a real regression from a language where deinit could not be forgotten.

Anything still reachable is kept, so a long-lived registry holding a closure that captures a short-lived object keeps that object alive indefinitely — the same defect a Swift retain cycle produces, with a different cause and no [weak self] to fix it. The remedy is to unsubscribe: every addEventListener needs a matching removeEventListener, every interval a clearInterval, every subscription an unsubscribe. WeakMap, WeakSet and WeakRef exist for the cases where you genuinely want a reference that does not keep its target alive, and a WeakMap keyed on an object is the idiomatic way to attach data to something without extending its lifetime.

Swift counts extended grapheme clusters — everything a reader would call one character — so a three-person family emoji is 1 and a flag is 1. JavaScript's length counts UTF-16 code units, so the same family string is 8: three emoji at two units each, plus two zero-width joiners. Spreading the string ([...family]) iterates by code point and gives 5. Getting Swift's answer needs Intl.Segmenter, which is standard in modern runtimes and which nobody remembers exists. The practical consequence: any string truncation written against length will eventually cut an emoji in half.

There is no String.Index: text[3] and text.slice(4, 9) work directly, because a JavaScript string is a fixed-width array of UTF-16 units and the third one is at a known offset. That is exactly what Swift gives up in exchange for the grapheme guarantee in the previous row, and it is why slicing here is convenient and occasionally cuts a character in half. Note also that replace with a string argument replaces the first occurrence only — replaceAll, or a regular expression with the g flag, does what replacingOccurrences does.

The flags go after the closing slash: g for every match, i for case-insensitive, m for multi-line, u/v for Unicode. g is the one to watch, because a regex object with it carries a mutable lastIndex and reusing the same object across calls gives different answers — which is why matchAll exists and requires g. Captures come back as an array-like match object with the whole match at index 0, and named groups ((?<year>…)) land in .groups, which is the closest thing to Swift's typed regex output. What Swift has and JavaScript does not is RegexBuilder and compile-time-checked capture types.

Reading past the end gives undefined rather than crashing, which turns a loud failure into a quiet one that surfaces three functions later. Writing past the end extends the array and fills the gap with empty slots, so length becomes 11 and iteration sees holes. Assigning to length truncates. Because it is an object, an array can also carry non-numeric properties, which is legal and always a mistake. The methods themselves are good — map, filter, reduce, find, some, every, flatMap all match Swift's — and the newer toSorted, toReversed and with return copies rather than mutating, which is worth preferring for the reason the value-semantics section gave.

A plain object is the ubiquitous choice and has real problems as a dictionary: its keys are strings only (a number key is silently converted), it inherits properties from Object.prototype so ages.toString is a function rather than undefined, and counting entries needs Object.keys(…).length. Map is what a Swift Dictionary actually corresponds to — any value as a key, a real size, guaranteed insertion order, and no inherited keys — and it is underused because object literals are so convenient. Both give undefined for a missing key rather than trapping, which matches Swift's optional subscript. Object key order is mostly insertion order, except that integer-like keys are sorted first, so never rely on it.

Both are eager and build an intermediate array at each step. Swift's lazy makes a chain lazy; JavaScript has no equivalent on arrays, and the lazy option is an iterator or generator, which has none of these methods attached — so a lazy chain means writing a generator or reaching for a library. first(where:) is find, contains(where:) is some, allSatisfy is every, and compactMap is flatMap with the nils filtered, or map then filter(Boolean). reduce takes its initial value last in JavaScript, and omitting it makes the first element the seed, which fails on an empty array.

count is size, contains is has, and insert is add. The membership caveat from the equality section applies: a Set compares with ===, so two structurally identical objects are two entries. Conforming to Sequence becomes defining a method named [Symbol.iterator] that returns an iterator — and the shortest way to write one is a generator, function* with yield, which the compiler turns into the state machine that IteratorProtocol makes you write by hand. Anything with that method works in for…of, spreads with ..., and destructures.

It works on objects by property name, with renaming (age: years) and per-field defaults (city = "unknown") — none of which Swift can do for a struct, where destructuring is limited to tuples. On arrays it is positional with a rest element (...rest). It also works in a parameter list, which is what the options-object pattern in the functions section relies on, and it nests. The one trap: a default fires only on undefined, never on null, so { city = "unknown" } leaves an explicit null alone.

There are no range patterns, no where clauses, no tuple patterns and no binding — the switch (true) idiom above is how you get arbitrary conditions in, and it is standard rather than a hack. There is also no exhaustiveness: leaving out a case is silence, and forgetting break in a non-returning arm runs the next one too, which is a genuine and frequent bug. Most JavaScript in this shape is written as an if/else if chain or an object lookup (const label = { 0: "zero" }[value] ?? "large") instead, and both read better than the switch.

for…of iterates values and is the direct counterpart of for…in in Swift. JavaScript's for…in iterates the keys of an object, including inherited ones, and using it on an array gives you string indexes and any stray properties — it is almost never what you want. The C-style for (let i = …) is still the way to write a strided or descending loop, since there is no stride. entries() is enumerated(), and destructuring in the loop head works the same way as in Swift.

Exactly six values are falsy: false, 0 (and -0, and 0n), "", null, undefined and NaN. Everything else is truthy — including "0", "false", [] and {}, the last two of which surprise people who expect an empty container to be falsy the way it is in Python or Ruby. The practical hazard for a Swift developer is if (count) as a presence check, which treats a legitimate zero as absent; the fix is the explicit if (count != null) from the optionals section.

A label is an identifier followed by a colon in front of a loop, and break label or continue label targets it — identical to Swift. JavaScript also allows a label on a plain block, so break can jump out of a bare { }, which Swift does not. The reason to know this is that the alternatives are worse: Array.prototype.forEach cannot be broken out of at all (a return inside it is a continue), so a search over nested data written with forEach has to fall back to a flag variable. Prefer for…of whenever a loop might need to stop early.

The options-object pattern gets you readable call sites and order independence, and it is the standard idiom for any function with more than two or three parameters — including default values, written { from = "a1", to } in the parameter list. What it does not get you is any check: pass an object missing to and the parameter is undefined, pass a misspelled too and nothing complains. Calling a function with the wrong number of arguments is also legal — extras are ignored, missing ones are undefined — which is the arity check a Swift developer will most miss. Rest parameters (...squares) are variadics and are the one place JavaScript is tidier.

Reading the JavaScript call, you cannot tell whether numbers will change — the information Swift puts in both the signature and the & at the call is simply absent. The distinction that remains is the second example: reassigning the parameter rebinds a local name and the caller sees nothing, while mutating the object it points at is visible everywhere. Default parameter values work the same way in both, and JavaScript evaluates them on every call — left to right, so a later default may refer to an earlier parameter.

An arrow function is the modern form: (a, b) => expression returns the expression with no return, and a braced body needs one. There is no $0 shorthand, so every parameter is named. Everything goes inside the parentheses, so DispatchQueue.main.async { … }-style APIs read as setTimeout(() => { … }, 0). The comparator is the detail to carry over: JavaScript's sort takes a function returning a number (negative, zero, positive) rather than a Bool, and its default with no comparator sorts as strings — so [10, 9].sort() gives [10, 9]. Prefer toSorted over sort, which mutates in place.

There is no capture list, so [index] and [weak self] have no equivalent — copying a value means assigning it to a new local before the closure is created. Nor is there any need for weak, since the collector handles cycles. The one thing to know is the loop: let in a for head creates a fresh binding per iteration, so the three closures capture 0, 1 and 2 as a Swift developer expects, while the older var is function-scoped and all three see the final value. That was the most famous JavaScript interview question for a decade and let fixed it in 2015; the reason to know it is reading older code.

A JavaScript function that can throw looks exactly like one that cannot, and reading a block you cannot tell which lines might fail. catch takes no type, so a single handler receives everything and dispatching is a chain of instanceof checks — with the discipline that anything you did not expect must be re-thrown, or you have silently swallowed a programming error. Worse, throw accepts any value: a string, a number, undefined. Always throw an Error (or a subclass), because only those carry a stack trace, and error.cause is the modern way to chain one failure to another.

A rejected promise that nothing is awaiting or .catch()ing becomes an unhandled rejection: in Node it terminates the process by default, and in a browser it logs a warning nobody reads. That cannot happen in Swift, because a Task whose result is discarded still cannot throw past its boundary, and an unawaited async let is a compile error. The rule is that every promise must have an owner — awaited, returned, or explicitly given a .catch. Promise.allSettled is the tool when you want every result regardless of failures, and finally works on both a try block and a promise chain.

For one cleanup the two are equivalent, and finally runs on every exit path including a return from inside the try. Where they diverge is several cleanups in one scope: Swift stacks them and runs them in reverse, while JavaScript needs nested try/finally blocks and the indentation that implies. There is also no using-style scoped resource, though the explicit-resource-management proposal (using and Symbol.dispose) is landing in runtimes now and will be the closest equivalent to a Swift deinit-plus-scope that the language has ever had.

ESM (import/export) is the standard, supports top-level await, and is what a browser loads. CommonJS (require) is Node's original, is synchronous, does not support top-level await — and is what node -e runs, which is the constraint this page is written under. The visibility model is the reverse of Swift's: a Swift file shares its target's namespace and hides what is private, while a JavaScript module exposes nothing unless exported, and every file is its own scope. Which system a package uses is decided by "type": "module" in package.json and by the .mjs/.cjs extensions.

package.json is Package.swift and package-lock.json is Package.resolved; ^4.17.21 is the from: range. The differences are cultural and consequential. npm has a central registry rather than git URLs, which makes publishing trivial and name-squatting and typosquatting real supply-chain risks. Dependency trees are far deeper — a modest project easily pulls a thousand transitive packages, where a Swift one pulls a handful — so npm audit and lockfile review are routine work rather than an occasional check. On the other hand there is no build step to wait for, and npx runs a package without installing it.

The shapes are close: a test is a function with a name, and assertions are function calls. node:assert/strict uses ===-style comparison and deepStrictEqual for structures, which matters because of the identity-equality problem from earlier — comparing two objects with assert.equal compares references and passes only when they are the same object. Vitest and Jest are the common choices and bring watch mode, mocking and snapshot testing. Tests live beside the code (billing.test.js next to billing.js) rather than in a parallel tree, and they see whatever the module exports and nothing else.