Dart.CodeCompared.To/TypeScript

TypeScript is JavaScript with a compile-time type layer, so a script is just top-level statements — there is no main() entry point to declare. Everything on this page compiles to plain JavaScript with the types erased, which is the single fact that drives most of the surprises ahead.

Dart's final maps to const and var to let, with the same caveat you already know: const freezes the binding, not the object, so a const array still mutates. TypeScript's const is not Dart's compile-time const — there is no canonicalization and no deep immutability here; that job falls to readonly and as const later.

Annotations sit after a colon exactly as in Dart, and inference covers most bindings. The jarring part is that ratio and answer share one type: TypeScript has a single number (an IEEE-754 double), so there is no int/double distinction and no num supertype to reach for.

The idea is identical but the punctuation shifts: TypeScript uses backtick template literals and requires ${…} braces around every interpolation, including a bare variable — there is no $name shorthand like Dart's. Ordinary double-quoted strings do no interpolation at all.

Dart's int/double/BigInt trio collapses to one number plus a separate bigint. There is no ~/; integer division is Math.trunc(a / b) or Math.floor. Because number is a double, 0.1 + 0.2 !== 0.3 and integers above 2^53 lose precision — the reason bigint exists.

In Dart a type conforms only if it explicitly implements or extends; here any object with an x and y number is a Point. This structural rule means two unrelated interfaces with the same fields are interchangeable — powerful, and occasionally a bug the nominal Dart type system would have caught.

Dart reifies generics: List<int> knows it holds ints at run time, and is List<int> works. TypeScript erases every type argument during compilation, so at run time number[] and string[] are the same bare Array. Any runtime check on a type parameter is impossible — a habit worth unlearning early.

Dart's dynamic is TypeScript's any — both disable checking entirely and are best avoided. The closer analog to Dart's Object? is unknown: it accepts any value but permits nothing until you narrow it, giving you the safe top type. Reach for unknown wherever you would have reached for Object?.

This is the most dangerous single difference. Dart's as inserts a runtime type check and throws immediately on a bad cast. TypeScript's as is a compile-time assertion that is erased — it silences the checker and performs no verification, so the failure surfaces later and elsewhere. Treat every as as an unaudited promise you are making to the compiler.

Dart's typedef becomes TypeScript's type alias, and it does far more here: beyond naming function signatures it can name unions, tuples, mapped and conditional types. A function type uses the fat-arrow form (x: T) => U, and Map<String, dynamic> is idiomatically a Record<string, unknown>.

Nullability is opt-in on both sides, but the syntax differs: Dart appends ? to the type, while TypeScript spells it as a union with null — string | null. Under strictNullChecks the compiler tracks it and refuses a bare access, just like Dart. The refinement inside the if is called narrowing rather than promotion.

Dart has exactly one bottom value, null. TypeScript has two: undefined (an uninitialized binding, a missing property, a function's implicit return) and null (a value someone chose to assign). An optional field x?: T means T | undefined. Most codebases pick one convention and lean on == null, which uniquely matches both.

This trio ports over unchanged: ?., ??, and ??= mean exactly what they do in Dart. One subtlety — TypeScript's ?? triggers on null or undefined only, deliberately unlike ||, which also fires on 0, "", and false. Prefer ?? when you mean "is it absent", the way Dart taught you.

Dart's ! is a runtime null-check that throws the instant the value is null. TypeScript's non-null assertion ! is compile-time only and erased: it tells the checker "trust me" and inserts no guard, so a wrong assertion produces a quiet undefined/NaN downstream instead of a clean failure. Like as, it is a promise, not a check.

Dart's late defers initialization while keeping the field non-nullable, and it throws if you read it before it is set. The nearest TypeScript tool is the definite-assignment assertion ! on a field, but it is weaker — purely a compile-time waiver with no runtime "used before initialized" guard. There is no lazy-late (compute-on-first-read) equivalent; use a getter for that.

Dart has no anonymous union, so "an int or a string" forces you up to Object and back down through is checks. TypeScript makes the union a real type — number | string — and typeof narrowing splits it back apart safely. This single feature quietly replaces a lot of Dart's sealed-class boilerplate.

A Dart sealed hierarchy becomes a discriminated union: each member carries a shared literal tag (here kind), and switching on that tag narrows the object in each branch. It is data, not a class tree — no subclassing, no extends — but it earns the same closed-set exhaustiveness, shown next.

When every case is handled, the value reaching default has type never, so the call type-checks. Add a third union member and forget its case, and payment is no longer never — the call fails to compile. It is the manual, opt-in version of the exhaustiveness Dart gives you for free on a sealed switch.

TypeScript has an enum keyword, but unlike Dart's it emits a runtime object and has some well-known sharp edges. Most modern code prefers a union of string literals: it is erased (zero runtime cost), it narrows like any union, and the values are the readable strings themselves. Dart's enhanced enums with methods have no direct equal — model those as a union plus helper functions.

A positional Dart record (int, String) maps to a TypeScript tuple [number, string] — a fixed-length, position-typed array. Both destructure at the call site. Note the sort difference lurking here: TypeScript's Array.sort is in-place and defaults to string order, so numbers need an explicit (a, b) => a - b comparator.

Dart's named record fields ({int width, int height}) are simply an object literal with a structural type in TypeScript. Because typing is structural, you never declare a name for this shape unless you want to reuse it — the anonymous { width: number; height: number } is a full-fledged type on its own.

Array destructuring with a rest element mirrors Dart's list patterns closely. Object destructuring, const { x, y } = point, has no Dart counterpart for maps and is used constantly — it is the standard way to pull fields out of an object or unpack a function's options argument (the functions section returns to this).

This is a genuine loss coming from Dart 3. TypeScript's switch compares a single value with === — there is no destructuring pattern, no when guard, and no record/list matching. You destructure first and fall back to an if/else ladder. Discriminated-union switches (above) recover the closed-set half, but not the shape-matching half.

TypeScript's parameter properties — an access modifier on a constructor parameter — are the direct echo of Dart's this.x shorthand, declaring and assigning the field in one place. Two differences to internalize: instantiation requires the new keyword, and member access always needs an explicit this. — there is no implicit receiver.

TypeScript allows only one constructor per class, so Dart's named constructors (Temperature.fahrenheit) and factory constructors both become static methods that return an instance. You lose the constructor-tear-off niceties, but the pattern — named alternative ways to build a value — carries over cleanly as static factories.

Dart's cascade .. lets you fire several calls at one receiver even when each returns void. TypeScript has no cascade; to chain you must design each method to return this (a fluent builder). For a plain configuration block, most code just repeats the variable name or destructures — there is no free chaining over void methods.

Dart lets a class define operator +, operator ==, operator [], and more. TypeScript supports none of this: + on objects only ever does string/number coercion, so arithmetic-like APIs become named methods such as add. Similarly there is no operator == override — value equality is hand-written, covered next.

In Dart you override operator == and hashCode to get value semantics. TypeScript's === is always reference identity for objects and cannot be overridden, so two structurally identical instances are not equal. Value equality is a method you call explicitly (or a library helper) — and there is no hashCode, since Map/Set key on reference or primitive value, never on a custom hash.

Single inheritance with extends and abstract works as in Dart. The differences: TypeScript has no @override annotation (you can enable a compiler flag that requires an override keyword instead), and it separates interface (pure structural shape, implemented with implements) from class — whereas in Dart every class also defines an implicit interface.

Dart mixes behavior in with a single with clause and strict linearization. TypeScript has no mixin keyword; the community pattern is a mixin function — a generic function over a base constructor that returns an anonymous subclass. It works and even composes, but it is boilerplate-heavy and loses Dart's clean linearization guarantees.

TypeScript has no named parameters. The idiom is a single options object destructured in the parameter list, with defaults written inline and optional fields marked ? in the object type. It reproduces Dart's call-site readability — greet({ name: "Ada" }) — but the "required" guarantee comes from the field being non-optional in the type, not from a required keyword.

Dart's optional positional parameters use square brackets; TypeScript writes a trailing = default directly, or marks a parameter optional with by?: number. There is no bracket syntax and no distinction between optional-positional and optional-named — a defaulted or ? parameter is simply the last one(s) you may omit.

Dart's => expression body and TypeScript's arrow functions look and behave almost identically, closures included. The gotcha for a Dart programmer is this: an arrow function captures the surrounding this lexically (usually what you want), whereas the older function keyword rebinds this per call — a footgun Dart simply does not have.

Here TypeScript is actually the more flexible one: a rest parameter ...numbers: number[] collects any number of trailing arguments, so callers write sumAll(1, 2, 3, 4) with no list literal — something Dart cannot express, since Dart has no variadics and requires an explicit List. Spread ... also expands an existing array back into arguments.

Dart's List<T> is TypeScript's Array<T> (written T[]). The method names shift: add is push, where is filter, and — crucially — map/filter return arrays eagerly, so there is no .toList() to materialize a lazy Iterable. Chains are immediate, not deferred.

Dart's map literal {k: v} is a Map; TypeScript reserves {…} for objects and offers a distinct Map class with get/set. Prefer Map for real dictionaries (any key type, reliable iteration order, a real size). A plain object works for fixed string keys but keys are always strings, and inherited properties can leak in — a subtle bug a Dart Map never has.

Both languages have a first-class Set that de-duplicates on insertion. The renames to remember: it is .size (not .length) and .has (not .contains). One caveat inherited from equality — a TypeScript Set of objects dedupes by reference, so two structurally equal objects are two members, whereas a Dart Set can honor a custom ==.

This is a Dart idiom you will miss daily. Dart lets you embed if and for directly inside a collection literal — the backbone of every Flutter children: list. TypeScript has only the spread operator, so a conditional element becomes ...(cond ? [x] : []) and a generated run becomes ...items.map(...). It works, but it is noisier.

Dart offers const collections and List.unmodifiable with real runtime enforcement. TypeScript's readonly T[] and as const are compile-time only — they remove the mutating methods from the type but do not freeze the value, so a cast or an any can still mutate it. For runtime immutability you must call Object.freeze yourself.

Dart splits the reduction in two: fold takes an initial value of any type, while reduce has no seed and stays in the element type. TypeScript folds both into one reduce — pass an initial value for the fold behavior, or omit it for the seedless reduce. Omitting the seed on an empty array throws, exactly as Dart's seedless reduce does.

A dangerous false friend: Dart's for (x in list) iterates values, but TypeScript's for..in iterates keys — array indices as strings, plus any enumerable inherited property. The one that matches your Dart habit is for..of. Reach for for..of to iterate values and avoid for..in on arrays entirely.

Dart's Iterable is lazy by default, so map/take chains do minimal work. TypeScript arrays are strictly eager — every .map materializes the whole array — so an Array.map over a huge range would compute all of it. To recover laziness you drop down to a generator (function*), which yields on demand exactly like a Dart Iterable.

Dart's sync*/yield generator function maps directly to TypeScript's function*/yield. Collecting the results differs: Dart calls .toList(), while TypeScript spreads the generator into an array with [...gen()]. Dart's yield* (delegate to another iterable) is spelled the same, yield*, in TypeScript.

Dart's Future<T> is TypeScript's Promise<T>, and async/await read identically. Two differences: a Promise has no Future.delayed, so a timed delay is new Promise around setTimeout; and like a Dart Future, a Promise is eager — it starts running the moment it is created, not when awaited.

Dart's Future.wait is Promise.all — run several async operations concurrently and await them together, preserving order. The extras differ in name: Dart's Future.any is Promise.race/Promise.any, and TypeScript adds Promise.allSettled for "wait for all, successes and failures alike", which Dart lacks a single-call equivalent for.

Dart's Stream<T> with async*/yield and await for maps neatly to a TypeScript async generator (async function*) consumed with for await..of. What has no built-in equal is Dart's rich stream ecosystem — StreamController, broadcast streams, and the transform operators; in TypeScript those come from libraries like RxJS, not the language.

Both runtimes are single-threaded with an event loop, so async/await never runs code in parallel — it interleaves. For true parallelism Dart spawns an isolate (its own heap, message-passing, no shared memory), and the browser/Node analog is a Web Worker or worker_threads: same "copy the data, no shared state" model, but a runtime API rather than a language feature — so this row is shown for illustration rather than run in place.

Generic function syntax is nearly identical — <T> after the name, inference at the call site. The one thing to keep in mind is the earlier lesson: TypeScript's T is erased, so inside the body you cannot inspect it (T has no runtime existence), whereas Dart could test items is List<int>.

Dart bounds a type parameter with T extends num; TypeScript uses the same keyword, T extends number. Because number already covers both integers and floats, the two Dart calls collapse into one type. TypeScript's extends bound is more expressive than Dart's, though — it can constrain to object shapes, unions, and even keyof another type, as the next example shows.

TypeScript can compute types: Partial<T> makes every field optional, Pick<T, K> selects a subset, Readonly<T> freezes them, and keyof T yields the union of field names — all derived automatically and kept in sync as the source type changes. Dart has no equivalent; you would write each variant class by hand. This alone is a strong reason web APIs lean on TypeScript.

A conditional type — T extends X ? A : B — chooses a type based on another type, and infer can even extract a piece of it (here, an array's element type). Combined with mapped types this makes TypeScript's type layer a small functional language of its own. Dart has nothing comparable; its type system is descriptive, not computational.

The structure matches Dart, and neither language has checked exceptions. Two differences bite: TypeScript can throw any value (a string, a number), not just an Error — so the caught binding is typed unknown and must be narrowed before use. And there is no on Type catch clause; type-based dispatch is done with instanceof, shown next.

Dart selects a handler by type with on FormatException catch. TypeScript has a single catch block whose parameter is unknown, so you branch inside it with instanceof — which, unlike an interface check, does work at run time because classes are real values. This is the one place structural erasure does not bite: class identity survives.

In Dart any class that implements Exception can be thrown. In TypeScript you conventionally extends Error and call super(message), which gives you a stack trace and a message field for free. Setting this.name is the customary touch so the error prints with your class name — the rough equivalent of overriding toString.

Dart's rethrow keyword re-raises the current exception while preserving its original stack trace. TypeScript has no dedicated keyword — you simply throw error again. Because the caught value is the original Error object (which captured its stack when constructed), the trace is retained; there is just no special syntax marking the intent.

Dart imports whole libraries by path and every top-level name is public unless prefixed with _. TypeScript uses ES modules with the reverse default: nothing leaves a file unless exported, and you import named bindings with { … }. This example spans two files, so it is marked display-only — a single-file test cannot resolve the second module.

Dart's extension methods let you graft new methods onto a type you do not own — 3.spelledOut. TypeScript has no such feature for your own code; you write a plain function, spelledOut(3). (Declaration merging can describe methods added to a global prototype, but actually monkey-patching built-ins is discouraged and is not the same tool.)

Dart's pubspec.yaml plus dart pub get corresponds to package.json plus npm install (or pnpm/yarn/bun). The registries differ — pub.dev versus the npm registry — and TypeScript packages often ship types either bundled or as a separate @types/… package, a split Dart never has since every pub package is already typed.