C#.CodeCompared.To/JavaScript

JavaScript's console.log is the everyday equivalent of Console.WriteLine: it accepts any number of arguments separated by spaces and always appends a newline. In the browser, output appears in the DevTools console; in Node.js it goes to stdout. There is no compilation step — a .js file runs directly.

JavaScript uses backtick template literals (`...${expr}...`) instead of C#'s $"...{expr}...". The syntax is nearly a direct swap: backticks instead of quotes, ${} instead of {}. Template literals also allow literal newlines without an escape sequence.

console.log always appends a newline. For raw output without one, use process.stdout.write() in Node.js — there is no direct equivalent of Console.Write that works identically in the browser and on the server. console.error writes to stderr, just like Console.Error.WriteLine.

Where C# needs a serializer call or a debugger to inspect an object's shape, console.log already prints objects and arrays readably — no ToString() override required. console.table renders an array of objects as a grid, and console.dir with { depth: null } expands deeply nested data that console.log would otherwise truncate.

This is a classic false-friend trap: C#'s var is still statically typed — the compiler infers a concrete type once and enforces it forever. JavaScript's var has nothing to do with type inference; it means "function-scoped, reassignable to any type." Modern JavaScript avoids var entirely in favor of let (reassignable, block-scoped) and const (single-assignment, block-scoped) — treat var as legacy syntax you will encounter but should not write.

C# catches a type mismatch while you are still writing the code. JavaScript has no compile step and no static type checker at all — a variable can hold any type at any time, and the runtime happily lets it change type on every assignment. Bugs that C# would have caught before the program ran surface here only when the wrong-typed value actually gets used, often far from where it went wrong.

JavaScript's typeof operator is much coarser than C#'s reflection-based GetType(). There is a single number type covering everything C# splits into int, long, float, double, and decimal. And typeof reports an array as "object" — use Array.isArray() to distinguish an array from a plain object.

C#'s nullable reference types give you exactly one absence value, null, and the compiler tracks whether a reference might hold it. JavaScript has no such safety net and splits absence into two distinct values: undefined means "never assigned" (an unset variable, a missing object property, a function with no return statement), while null means "explicitly set to nothing." The nullish coalescing operator ?? treats both as absent at once.

C#'s nullable reference types (#nullable enable) make the compiler flag every place a possibly-null value is dereferenced without a check. JavaScript has no equivalent enforcement mechanism — ?. and ?? exist and work well, but nothing requires you to use them. A missed null check is a runtime TypeError, not a compile error.

Most C# string methods have direct JavaScript equivalents with camelCase names: Trim() → trim(), ToUpper() → toUpperCase(), Contains() → includes(), StartsWith() → startsWith(). replace swaps only the first match; replaceAll (ES2021+) swaps every one — C#'s Replace always replaces all occurrences, so replaceAll is the closer match.

split/join are instance methods rather than C#'s static string.Join: you call join on the array, not on the string type. split also accepts a regular expression directly: text.split(/\s+/) splits on any run of whitespace.

Template literals span multiple lines as-is — no special raw-string syntax needed. Every line break and space between the backticks is preserved literally, so indentation is entirely up to how the text is placed; unlike C#'s raw string literals, JavaScript does not strip leading whitespace based on a closing-delimiter indentation rule.

parseInt and parseFloat parse strings to numbers but return NaN on failure instead of throwing or returning a boolean success flag. There is no TryParse pattern — always check the result with Number.isNaN() (not the global isNaN(), which has surprising coercion behavior of its own).

JavaScript has a single number type — a 64-bit IEEE 754 float — with no int, long, double, or decimal distinction. The 0.1 + 0.2 !== 0.3 rounding surprise that C#'s decimal type exists to avoid is unavoidable for ordinary JavaScript arithmetic; use a dedicated library for money calculations rather than plain numbers.

The global Math object provides the same core functions as C#'s Math class, with camelCase names: Math.sqrt, Math.ceil, Math.floor. Unlike C#'s Math methods, JavaScript's always operate on the single number type — there is no overload set for int versus double arguments.

C# picks integer or floating-point division based on the operand types. JavaScript has no integer type at all, so / always produces a floating-point result. Use Math.trunc() to discard the fractional part (matching C#'s truncation-toward-zero behavior) or Math.floor() if flooring toward negative infinity is what you want instead.

JavaScript has a built-in bigint primitive for arbitrary-precision integers, written with an n suffix — 9007199254740993n. Unlike C#'s BigInteger (a class requiring a using import), bigint is a language primitive. It cannot be mixed with number in arithmetic — both operands must be converted to the same type first.

JavaScript arrays are dynamically resizable — they are not fixed-size memory blocks the way C# arrays are, and grow or shrink with push/pop/splice. length is a property, not a method call. A const array binding still allows mutating the array's contents; only reassigning the variable itself is forbidden.

This is the strongest bridge point between the two languages: JavaScript's built-in array methods mirror LINQ almost one to one — filter is Where, map is Select, reduce is Aggregate, find is FirstOrDefault, some is Any, every is All. They chain the same way and return new arrays without needing a closing .ToArray() — a C# programmer's LINQ intuition transfers almost directly.

A JavaScript object literal is closest to a C# anonymous type, but far more flexible: properties are freely mutable by default (an anonymous type's properties are read-only), and there is no compiler-checked shape — a typo in a property name is simply a new property, not an error. Objects are the workhorse data structure of JavaScript, used where C# would reach for a class, a record, a dictionary, or an anonymous type depending on context.

JavaScript's Map is the closest equivalent of C#'s Dictionary<TKey, TValue> — it preserves insertion order, accepts any key type (not just strings, unlike a plain object), and has get/set/has/delete methods. Prefer Map over a plain object whenever the keys are not known ahead of time or are not strings.

Object.entries() returns an array of [key, value] pairs — the equivalent of iterating a C# Dictionary with foreach. Object.keys() and Object.values() give just one half of the pair. Unlike a Dictionary, a plain object was not designed as a general-purpose map, so this pattern works best when the keys are known, string-like identifiers.

Array destructuring feels familiar to a C# programmer who deconstructs tuples: const [x, y] = point is the same idea as var (x, y) = point. JavaScript adds a trick with no direct C# equivalent — an empty slot in the pattern ([first, , third]) skips an element entirely without naming it.

Object destructuring plays a similar role to C#'s property pattern matching (person is { Name: var name }), pulling specific properties into local variables. Renaming uses a colon ({ name: fullName }), and a default value covers a missing or undefined property ({ role = "guest" }) — both are more concise than the equivalent C# pattern-matching syntax.

The spread operator (...) expands an iterable in place — [...first, ...second] is the idiomatic replacement for LINQ's first.Concat(second).ToArray(). It also shallow-copies an array ([...original]) and, in a function call, expands array elements into individual arguments: Math.max(...numbers).

Spreading into a new object literal, with an overriding key listed afterward, achieves the same non-mutating "copy and update one field" pattern as C# record with expressions. This matters more in JavaScript than it might first appear, because plain objects are always mutable — spreading is the idiomatic way to produce an updated copy without touching the original.

The rest parameter (...numbers) collects any extra arguments into a real array, the same role C#'s params int[] numbers plays. The two directions of ... mirror each other neatly: as a parameter it gathers arguments into an array; as a spread at the call site it expands an array back into arguments.

The syntax is nearly identical, and JavaScript convention strongly favors braces even for single-statement branches. One important difference: JavaScript's if condition is implicitly coerced to a boolean rather than requiring one, so an empty string, 0, null, and undefined are all falsy — see the truthy/falsy concept below for the full table.

C# has no concept of truthy or falsy — a condition must be a genuine bool, full stop. JavaScript coerces any value, and only six values are falsy: 0, "", null, undefined, NaN, and false itself. Everything else — including an empty array [] and empty object {} — is truthy, which surprises programmers coming from a language with no implicit conversions at all.

This is the single biggest gotcha for a C# programmer: C# has exactly one equality operator, and it never silently converts between unrelated types. JavaScript's == applies a web of type-coercion rules that are famously inconsistent — notice that 0 == "" and 0 == "0" are both true, yet "" == "0" is false. The universal fix is to always use === and never reason about =='s coercion table at all.

C#'s modern switch expression (with =>) returns a value directly and has no fall-through. JavaScript only has the older switch statement — it does not produce a value, and execution falls through from one case to the next unless each ends with break. Grouping several values under one branch means stacking empty case labels, as shown for 2 and 3.

?? and ?. work almost identically to C#'s versions of the same operators, and were in fact directly inspired by them. The one difference: JavaScript's ?? guards against both null and undefined at once, since JavaScript has both. The || operator is not a substitute for ?? — it also triggers on any other falsy value, like 0 or "".

The C-style for loop is identical. C#'s foreach becomes for...of in JavaScript — note the keyword of, whose sibling for...in iterates property keys instead of values (including inherited ones) and is almost never what you want for an array. Prefer for...of or an array method like forEach.

The function keyword replaces a C# method signature entirely — there are no parameter types, no return type, and no static keyword (all module-level functions are effectively static, since there is no enclosing class). Function declarations are "hoisted": they can be called before their definition appears later in the file, unlike a function assigned to a const.

Arrow functions ((params) => expression) read almost exactly like C# lambdas. For a multi-statement body, add braces and an explicit return: (n) => { const doubled = n * 2; return doubled; }. The single-expression form implicitly returns its value, just as a C# expression-bodied lambda does.

Default parameter values look identical to C#'s. One notable difference: a JavaScript default can be any expression, including one referencing an earlier parameter — function f(a, b = a * 2) — while C# restricts default values to compile-time constants. A default kicks in whenever the argument is omitted or explicitly passed as undefined.

JavaScript has no named-argument syntax like C#'s name: value at the call site. The established idiom is to accept a single destructured "options object" parameter, which gives the same order-independent, self-documenting calls. Defaults live right inside the destructuring pattern, exactly as shown.

C#'s method overloading lets the compiler pick the right implementation based on argument types. JavaScript has no overload resolution mechanism at all — defining function describe twice simply replaces the first definition with the second. A single implementation must branch on typeof or instanceof itself to handle multiple argument shapes, or accept a flexible options object instead.

Functions that return functions work the same way conceptually as C#'s Func<T, TResult>-returning methods. Because functions are ordinary values in JavaScript, no delegate type declaration is needed — the returned arrow function automatically captures factor from the enclosing scope. This pattern powers currying, memoization, and middleware idioms throughout JavaScript codebases.

Closures behave the same way in both languages: a C# lambda captures outer variables by reference, and so does a JavaScript closure — later changes to the captured variable are visible inside the function. This is the mechanism behind private state in JavaScript modules and factory functions, since there is no separate "captured variable" syntax to opt into, unlike some other languages.

In C#, this inside an instance method always refers to the object the method was called on. Even when you capture a method as a delegate (Action shower = counter.Show;) and invoke it somewhere else entirely, this inside Show still points back to counter. This consistency is exactly what JavaScript's this does not guarantee, as the next concept shows.

Unlike C#, JavaScript's this is not fixed to the object a method was defined on — it is determined entirely by how the function is called. Pulling a method off its object (const detached = counter.show) and calling it as a plain function loses this entirely, throwing a runtime error the moment the method body touches this. Fixes: call it as object.method(), use .bind(object) to pin the receiver permanently, or use an arrow function, which has no this of its own.

This is the practical reason arrow functions exist. A regular JavaScript function expression, when used as a callback, gets its own this determined by how the callback itself is invoked — inside array.map(function (n) {...}), that this is undefined, not the enclosing object. An arrow function has no this of its own; it inherits the enclosing scope's this instead, matching the predictable behavior C#'s this always has. This is why arrow functions are the default choice for callbacks inside class methods.

JavaScript class syntax reads similarly to C#: a constructor method, this. for instance members, and new to instantiate. There is no automatic property syntax — fields must be assigned by hand — and every method is implicitly virtual/overridable; there is no virtual keyword because it is simply always the case.

C#'s object model is class-based: a type's shape and inheritance chain are fixed by the compiler. JavaScript's object model is fundamentally different — prototypal: every object has a live, mutable link (its prototype) to another object it delegates missing properties and methods to, and Object.create() builds that link directly. The class keyword introduced in ES6 is syntax sugar over this same prototype-chain machinery — it does not add a genuinely different object model underneath, just a more familiar-looking syntax on top of one.

When JavaScript compiles a class body, instance methods like speak() are placed on Animal.prototype, a single shared object — not copied onto each instance. Every Animal instance has a hidden prototype link to that shared object, so animal.speak() works by JavaScript walking up the prototype chain until it finds speak. This is invisible when using class normally, but understanding it explains why prototype methods are shared and memory-efficient, and why modifying Animal.prototype at runtime affects every existing instance — something C#'s sealed-at-compile-time type system never allows.

JavaScript's native #field syntax gives genuinely private fields, enforced by the runtime rather than a compile-time-only convention — unlike C#'s private, which is a language-level access modifier that JavaScript historically lacked. The get keyword defines an accessor called without parentheses, the same as a C# property.

Inheritance uses the same extends keyword C# does not have (C# uses : instead). To call a parent constructor or method, JavaScript uses super(...) / super.speak() rather than base(...) / base.Speak(). One strict rule: a subclass constructor must call super() before touching this at all, since the parent constructor is responsible for initializing the instance.

JavaScript marks both static methods and static fields with the static keyword and accesses them through the class name with a dot — the same syntax C# uses. Unlike C#, a JavaScript class does not need to be marked static as a whole; individual members opt in one at a time, so a class can freely mix static and instance members.

JavaScript ES modules are explicit about what crosses file boundaries: each name must be individually exported, and an importer names exactly what it needs with import { ... } from "..." — closer in spirit to C#'s access modifiers than to using directives, since nothing is visible outside a module unless deliberately exported. There is no namespace-style dotted access; each file is its own independent scope. This example cannot run in the single-file test sandbox, but it is the backbone of every real JavaScript project.

Dependencies are installed from npm, the JavaScript package registry analogous to NuGet, into a local node_modules folder — with package.json playing the role of a .csproj's package references. Unlike NuGet packages, which are typically compiled assemblies, most npm packages ship as plain JavaScript source, which is part of why the ecosystem moves so fast and occasionally breaks in surprising ways.

The structure is the same — try / catch / finally — and the shape reads familiarly to a C# programmer. The key difference is that JavaScript's catch has no typed catch clauses: unlike C#'s catch (ArgumentException error), which filters by exception type, a JavaScript catch (error) block always catches everything and must inspect error itself (with instanceof) to decide what to do. The message property is .message, not C#'s .Message.

Custom errors subclass the built-in Error, the way a C# custom exception subclasses Exception. Two conventions matter here: call super(message) so the message and stack trace are set up correctly, and assign this.name so the error identifies itself when logged. Because catch has no typed clauses, you distinguish your custom error with instanceof and re-throw anything unexpected — the same defensive pattern a C# catch-all block requires.

C#'s type system only permits throwing an object that derives from Exception. JavaScript places no such restriction on throw — a string, a number, or a plain object can all be thrown. This is a trap: a thrown non-Error value has no .message or .stack, so any code that assumes those properties exist will break. The universal rule is to always throw an Error or a subclass of it.

This is the deepest model difference behind the syntax similarity. C#'s async/await schedules continuations on the .NET thread pool — genuine parallel execution is possible. JavaScript runs on a single thread with an event loop: nothing ever executes truly in parallel within one JavaScript context, and "async" work — timers, network responses, promise resolutions — is only ever interleaved with other JavaScript code, never running at the same instant as it. Understanding this ordering is essential to everything that follows.

JavaScript has no distinct Task type — a Promise fills that role, but with one behavioral quirk worth knowing: a Promise's executor function runs immediately and synchronously the moment new Promise(...) is called — Promises are always "hot," already in progress before you ever call .then(). There is no cold/not-yet-started state the way a manually constructed Task can have; work begins the instant the Promise is created.

Here the two languages are nearly identical, and it is genuinely the smoothest concept to carry over: async marks a function as asynchronous, and await pauses until the awaited value resolves, letting asynchronous code read almost exactly like synchronous code in both languages. The differences are underneath, not in the syntax: JavaScript has no Task type (just Promise), no thread pool to schedule onto, and every async function — like every C# async Task method — always returns a value that must itself be awaited or chained.

Promise.all plays exactly the role of C#'s Task.WhenAll: kick off several asynchronous operations, then await all of them together so the total wait is the slowest one rather than the sum of each — even though, underneath, JavaScript is interleaving on a single thread rather than genuinely running them on separate ones. Promise.allSettled is the variant that does not reject as soon as the first operation fails, similar in spirit to inspecting each Task's status individually.

JSON is native to JavaScript — it is, quite literally, JavaScript object-literal syntax — so JSON.stringify and JSON.parse need no serializer configuration, attribute annotations, or generic type parameter the way C#'s System.Text.Json does. JSON.stringify(value, null, 2) pretty-prints with two-space indentation.

A genuine trap for a C# programmer: JavaScript's default sort() converts every element to a string before comparing, so [10, 2, 33, 4] sorts lexicographically to [10, 2, 33, 4] — "10" sorts before "2". C#'s List<int>.Sort() has no such trap because it is generic and numerically aware by default. For numbers in JavaScript, always supply a comparator: (a, b) => a - b. Like C#'s Sort(), JavaScript's sort() mutates the array in place.

For arrays, includes is the equivalent of Contains. For a Map, has mirrors ContainsKey closely. For a plain object used as a lookup, the in operator checks for a key's presence — and reading a missing property simply returns undefined rather than throwing the way an indexer would on a missing Dictionary key without TryGetValue.

toFixed(n) rounds to a fixed number of decimal places but returns a string, not a number — a common source of bugs when the result is used in further arithmetic without converting back with Number() or a unary +. toLocaleString() handles thousands-grouping and locale formatting, filling the role of C#'s "N" format specifier.

Even with JSDoc type annotations (@param {number} count), plain JavaScript has zero runtime type enforcement — the annotation is purely advisory documentation for editor tooling, never checked by the JavaScript engine itself. Only a separate static analysis pass (an editor's TypeScript-powered checker, or an actual TypeScript build) can catch a JSDoc type mismatch, and only before deployment, never at runtime. Coming from C#'s compiler-enforced guarantees, this is the single biggest adjustment: nothing stops a type error from reaching production.

This is the single most common runtime surprise for a C# programmer: passing object.method as a callback (to setTimeout, an event listener, an array method) silently detaches this — C# delegates never do this. Always call methods through the object (counter.show()), .bind() the receiver explicitly, or wrap the call in an arrow function.

Repeated here as its own gotcha because it deserves to be memorized: JavaScript's == coercion table has no C# analogue and is not fully consistent even internally — memorizing it is not worth the effort. Always use ===, and always use Number.isNaN() rather than == or === to test for NaN, since NaN famously does not equal itself under any comparison operator.

C# distinguishes int, long, float, double, and decimal for good reasons — each has different precision and range guarantees. JavaScript's single number type is a 64-bit float, which means integers beyond Number.MAX_SAFE_INTEGER (2⁵³ − 1) silently lose precision with no warning or exception — the value above rounds to the nearest representable float. Use the separate bigint type (the n suffix) for integers that must stay exact beyond that range, and never use plain number for currency without a dedicated library.

C# requires a variable to be declared before any use — there is no ambiguity. JavaScript's legacy var declarations are "hoisted": the declaration itself is moved to the top of the enclosing function during compilation, but the assignment stays in place, so reading a var before its assignment line gives undefined rather than an error. Function declarations (function name() {}) are hoisted completely, body and all, so they can be called before they appear in the file — but a function stored in a const/let is not, and referencing it early throws a ReferenceError. Modern code sidesteps the whole issue by using let/const and declaring functions before use.

C# gives you a genuine choice between reference types (class) and value types (struct), where a struct assignment truly copies the data. JavaScript has no value-type equivalent for objects or arrays at all — every object and array is always a reference, and copy = original makes both names point at the exact same underlying data. To copy, spread into a new literal ({ ...original } or [...list]) for a shallow clone, or use structuredClone(original) for a deep one. Only primitives (numbers, strings, booleans, null, undefined, bigint) copy by value.