JavaScript.CodeCompared.To/C#

The similarity is real but shallow, and it hides the one structural difference worth knowing immediately: executable statements must come before any type declaration in a top-level program. So a file that defines a class and then uses it has to put the usage first and the class at the bottom — which is the reverse of what a JavaScript developer expects from hoisting, and is enforced by the compiler as CS8803. Every example on this page is written that way.

This is the trade in one row, and it cuts both ways. C# finds the typo, and C# also makes you wait for a compiler every time you want to see anything. A JavaScript developer usually underestimates how much of their working rhythm was "save and look" — which costs nothing in Node and a few seconds in .NET. Hot reload closes some of that gap, and dotnet watch is the closest thing to nodemon.

C# does have dynamic, which genuinely defers everything to run time, and it is almost never the right answer — it exists for interop with COM and with dynamic languages. The everyday tools are var for inference, object when something really can be anything, and record/generics when a type varies in a structured way. Note that const in C# means a compile-time constant, so JavaScript's const is closer to C#'s readonly — which applies only to fields; a C# local cannot be made read-only at all.

The JavaScript techniques that depend on adjusting an ordinary object later have no direct equivalent: no monkey patching, no adding a method to a built-in, no mixin applied at run time. (Mocking libraries replace a method by generating a subclass, and reflection can build new types at run time, but neither changes an existing object.) Extension methods look similar and are not — they are static methods the compiler rewrites your call into, so they cannot override anything or reach private state. In exchange, a property access is an offset rather than a hash lookup, and a misspelled property is a build error rather than undefined.

The types that matter day to day: int for counting, long for identifiers and timestamps, double for measurement and decimal for money — the last has no JavaScript equivalent short of a library and is exactly right for currency, since 0.1m + 0.2m is exactly 0.3. The shared surprise is that double arithmetic rounds identically in both languages, because both are IEEE 754. Integer overflow wraps silently unless you write checked.

What replaces the JavaScript rules is a different question: reference or value. == on a class compares references (two objects with identical contents are not equal), on a record compares values (the compiler generates it), and on a plain struct does not compile at all unless the struct declares it (Equals compares its fields). NaN != NaN survives, because that is IEEE 754 rather than a language decision. And Equals and GetHashCode must be overridden together for a class used as a dictionary key — which is what records do for you, and the reason to prefer them.

The practical guidance is that you will mostly write class and mostly get JavaScript's behavior, so this is a smaller change than it first looks. Where it matters is that several built-in types are structs — int, bool, DateTime, Guid, every tuple and every enum — so passing one to a method copies it, and modifying the copy changes nothing. The rule of thumb from the .NET guidelines: use a struct for a small immutable value that behaves like a number, and a class for everything else.

For a JavaScript developer this is the single most worthwhile C# feature to adopt early, because it is the closest thing to an object literal that the type system takes seriously — and it removes the boilerplate that made older C# feel heavy. The differences from a literal: the shape is declared once and fixed, the properties are immutable by default, and equality compares contents rather than identity. record struct gives you the same thing as a value type.

Raw string literals with three quotes are the modern multi-line form (a verbatim @"…" string can span lines too), and they strip the indentation to match the closing delimiter, which template literals do not. The other difference is that a C# string is UTF-16 and immutable, like JavaScript's — so the surrogate-pair problem is the same in both, and an emoji counts as two in Length. Use StringBuilder for repeated concatenation, which is the equivalent of pushing to an array and joining.

Two that move rather than rename. join is string.Join — a static method taking the separator first, which is backwards from array.join(separator). And replace in C# replaces every occurrence, where JavaScript's replaces only the first unless you pass a global regular expression; replaceAll is what C# does by default. Note ',' in single quotes: that is a char, a distinct type from a one-character string.

Three habits to retire. There are no holes and no sparse arrays — an index past the end throws IndexOutOfRangeException rather than growing the array. A collection holds one type, so a mixed array needs List<object> and a cast on the way out, which is usually a sign the design wants a record instead. And Count is the property on a List while Length is the one on an array, which trips up everybody. ^1 is at(-1), and slicing is values[1..3].

🚨 The trap is the indexer. counts["fig"] on a missing key throws KeyNotFoundException rather than returning undefined — which is safer and catches JavaScript developers constantly. TryGetValue is the idiom for "get it if it is there", and the out var found declares the variable inline. Dictionary is the hash map; SortedDictionary is used here only so the iteration order is defined, since neither guarantees insertion order the way a JavaScript Map does.

Destructuring by property name is written as a pattern — person is { Name: var name, Age: var age } — and a rest element as a slice in a list pattern, values is [var head, .. var rest]. What does not carry over is default values in the pattern. The spread operator has partial equivalents — params for arguments, collection expressions ([..first, ..second]) in C# 12 for combining collections, and with for copy-and-change on records.

The important difference is that LINQ is lazy: Where and Select build a query rather than an array, and nothing runs until something consumes it — a foreach, a Sum, or an explicit ToList(). That is closer to a generator than to an array method, and it means chaining ten operations makes one pass rather than ten intermediate arrays. It also means a query can be evaluated twice by accident if you enumerate it twice, which is the one new hazard.

The rest of the vocabulary: OrderBy and ThenBy for stable multi-key sorting (JavaScript's sort takes one comparator and you write the tie-break by hand), Distinct, Zip, ToDictionary, and the ones JavaScript does share under other names — SelectMany is flatMap, and Any and All are some and every. There is also a query syntax — from person in people group person by person.Team — which reads like SQL and which most modern code does not use.

Two things a JavaScript developer gains. There is no this rebinding problem: in a class, this is always the instance, so no bind, no self = this, and no arrow-function-to-preserve-this. And properties are first-class — public int Value => value; is a getter, { get; set; } is a field with an accessor, and { get; init; } allows setting only during construction. The class sits at the bottom of the file because a file of top-level statements must put its type declarations after the statements (error CS8803); the statements above can still use it.

This is nominal typing, and it is the opposite of both JavaScript's duck typing and TypeScript's structural typing — a TypeScript developer will find this the sharpest change, since a matching shape is no longer enough. What you get is that the compiler can tell you every implementation of an interface, refactoring tools can rename across all of them, and a type cannot accidentally satisfy an interface it knows nothing about. The I prefix is a .NET convention you will see everywhere.

Generics are the mechanism behind everything a JavaScript developer meets in .NET: List<T>, Dictionary<K, V>, Task<T>, IEnumerable<T>. Constraints are written with where — where T : IComparable<T>, where T : class, where T : new() — and are what let the compiler check the body once rather than at each use. TypeScript generics look similar and are erased; C# generics are not.

string? means "may be null" and string means "will not be", and the compiler warns when you dereference the first without checking or assign null to the second. It is a warning rather than an error because the feature was added to a language with twenty years of existing code, and most new projects turn warnings into errors. ??, ?. and ??= are all present and mean what they do in JavaScript.

Every check becomes explicit, which is more typing and one fewer thing to get wrong: if (value != null), if (text.Length > 0), if (list.Any()). The convenience shorthands JavaScript developers miss most are string.IsNullOrEmpty(text) and string.IsNullOrWhiteSpace(text), which are exactly the if (!text) that people write in JavaScript and which cover the common case.

The difference that matters: JavaScript has one thread, so await is about yielding to the event loop, and a long synchronous loop freezes everything. C# has a thread pool, so await is about not occupying a thread while waiting — and the code after an await may run on a different thread than the code before it. That is why shared mutable state needs locking in C# and never does in JavaScript, and it is the single biggest conceptual adjustment on this page.

The rule of thumb that keeps this straight: async/await is for waiting (input and output — a database, a file, a request), and Parallel.For, Task.Run and PLINQ are for computing. Using async for CPU work does not make it parallel, and using threads for waiting wastes them. The obligation that arrives with real threads is real too: two threads writing the same variable is a data race, so shared mutable state needs lock, Interlocked or a concurrent collection.

Two conveniences worth knowing: CancellationTokenSource can be constructed with a timeout, so "cancel after five seconds" is one line, and tokens compose with CreateLinkedTokenSource, so a request-scoped token can cancel everything below it. Passing the token down through every layer is the discipline it asks for, and it is why you see CancellationToken token = default as the last parameter of so many .NET methods.

The .NET exception hierarchy is worth a little study because it is what you catch: ArgumentException, InvalidOperationException, FormatException, KeyNotFoundException, NullReferenceException. Two habits to bring: never catch bare Exception except at a top-level boundary, and use the Try pattern (int.TryParse) for failures you expect, since throwing is comparatively expensive. A C# exception carries a full stack trace, as a JavaScript Error does.

JavaScript has been adding the same idea — the using declaration and Symbol.dispose — and .NET has had it since the beginning, which is why every file, connection, HTTP client and stream in the framework implements it. The rule to absorb: if a type implements IDisposable, dispose it — using is how — with a few documented exceptions such as Task. await using is the asynchronous form.

So using System.Linq; does not load anything — it makes those names visible, and the code is already in an assembly the project references. That removes a set of problems a Node developer knows well: no resolution algorithm, no two copies of the same package at different versions in one tree, no CommonJS-versus-ESM split, and no node_modules. Loading an implementation by path is still possible — Assembly.LoadFrom and AssemblyLoadContext are how plugin systems work — but it is rare, and dependency injection is the everyday way to swap one.

That trade is worth understanding rather than judging. Flat resolution means no duplicate copies and a much smaller dependency tree, and it means a version conflict between two of your dependencies is a problem you must resolve rather than one the tool papers over. The other cultural difference is that the .NET base class library is very large — JSON, HTTP, cryptography, dates and regular expressions are all in the box, and dependency injection and logging come with the ASP.NET Core and generic-host frameworks — so the median project has perhaps a dozen dependencies rather than several hundred.

What you give up is the ecosystem's pace and its flexibility — there is no swapping the bundler for a faster one, because there is no bundler. What you get is that a five-year-old .NET project still builds, the debugger works without configuration, and every project is laid out the same way. Two tools worth knowing early: dotnet watch is nodemon, and the analyzers built into the compiler cover much of what ESLint does, configured in .editorconfig.