Kotlin.CodeCompared.To/JavaScript

There is no compile step, so the first thing you learn about a mistake is when execution reaches it — including a misspelled method name. console.log takes several arguments and separates them with spaces, and writes to stdout; console.error writes to stderr. What has no counterpart is println's guarantee that the value has a sensible text form: console.log of an object prints an engine-specific rendering rather than calling anything you defined.

Two things do not carry over. There is no format and no format string at all: width, precision and padding are method calls on the value (toFixed, padStart, toLocaleString). And there is no sum(): reductions are reduce with an explicit initial value, which throws on an empty array if you omit it.

Adding a number to a string is a defined operation rather than a type mismatch, and a misspelled method is a TypeError reached only if that branch runs. Two consequences: your test coverage is now the type checker, and TypeScript exists to give some of it back — it is the same language with a checker on top, erased before execution. A Kotlin/JS build gives you the same guarantee from the Kotlin side, for the code you wrote in Kotlin.

undefined is what you get from a missing property, a missing argument, or a function with no return; null is what a programmer writes to mean "deliberately empty". ?? is the elvis operator ?: and treats both alike, which is what you want. Note typeof null is "object" — a fifteen-year-old bug that cannot be fixed without breaking the web. The idiomatic "is there anything here" test is value != null, which is true for exactly those two values and nothing else.

The JavaScript as written throws TypeError: Cannot read properties of null at run time, which is the whole point of the comparison — and why it is shown rather than run. There is no compiler to tell you, so the discipline moves into the code: ?. and ?? exist and read exactly like Kotlin's ?. and ?:, and the habit to keep is using them everywhere a value crossed a boundary. TypeScript with strictNullChecks restores most of the guarantee — it is the closest thing the platform has to what you are giving up.

?. stops the chain at the first empty and yields undefined rather than null, which matters only if you compare with ===. ?? is ?: and falls back only on the two empties, never on 0 or "" — unlike ||, which is the older idiom and the source of the classic "zero became the default" bug. There is also ?.[index] and ?.() for optional indexing and calling, which Kotlin has no need for.

?.let { } becomes an if; apply and also become plain statements; run and with become an IIFE if you really want an expression. it has no equivalent either — every lambda parameter is named. The nearest thing in spirit is optional chaining plus ??, and the honest advice is to stop reaching for the pattern rather than to reproduce it: JavaScript code that simulates apply reads worse than the four plain lines it replaced.

lateinit becomes nothing at all — an undeclared property is simply assigned, and reading it early gives undefined instead of the UninitializedPropertyAccessException that told you exactly what went wrong. by lazy becomes a getter with a cache, as above, and is not thread-safe because it does not need to be: there is one thread. Delegated properties in general (by) have no counterpart; the closest mechanism is Object.defineProperty or a Proxy, both of which are heavier than what they replace.

Kotlin's val stops reassignment, exactly as const does; what stops mutation is asking for List rather than MutableList. JavaScript has no read-only collection type at all, so a const array is fully mutable and the only run-time defence is Object.freeze, which is shallow. Use const by default — it is the linter default and the idiomatic choice — but do not read it as a promise about the value.

Kotlin's == calls equals (structural) and === is referential. JavaScript's === is Kotlin's ===, and JavaScript's == is neither — it converts its operands before comparing, which is why 0 == "0" is true and why the rule is to never write it. There is no structural equality for arrays or objects: two identical arrays are unequal, and the usual workaround is JSON.stringify on both, which is wrong for key order and for anything JSON cannot represent.

typeof answers for the seven primitives and is the one to use for strings, numbers and booleans; instanceof answers for classes and fails across realms (an array from an iframe is not instanceof Array, which is why Array.isArray exists). typeof null is "object" and typeof [] is "object". What is genuinely missing is smart casting: after typeof value === "string" nothing changes about what you may call — there is no type to narrow, so nothing stops you calling a string method in the wrong branch.

That name-based form is what Kotlin's data-class destructuring is often mistaken for and is not: reordering a Kotlin data class's properties silently changes what val (x, y) binds, while the JavaScript object pattern is immune. The array form adds ...rest, defaults, and nesting, and works in function parameters — which is how the options-object idiom stays readable. There is no componentN convention and no destructuring of arbitrary classes.

Any becomes "no annotation at all". Unit becomes undefined, which a function with no return yields — but where Unit is a real singleton value with a type, undefined is the same value you get from a missing property, so "returned nothing" and "that property does not exist" are indistinguishable. Nothing has no counterpart; a function that always throws simply has no return value to describe. TypeScript restores all three as unknown, void and never.

Division always produces a float, so integer division is Math.trunc(a / b) — or Math.floor, which differs for negatives exactly as Kotlin's floorDiv does. Integers are exact only up to 2⁵³ (Number.MAX_SAFE_INTEGER), past which additions silently round rather than wrapping as a Kotlin Int would. The bitwise operators convert to 32-bit signed integers first, which is the strangest corner of the type.

A Long cannot be represented exactly by a JavaScript number past 2⁵³, so Kotlin/JS compiles Long to a boxed implementation rather than a native number — correct, and not something you can hand to a JavaScript caller as a plain value. BigInt is the platform's arbitrary-precision integer, and it deliberately refuses to mix with number in arithmetic; it also cannot be JSON.stringifyd without a custom replacer. The practical advice for an exported API: use Int, or a String, and never a Long.

The nearest thing to (0..9).toList() is Array.from({ length: 10 }, (_, index) => index), which is worth knowing and not worth loving. Note the inclusivity trap while translating: Kotlin's .. includes its end and until excludes it, so a mechanical conversion to < is right for one and wrong for the other. Ranges are also where when loses power, which the sealed-classes section returns to.

uppercase() is toUpperCase(), contains is includes, joinToString is join (with no separator argument by default — it uses a comma, unlike Kotlin's ", "). The trap is replace: Kotlin's replaces every occurrence, while JavaScript's replace with a string argument replaces only the first — use replaceAll, or a /g regex, to get Kotlin's behaviour.

A JVM String and a JavaScript string are both sequences of UTF-16 code units, so "🦀".length is 2 in both: an emoji outside the Basic Multilingual Plane takes two units, and slicing between them produces a lone surrogate. substring(start, end) is slice(start, end), and slice additionally accepts negative indices counting from the end. There is no StringBuilder; engines optimise += internally, and the array-plus-join idiom is the explicit version.

What a template literal cannot do is trimIndent(): it keeps whatever leading whitespace the source had, which is why dedent libraries exist and why the example above is left-aligned. The regex engine is backtracking, so it has lookaround and backreferences and no linear-time guarantee. Flags go after the closing slash — g, i, u, s, m, y — and a g regex object carries mutable state in lastIndex, so reusing one across test calls gives alternating answers.

Reading past the end gives undefined rather than IndexOutOfBoundsException, and writing past the end extends the array with holes — a sparse array whose missing slots are skipped by forEach but counted by length. Avoid that entirely. Since there is no List interface to return, the convention for "do not modify this" is documentation, a copy ([...items]), or Object.freeze, which is shallow and silent outside strict mode.

Map takes any value as a key (objects compared by identity), preserves insertion order, has a real size, and has no inherited keys to collide with. A plain object coerces every key to a string — so 1 and "1" are one entry — and carries prototype properties, which is why Object.create(null) exists. Neither has getOrPut, mapValues or toSortedMap: those become explicit code, and iterating a Map in key order means spreading and sorting.

sum, chunked, zip, windowed, associateBy, partition, distinctBy, sumOf, maxByOrNull — none of those exist, and each becomes a reduce, a slice loop or a small helper. Object.groupBy and Map.groupBy (2024) are the one recent addition that closes a real gap. Note there is no it: every lambda parameter gets a name, which makes chains longer than Kotlin's.

So a three-step chain over a million elements makes two intermediate arrays where a Sequence would make none. Generators (function*, yield) are the lazy option and work with for...of and spreading — but they are not composable: there is no .take(10) or .map() on a generator, which is why the example counts by hand. The Iterator Helpers proposal adds exactly those and has shipped in current Node and Chrome.

So [10, 9, 100].sort() gives [10, 100, 9]. Always pass a comparator for numbers; it returns a negative number, zero or a positive one, which is compareTo's contract without the type. sortedBy { } becomes a comparator over the key. And sort mutates and returns the same array, unlike Kotlin's sorted() — toSorted() (ES2023) is the non-mutating version, along with toReversed, toSpliced and with.

Skipping a middle parameter is impossible positionally, so anything with more than two optional values takes a single object and destructures it in the parameter list — with = {} at the end so calling with no argument still works. That idiom is the JavaScript equivalent of named arguments and is worth adopting deliberately rather than discovering. Note also that extra arguments are silently ignored and missing ones become undefined: arity is never checked.

Every parameter must be named, and every lambda sits inside the parentheses — so the DSL-style html { body { ... } } that trailing lambdas make possible has no direct spelling. A JavaScript function is also an ordinary object with properties: length is its declared arity and name is its name. There is no distinction between a lambda and a function reference, and no inline, so every callback is a real allocation and a real call — which is why hot loops in JavaScript sometimes avoid them.

The mechanism differs underneath — Kotlin boxes the captured var in a Ref object, JavaScript keeps the whole scope alive — and the consequence is the same: a closure held by an event handler keeps everything it captured alive, which is the shape of most JavaScript memory leaks. Watch one trap that Kotlin does not have: capturing the loop variable of a C-style for captures the single shared variable, so use let (which gets a fresh binding per iteration) rather than var.

So passing counter.increment as a callback gives a function whose this is undefined, and the failure appears wherever the callback eventually runs. The fixes are bind, an arrow wrapper (() => counter.increment()), or defining the method as a class field holding an arrow function, which captures this lexically. An arrow function has no this of its own at all, which is exactly why it became the default for callbacks.

The JavaScript rest parameter gives you a real array — not Kotlin's Array<out T> with its primitive-array complications — and the spread operator works in array literals ([...first, ...second]) and object literals ({ ...defaults, ...overrides }) as well as in calls. That object spread is the everyday replacement for a data class copy(), which the classes section returns to.

this. is mandatory, and a property is created by assigning to it — there is no declaration to misspell against. Private fields exist now, marked with #, and are genuinely private (unlike the older underscore convention); reading one from outside is a syntax error rather than undefined. What has no counterpart is the property syntax: a Kotlin val with a custom getter becomes get area() { ... }, and there are no init blocks, no secondary constructors and no internal visibility.

There is no equals, so === compares identity and two identical objects are unequal; there is no toString, so console.log prints an engine-chosen rendering; and there is no hashCode, because a Map keys objects by identity anyway. For an equality test the usual workaround is JSON.stringify(first) === JSON.stringify(second), which is wrong for key order and for anything JSON cannot represent. What does survive, and survives well, is copy(): { ...first, y: 99 } is the object spread, and it is shallow exactly as copy() is. For deep equality you need a library or node:assert.

A companion object becomes static members on the class, which is closer to Java than to Kotlin: they are reached through the class name and cannot implement an interface. There is no object : SomeInterface { } expression either, because there is no interface to declare conformance to — an object literal with the right methods is accepted by anything that calls them, which is the next section's subject.

Duck typing removes both the ceremony and the guarantee: nothing warns you when an object is missing speak, and nothing tells you which objects are meant to have it. Default interface methods have no home, so shared behaviour goes on a base class, into a mixin (Object.assign(Target.prototype, behaviour)), or into a plain function taking the object. TypeScript restores interfaces — structurally, so a matching object literal satisfies one without saying so.

So a misspelled method name in a subclass silently becomes a new method rather than an error — exactly the bug override exists to prevent. super.speak() works as expected. Underneath there is no vtable: method lookup walks a chain of prototype objects at run time, so a method added to Animal.prototype after the objects exist is immediately available on all of them. That is monkey-patching, and it is the mechanism the extensions section compares against.

Nothing stops a third kind appearing, nothing checks that the payload matches the tag, and — the part that hurts most — nothing warns when a switch misses a case. That is why the default throws: it is the manual replacement for exhaustiveness, and it fires at run time rather than at compile time. TypeScript turns this exact pattern into a checked discriminated union with a never assertion in the default branch, which is much of why Kotlin developers writing web code reach for it.

So the direct translation is an if/return chain, which is what idiomatic JavaScript writes here anyway. The switch (true) { case code >= 400: ... } trick is real and common and reads worse. For a subject-based when over constants, switch is a fair match — remember that every arm needs return or break, since fall-through is the default rather than an opt-in.

The pieces you lose are the type (a parameter cannot be declared to accept only a Status), valueOf's validation, and entries. Object.freeze is shallow and, outside strict mode, silently ignores writes rather than throwing. The lighter version — const Status = { ACTIVE: "active" } with plain strings — is more common and interoperates better with JSON, at the cost of every comparison being a string comparison.

The tagged-object shape above is the convention, and it has the same drawback as every discriminated union here: nothing checks that you looked at ok before reading value. The alternative is to throw, which is what the standard library does everywhere — and unlike Kotlin, any expression can throw, including a property access on undefined, so a try block is about a region of code rather than about a specific call.

Assigning to String.prototype changes the string type globally and permanently for every script on the page, which is how libraries used to collide with each other and with future standards — the reason Array.prototype.flatten had to be renamed flat. Do not do it. The idiomatic replacement is a plain function taking the value as its first argument, which is exactly what Kotlin compiles your extension into anyway; the difference is only that the call reads shouted(text) rather than text.shouted().

A computed property on a type you do not own would mean Object.defineProperty on a built-in prototype — the same global mutation as the previous row, plus a getter. Infix calls simply do not exist: there is no way to define an operator or to call a two-argument function without parentheses, and operator overloading is absent too, so + on your own type is impossible. What JavaScript offers in exchange is that a plain function is always available and never conflicts with anyone.

toString is called by string interpolation and by +; toJSON is consulted by JSON.stringify, which is as close as this gets to a serialiser; Symbol.iterator makes a value work with for...of and spreading, which is Iterable. Note that console.log of an object ignores toString and prints its own rendering, so a value looks different depending on whether you logged it or interpolated it — a real source of confusion when debugging.

The differences are what happens at the edges. A suspend function can only be called from a coroutine, and runBlocking is the bridge from ordinary code; in JavaScript the bridge is an async IIFE, or top-level await in a module (not available under node -e, which is why every async example here is wrapped). And a JavaScript async function starts immediately when called, returning a promise for work already in flight, whereas a suspend function does nothing until it is called from a coroutine — there is no cold-versus-hot distinction to manage here.

Promise.all rejects as soon as any input rejects — like awaitAll — but the others keep running with their results discarded, because there is no scope to cancel them. Promise.allSettled collects every outcome and never rejects, which is usually what a batch wants; Promise.race settles with the first outcome of any kind and Promise.any with the first success. None of them is parallelism: there is one thread, so only I/O overlaps.

The JavaScript column prints its "never" line, because a promise nobody is waiting for keeps running regardless — there is no Job tree, no parent, and no cancellation at all. AbortController is the by-convention replacement and works only for APIs that accept a signal and check it. Two practical consequences: work can be orphaned silently, and an unawaited promise that rejects becomes an unhandled rejection, which terminates a Node process and logs a warning in a browser.

AbortController is the platform convention: pass its signal down, and either check signal.aborted at each step or hand the signal to an API that honours it (fetch does; setTimeout does not). Nothing enforces the checking, so a loop that never looks at the signal simply runs to completion. There is no withTimeout either — a timeout is Promise.race against a timer, and the loser keeps running.

A tight loop occupies all of it: in a browser the page stops responding, and in Node every other request waits. The escape hatches are Web Workers and Node's worker_threads, which are separate JavaScript realms communicating by message passing — structured-cloned copies, not shared references, so there is nothing like a shared mutable object between them and correspondingly nothing like a data race. That also means @Synchronized, Mutex and atomics have no counterpart, because no two lines of your code ever run at the same instant.

What is missing is the operator library: no map, filter, debounce, flatMapLatest, buffer or conflate on an async generator, so the transformation happens in the loop body or in a helper you write. There is no StateFlow or SharedFlow either — a hot, multi-subscriber stream means an EventTarget, a callback list, or a library such as RxJS, which is where a good deal of the Flow vocabulary originally came from.

That matters because anything at all can be thrown — a string, a number, undefined — so a catch block must not assume it received an Error. The this.name assignment is not optional boilerplate: without it the class name does not appear in the message or the stack trace. Also note instanceof fails across realms, so an error from a worker or an iframe is not instanceof your class; library code often checks error.name instead.

That is why let appears where you would have written val, and it is the most common reason a translated Kotlin function grows a mutable variable it did not have. Note the bare catch { } with no binding — legal since ES2019 when you do not need the error. Note too that parseInt returns NaN rather than throwing, which is the JavaScript pattern in miniature: failure as a value that keeps flowing.

The consequences differ by host and are worth knowing before the first production incident: Node terminates the process on an unhandled rejection (since v15), while a browser logs to the console and keeps going. Attaching a .catch later than the same tick is already too late in Node. The habit to build is that every promise either gets awaited inside a try or gets a .catch immediately — there is no supervisor to fall back on.

Everything is private until exported, which matches Kotlin's internal/public more closely than its package visibility. The complication is that there are two systems in the wild: ESM (import/export, the standard, statically analysable) and CommonJS (require/module.exports, Node's original, dynamic and synchronous). A package declares which it is in package.json, and interop between them is the most tedious part of Node work.

npm installs and runs scripts; it does not build, test, format, lint or generate. Each of those is a separate dependency you choose and configure, which is why a new JavaScript project starts with more decisions than a new Gradle one — and why the JavaScript half of a Kotlin Multiplatform project brings a second toolchain with it. Dependency trees are an order of magnitude larger. package-lock.json is committed, and npm ci is the CI command that honours it exactly.

Kotlin separates by source set (src/test/kotlin); JavaScript separates by filename convention (name.test.js) and by the bundler excluding it. Node has had a built-in runner since 18 (node --test plus node:assert), which is the closest thing to running ./gradlew test; most projects still use vitest or jest for watch mode, mocking and a browser environment. There is no @Test annotation because there are no annotations — the runner finds tests by filename and by the global test/it functions it injects.

Without it, the IR compiler mangles names and may eliminate anything unreachable from Kotlin — so an unexported class simply is not there. @JsName("greet") pins a specific name when mangling would otherwise change it. Not every Kotlin type can be exported: suspend functions, Long, non-external interfaces and generics with unusual bounds are all restricted, and the compiler tells you at build time. Design the exported surface as a small, boring API — primitives, strings, arrays and plain classes.

dynamic is that hatch: member access on it is resolved at run time exactly as JavaScript resolves everything, with no checking and no completion. The disciplined alternative is an external declaration describing the library's shape, which is Kotlin's equivalent of a TypeScript .d.ts file — and Dukat could generate them from one. Keep dynamic at the boundary and convert to real Kotlin types immediately, for the same reason you would validate JSON at the edge.

First, the Kotlin standard library travels with the output, so the bundle is larger than the equivalent hand-written JavaScript — measure it early rather than at the end. Second, expect/actual is how one shared API gets a JavaScript implementation and an Android one, and it is the right place to put anything that touches the platform: storage, HTTP, dates, randomness. Keep commonMain free of platform assumptions and the JavaScript target mostly takes care of itself.