A Managed Language vs. A Script-Born Language

var age = 30;
age = "thirty"; // compile error

let age = 30;
age = "thirty"; // fine, no error

C#'s var is compile-time type inference — the variable's type is fixed the moment the compiler sees the initializer; it's sugar, not dynamic typing. JavaScript's let/const hold no type at all — the value can be any type, and can change type on reassignment. There is no JS equivalent of "the compiler rejects this."

string? name = null;
Console.WriteLine(name is null);

let name;        // undefined
let city = null; // null
// referencing an undeclared name throws

C# (8+) has nullable reference types as an opt-in, compiler-enforced annotation on top of one null. JavaScript has no nullable-type annotations at all, but splits "nothing" into two runtime values plus a third failure mode — an unassigned variable is undefined, a deliberately empty one is null, and an undeclared name throws outright. This course's Lab 04 covers the split in full.

1 == "1"; // compile error — no implicit conversion

1 == "1"  // true  (coerces)
1 === "1" // false (no coercion)

C#'s == either compares matching types directly or calls an overloaded operator you (or the type) defined — mismatched types across most built-ins are a compile error, not a runtime surprise. JavaScript's == silently converts one or both operands before comparing; === is the one that behaves closer to what a C# developer expects from ==. Default to ===.

public class Dog {
    public string Name { get; }
    public Dog(string name) => Name = name;
}

class Dog {
  constructor(name) {
    this.name = name;
  }
}

In C#, class is the object model — types, vtables, and inheritance are class-based all the way down. In JavaScript, class is syntax sitting on top of a completely different underlying mechanism: prototype-based inheritance, where instances link directly to another object instead of to a compiler-managed type. It reads similarly; it is not the same model underneath. This course spends several labs specifically on that distinction.

public int Age { get; set; }

class Person {
  #age;
  get age() { return this.#age; }
  set age(v) { this.#age = v; }
}

C# auto-properties generate a backing field for you. JavaScript has no auto-property equivalent — a real getter/setter pair with a backing field is always written out by hand (here using a genuinely private #field, not just a naming convention).

public interface IQuacks { void Quack(); }
public class Duck : IQuacks {
    public void Quack() { }
}

function makeItQuack(thing) {
  thing.quack(); // works if thing HAS a quack method
}                // nothing declares this requirement anywhere

C#'s interfaces are a compile-time contract — implementing one is declared and checked. JavaScript has no built-in interface concept at all: if an object happens to have the right method, calling it works; if it doesn't, you get a runtime TypeError the moment it's called, not before. (TypeScript adds compile-time structural interfaces back on top of JavaScript, but plain JS has none.)

struct Point { public int X, Y; }
Point a = new Point { X = 1 };
Point b = a; // real copy
b.X = 99;    // a.X is still 1

let a = { x: 1 };
let b = a;   // same object, not a copy
b.x = 99;    // a.x is now 99 too

C# lets you define your own value types (struct) that copy on assignment. JavaScript has no user-definable value type at all — only primitives (number, string, boolean, etc.) copy by value; every object, array, and function you create is always a reference, always shared on assignment, with no opt-out. There's no JS equivalent of "make this type copy like an int does."

await Task.Run(() => HeavyCpuWork());
// can genuinely run on another thread

await someAsyncCall();
// still runs on the SAME single thread as everything else

This is the one most worth slowing down for. C#'s Task/async/await can genuinely hand CPU-bound work to another OS thread via the thread pool — real parallelism is available. JavaScript is single-threaded, full stop, in every environment (browser tab or Node process) — async/await never creates a new thread; it's sugar over the event loop deciding when a paused function resumes on that same one thread. A CPU-heavy async function in JS still blocks everything else while it runs. This course dedicates several labs specifically to that model.

// csc compiles source -> IL (a .dll/.exe)
// CLR loads the IL and JIT-compiles it to
// native code at (or before) run time

// no separate build artifact by default —
// an engine (V8, SpiderMonkey, ...) parses
// source directly, interprets and/or
// JIT-compiles hot paths while running

C# has a distinct ahead-of-time compile step producing an intermediate-language artifact, which the CLR then JIT-compiles at load/run time. Plain JavaScript has no separate compiled-artifact step at all in the way C# does — a JS engine goes from source text to running code itself, typically using a mix of parsing, interpretation, and JIT compilation internally, with no IL-equivalent file ever produced. "Compiled vs. interpreted" undersells how different these two pipelines actually are.

private, protected, internal,
protected internal, public
// all compiler-enforced

class Account {
  #balance = 0; // truly private, enforced by the engine
  balance = 0;  // public — that's the only other option
}

C# has a full set of compiler-checked access modifiers, including cross-assembly visibility (internal) with no JavaScript equivalent at all. JavaScript has exactly two real states: public (the default), or truly private via a #field (engine-enforced, added relatively recently to the language). There is no built-in protected or module-internal visibility — older JS code faked "private" with a leading underscore, which was never actually enforced by anything.