JavaScript.CodeCompared.To/GDScript

Nothing surprising yet, which is the point of starting here. GDScript is deliberately Python-flavored: no semicolons, no braces, and indentation decides what belongs to what. The bigger difference is where the code lives, and the Scene Tree section is where that story starts — in a Godot project a file of GDScript is attached to a node, and the engine calls into it rather than the other way round.

The % operator takes a single value on the right, or an Array when there is more than one — and unlike a template literal it carries a format: %.2f is toFixed(2), %05d is padStart(5, "0"), and both are checked against the value's type when the script loads. There is also "{name} scored {score}".format({ "name": name }) for named placeholders. What there is not is an expression inside the string — everything interpolated has to be a value you already have.

print already renders a Dictionary or an Array readably, so there is no console.dir to reach for. var_to_str is the closest thing to JSON.stringify with indentation — it produces GDScript's own literal syntax, which round-trips through str_to_var. Godot also ships a real JSON class when the destination is a file or a network peer rather than your own eyes.

GDScript's const is stricter than JavaScript's: it must be initialized with a value the compiler can work out at load time, so const NOW = Time.get_ticks_msec() is a load-time error rather than a constant that happens to be computed once. That also means there is no const for "this reference will not be reassigned but its contents will change" — a Dictionary you intend to mutate is a var. The screaming-case name is a convention rather than a rule, but the engine's own source follows it everywhere.

var speed := 200.0 means "infer this variable's type from its first value and check every later assignment against it". Assigning a String to it afterwards is an error caught when the script loads, before the game runs. A bare var speed = 200.0 is the JavaScript binding you already know — it holds a Variant, which is Godot's tagged union of every type. The reason to prefer := is not only safety: an annotated variable skips Variant dispatch and the difference is commonly quoted at two to four times, which matters when the code runs sixty times a second.

This is the same annotation := produced, written out — worth doing when the inferred type would be wrong (var speed := 200 infers int, not float) or when the declaration has no initializer. Array[String] is a genuinely typed array: appending an int to it fails, where a JavaScript array with a JSDoc annotation only fails if someone runs a type checker over it. A JavaScript developer will recognize the trade — this is what TypeScript does, except that the checking is part of the language rather than a build step, and it is optional per variable rather than per file.

There is no undefined in GDScript, so the whole family of distinctions that follows from it — ?? against ||, == null catching both, a missing property differing from a property set to null — simply does not arise. Reading a key that is not in a Dictionary with settings["missing"] is an error rather than undefined; get(key, fallback) is the deliberate way to ask, and it plays the role of ??.

GDScript's typeof returns an integer from the Variant.Type enum, and type_string turns it into something readable — so it is closer to Object.prototype.toString.call than to JavaScript's typeof, in that it distinguishes types JavaScript collapses. is is the operator to reach for in real code: it works for built-in types and for your own classes, the way instanceof does, and unlike instanceof it also works for the primitives.

JavaScript has one number type, so division always produces the mathematical answer. GDScript has int and float as genuinely separate types, and dividing two ints performs integer division — 7 / 2 is 3, with no warning, because that is what a C-family language does and Godot's engine is C++. Make one side a float and you get the answer you expected. The habit worth forming is writing game constants as 200.0 rather than 200, which is also why var speed := 200.0 appears throughout this page.

Godot puts the whole of Math in the global scope, so there is no namespace to type. There are also typed variants — floori, roundi, absi, mini, maxi — that return an int rather than a Variant, which is what you want inside a := declaration or a hot loop. Two more worth knowing early because game code is full of them: clamp(value, low, high), and lerp(from, to, weight) for interpolating between two values.

The interesting difference is seed(). Math.random deliberately cannot be seeded, so a JavaScript program that needs reproducible randomness has to bring its own generator. A game engine needs reproducibility for replays, for procedural generation and for tests, so Godot exposes the seed — and gives you randi_range, randf_range and Array.pick_random() so the off-by-one arithmetic in the JavaScript column never has to be written.

Vector2, Vector3, Rect2, Color and Transform2D are value types built into the language with operators — they are copied on assignment, they add and scale with + and *, and they carry the methods the arithmetic keeps needing (length, normalized, distance_to, angle_to, lerp). None of that is a library; there is nothing to import. A JavaScript developer will notice the absence of new, and it is meaningful: these do not allocate on the heap.

The list is the same list with different names, and the naming is the point: GDScript is snake_case throughout, and length() is a method rather than a property, so the parentheses are not optional. The three renames worth memorizing are contains for includes, begins_with / ends_with for startsWith / endsWith, and strip_edges for trim.

The shape is the same but the second argument is not: slice(0, 5) takes an end index while substr(0, 5) takes a length. They agree here only because the start is zero. Negative indexing works with the bracket syntax in both languages, which is why text[-1] needs no at() on the GDScript side.

The surprise is join. In JavaScript it is a method on the array; in GDScript it is a method on the separator, so it reads " and ".join(names) — which is Python's spelling and takes a day to stop looking backwards. Note also that split returns a PackedStringArray, a compact contiguous array of strings with no Variant per element; it behaves like an Array for everything on this page.

"count: " + 3 is an error in GDScript, caught when the script loads rather than producing "count: 3": + between a String and an int has no meaning, so you write str(3) and say what you meant. Going the other way, to_int() never produces a NaN — there is no such value for an int — so unparseable input becomes 0, which is quieter than JavaScript and worth a guard when the input came from a player. "42".is_valid_int() is that guard.

Three renames and one convenience. length is size(), push is append, and pop is pop_back (with pop_front for shift and push_front for unshift). The convenience is that scores[-1] just works, so there is no at() and no scores[scores.length - 1].

The correspondence is nearly exact: map, filter and reduce are the same, some is any and every is all. The two gaps are find — GDScript's find searches for a value, not by predicate, so the filter-then-index above is the idiom — and the fact that these return an untyped Array even when the input was Array[int]. The lambda syntax is covered in the Functions section, and the important thing about it is on the next line.

Both sort in place and return nothing useful, so the JavaScript habit of not writing const sorted = names.sort() transfers directly. The comparator does not: JavaScript wants a number whose sign decides the order, GDScript wants a boolean answering "does a come before b". Returning a number from sort_custom quietly sorts by truthiness, which is the kind of bug that looks like a sorting-algorithm problem for an hour.

There is no spread operator, and two things fill the gap: + concatenates two Arrays into a new one, and append_array merges one into another in place. The copying half matters more. var copy := first makes both names refer to the same Array, exactly as const copy = first would in JavaScript — duplicate() is the deliberate copy, and duplicate(true) is the deep one.

A Packed*Array is a real contiguous buffer with no Variant per element — the same idea as Int32Array, and the family (PackedByteArray, PackedInt32Array, PackedFloat32Array, PackedVector2Array, PackedStringArray) is what the engine's own APIs hand back. Reaching for one is often the difference between "this needs to be written in C++" and "this is fine in GDScript"; the cost is that the element type is fixed and the array is copied on assignment rather than shared.

The keys need quotes. A JavaScript object literal lets you write { name: "Ada" } and treats the bare word as the string; GDScript reserves that spelling for its own Lua-style form and wants { "name": "Ada" }. Reading works both ways — player.score and player["score"] are the same lookup — but writing a new key must use brackets, because player.level = 3 on a Dictionary is a property assignment that fails. Object.keys and Object.values become methods on the Dictionary itself.

There is no optional chaining, and its absence is felt: a chain of ?. becomes a chain of get(key, {}), or a guard clause, or a typed class instead of a nested Dictionary — which is usually the right answer in a codebase that is going to be maintained. Note the harder edge too: settings["missing"] is an error rather than undefined, so has and get are not stylistic choices.

Iterating a Dictionary directly yields its keys, which is the behavior a JavaScript developer expects from for…in rather than from for…of. There is no Object.entries and no destructuring in the loop header, so the value is fetched by key. Both languages preserve insertion order, which is a guarantee JavaScript only made official in ES2015 and Godot has always had.

Misspelling as_dictionary["nmae"] is a run-time error that happens the moment that line executes — which, in a game, may be the moment a rare branch is taken. Misspelling as_instance.nmae is caught when the script loads, before anything runs. On top of that, a typed class member has a real type and skips Variant dispatch. The rule of thumb: a Dictionary is for data whose shape you learn at run time (a save file, a JSON response); anything whose shape you know while writing the code should be a class.

No parentheses, no braces, a colon, and elif. The conditional expression is the same three pieces in a different order — value if condition else other — which reads more like a sentence and less like an operator, and nests far worse, which is arguably the point. The boolean operators are spelled and, or and not; && and || also work and the word forms are what the engine's own code uses.

JavaScript's [] and {} are objects and objects are truthy, which is why if (list) is a null check and if (list.length) is an emptiness check. GDScript makes an empty Array and an empty Dictionary falsy, so if list: is the emptiness check — and a habitual if (list) guard translated literally will now skip the branch for an empty-but-perfectly-valid list. GDScript is also stricter about ==: there is no coercion, so "1" == 1 is simply false and there is no === to reach for.

There is no three-clause for and no ++. for index in 3 counts 0, 1, 2, and for index in range(2, 10, 2) covers the general case. Everything else is a for…of under a shorter name — iterating an Array yields its elements, iterating a Dictionary yields its keys, iterating a String yields its characters. break and continue are unchanged.

match is real pattern matching, not a switch. A pattern can destructure an Array or a Dictionary and bind the pieces (var x, var y), match a type (var value is int), list alternatives (1, 2, 3), or end with .. to mean "and anything else". There is no fall-through and therefore no break, and _ is the default branch. The closest JavaScript equivalent is destructuring assignment plus a chain of ifs, which is exactly what it replaces.

Default parameters work the same way. The annotations are optional and worth writing: -> int is checked at load time against every return in the body, and a call passing the wrong type is caught then too rather than at the call. -> void says the function returns nothing, which the compiler will then hold you to. What GDScript does not have is rest parameters — no ...args — so a function that takes an unknown number of things takes an Array.

A lambda produces a Callable — a value holding a function together with the object it belongs to — and a Callable is invoked with .call(…) rather than with parentheses. That extra word is the price of GDScript not having a callable-object type: double(21) would mean "call the method named double", which is a different thing. A named method also converts to a Callable simply by naming it without parentheses, which is how scored.connect(_on_scored) in the Scene Tree section works.

A JavaScript closure captures the binding, so it sees whatever the variable holds when the closure runs — which is why the loop-variable bug existed before let, and why a closure can be used to share mutable state. A GDScript lambda captures the value at the moment it is created, so it is a snapshot. Neither is wrong, but a JavaScript habit built on the first will silently produce stale numbers under the second. When a lambda genuinely needs to see later changes, give it something whose contents change — an Array, a Dictionary, or the enclosing object's own member, which it reaches through self rather than through capture.

Naming a method without parentheses produces a Callable that already remembers its object, so there is no bind and no lost-this bug — the single most common cause of a broken JavaScript event handler simply does not exist here. GDScript's own bind means something else entirely: callback.bind(extra) pre-supplies trailing arguments, which is JavaScript's partial application rather than its this-binding.

In a Godot project this would be the whole of player.gd: class_name Player registers the name globally so any other script can say Player.new(), and extends RefCounted names the base class — which is also the memory strategy. RefCounted is reference counted and disappears when nothing points at it, Node is owned by its parent in the scene tree, and plain Object must be freed by hand. There is no new keyword; Player.new() is an ordinary static call. And there is no this — members are reachable by name, with self available when you need the object itself.

Almost a transliteration. super(args) calls the parent constructor and super.method() calls the parent's version, exactly as in JavaScript. The differences are that a class declared inside another file is written class Dog extends Animal: rather than being a file of its own, and that GDScript has no interfaces and no multiple inheritance — the composition answer is to attach several nodes to one object, which is the engine's own preferred design and is what the Scene Tree section is about.

The set and get blocks hang directly off the declaration, so there is no shadow field to name and no chance of the two drifting apart. This matters more in Godot than the syntax suggests: a setter is how a value that other things depend on stays consistent — assigning to health can update a health bar, emit a died signal and clamp the number, all without any caller knowing. The one trap is that assigning to the variable inside its own setter does not recurse; it writes the backing storage, which is what you want.

The same idea with the same spelling, and it is newer than a JavaScript developer might guess — static var arrived in Godot 4.1, so older answers on the internet will tell you to use an autoload singleton instead. An autoload is still the right answer for a service that needs to exist for the whole game (an audio manager, a save system): it is a node the engine instantiates at startup and puts at a fixed path, which makes it closer to a module-level singleton than to a static class.

GDScript's _to_string is JavaScript's toString with an underscore, and the leading underscore is a real convention rather than decoration: it marks a method the engine calls, alongside _init, _ready, _process and _draw. A JavaScript developer can read it as "this is a lifecycle hook, not part of my own interface".

GDScript has no exceptions at all — no throw, no try, no catch, no finally. A failure comes back as a value the caller inspects: an Error enum member (OK, ERR_FILE_NOT_FOUND, …), a null, or a sentinel like the -1 above. The reason is a game loop: an exception unwinding through a frame leaves the scene tree in a half-updated state, and a sixty-times-a-second loop has nowhere sensible to put a stack trace. What replaces the safety net is that every caller checks, which is tedious and is why the engine's own APIs return error codes rather than raising. push_error reports the problem to the console and the editor without stopping anything.

This is the shape of nearly every fallible engine API: it returns an Error, OK is zero, and the result is fetched separately once the code says it is safe to. error_string turns the code into something printable. There is also a convenience form, JSON.parse_string(text), which returns the parsed value or null — quicker to write, and it prints an engine error of its own when the input is bad, so it belongs in code where bad input is a bug rather than an expected case.

The important difference is that assert is stripped from release builds entirely — its condition is not merely ignored, it is not compiled, so an assertion whose expression has a side effect will change behavior between your debug run and your shipped game. console.assert stays in the bundle and merely logs. The other two are close: push_warning and push_error print to the console and appear in the editor's Debugger panel with a stack trace, which is where they earn their keep.

There is no Promise. await takes a signal — the same object the Scene Tree section connects handlers to — and suspends the function until that signal fires. create_timer(0.05) makes a one-shot timer object whose timeout signal is what is being awaited, so the line reads as "wait for this timer to go off". A JavaScript developer should notice what is missing: no promise to hold, no .then, no rejection, and therefore no catch — a signal that never fires simply leaves the function suspended forever.

A signal you declare is awaitable for free — there is no separate promise-shaped thing to construct, and await evaluates to whatever the signal carried. (The JavaScript column uses .then rather than a top-level await only so that it runs as a plain script; in a module the two are interchangeable.) call_deferred is the closest analogue to queueMicrotask: it runs the call at the end of the current frame rather than immediately, which is exactly what is needed here so that the await is already listening. The general lesson is that signals are Godot's single asynchrony mechanism — they are the event system, the promise, and the observer pattern all at once, so learning them once pays three times.

A browser runs your code in response to events and is idle in between; a game engine runs a frame sixty times a second whether anything happened or not, and _process(delta) is your slot inside it. delta is the seconds since the previous frame, and multiplying movement by it is what keeps a game running at the same speed on different hardware. The practical consequence for a JavaScript developer: work that would go in a setInterval goes in _process, work that would go in a requestAnimationFrame loop is _process, and blocking the frame is as unforgivable as blocking the event loop — except that here the budget is sixteen milliseconds and it is measured.

They are the same operation. Godot's scene tree is a retained tree of objects that you mutate — which is the DOM, not a game loop — so Node.new() is createElement, add_child is appendChild, get_parent() is parentElement, and get_child_count() is children.length. A web developer arrives at Godot with a working mental model of the central data structure and is usually told they do not. Two differences worth holding on to: a node's name must be unique among its siblings (the engine renames a duplicate for you), and a node is not anywhere until it is added — an unparented node exists, has no position, and will leak if you drop it.

There is no selector language. Lookup is by path — get_node("Hud/Score"), abbreviated $Hud/Score in real code — which is a filesystem path through the tree rather than a query over it. That is less expressive and much faster, and it is one of the places Godot pushes you toward structure: a node that needs another node is expected to be handed it (@export var target: Node) or to find it once in _ready, not to search the tree every frame. find_children exists for the genuinely dynamic case and is the thing to avoid in a hot path.

A detached DOM element is collected when nothing references it. A detached Node is not — Node is manually managed, and a node you removed and forgot is a leak. In practice you rarely call free() as above: queue_free() is the idiom, and it detaches and destroys the node at the end of the current frame, which is safe to call while the engine is in the middle of iterating that node. The pattern to internalize is that queue_free() is remove() and doing only remove_child leaves you holding something you now own.

The mechanism is the same and the guarantees are not. A DOM event name is a string the browser looks up at run time, so a typo in addEventListener("chnaged", …) is silence. A Godot signal is declared on the class with a name and a parameter list, so changed.connect(…) with the wrong name fails when the script loads, and connecting a handler whose signature does not match fails too. Connections are also first-class: disconnect, is_connected and get_connections() all exist, and the editor shows every connection in its Node dock — there is no equivalent of wondering what is listening to a DOM node.

The order is _enter_tree, then every child's _ready, then this node's _ready — so by the time _ready runs, everything beneath you is built, which is exactly the guarantee connectedCallback does not give you about a custom element's children. That ordering is why _ready is where you look up other nodes and connect signals, and _init is only for work that needs nothing from the tree. _exit_tree is disconnectedCallback and is where a manual subscription gets undone.

Line for line, this is the same program. That is the whole argument of this page in one row: a retained object you hold a reference to and mutate, an event you subscribe to, a parent you attach it to. Where they differ is what they are drawing on — HTML reflows into a document whose text is selectable and reachable by a screen reader, while Godot paints a fixed pixel grid that knows nothing about either, and that difference is the real cost of the canvas. A React developer should notice the direction of the comparison. This row is imperative on both sides; React would instead re-derive the button's label from a piece of state and let a reconciler work out the DOM operations. Godot never does that — there is no reconciler, no virtual tree, and no render pass to be inside. Godot is the vanilla column, permanently.

A VBoxContainer is flex-direction: column, and the mapping keeps going: HBoxContainer is row, GridContainer is display: grid, add_theme_constant_override("separation", 10) is gap: 10px, a child's size_flags_horizontal = SIZE_EXPAND_FILL is flex: 1, and a Control's anchors and offsets are position: absolute with inset. It is close enough that a web developer can usually guess the Godot name. The one structural difference: a Godot container is a node in the tree that a script can reach and reconfigure, rather than a property of the parent box.

The two columns are the same length and the same shape, which is the honest result: neither vanilla JavaScript nor GDScript has a template language, so both write the loop and call the constructors. This is the row where a React or Svelte developer feels the gap rather than a JavaScript one — players.map(…) returning JSX, or an {#each} block, collapses this to four lines, and Godot has no answer to it in code. Its answer is elsewhere: a repeated interface is authored once in the editor, saved as a .tscn scene file, and instanced at run time with preload("res://row.tscn").instantiate() — a prefab rather than a template, declarative in a file rather than in the language.

Both are immediate mode: the calls paint and nothing is retained, so changing the circle means running the whole routine again. The difference is who decides when. In JavaScript you call the drawing code yourself, usually from a requestAnimationFrame loop. In Godot you never call _draw — the engine calls it when it decides the node needs repainting, and queue_redraw() is how you tell it that something changed. That is strictly less work and strictly less control, and it is the same bargain _process makes. Note the GDScript column's shape too: no statements at the outer level, just extends and a lifecycle method, which is what a real script file looks like.

The JavaScript column has to build the frame loop: capture a timestamp, subtract the previous one, divide by a thousand, and re-register itself. The GDScript column is the frame loop — _process(delta) is called once per frame with the seconds elapsed already computed, and there is nothing to schedule or cancel (set_process(false) turns it off). That is the whole difference: a browser lends you a frame when you ask, an engine hands you one whether you asked or not. Worth knowing that Godot also offers the declarative form, as a Tween or an AnimationPlayer — for a fixed motion between two values those are the CSS-transition-shaped answer, and they run without your code being involved at all.

CSS is a selector language with a cascade: a rule finds elements by matching, and properties like color and font inherit down the tree unless something overrides them. A Godot Theme is a resource — an object holding named styles keyed by node type ("normal" for "Button"), assigned to a node and applying to everything beneath it. Nothing matches, nothing inherits property by property, and there is no specificity to lose an argument with. The nearest CSS relatives are a design-token file and all: revert, and the practical shape of a Godot project reflects it: one Theme resource authored in the editor for the whole game, plus add_theme_*_override on the handful of nodes that need to differ.

There is no import statement. A script file is a class, and there are two ways to reach another one: class_name Player registers the name globally across the whole project, so nothing needs importing; or preload("res://enemy.gd") loads a file by path at parse time and gives you the class as a value. A JavaScript developer should read class_name as deliberately global — it is closer to a browser global than to an ES module export, and the discipline it needs is naming rather than scoping. preload resolves when the script is parsed and load at run time, which is the distinction between a static import and a dynamic import().

Godot has no package manager. The Asset Library is a website you download a zip from, and installing an addon means copying a folder into res://addons/ and enabling it — there is no version resolution, no lockfile, no transitive dependencies, and no way to say which version you are on except by looking. In practice a Godot project vendors everything and commits it, which is closer to how the web worked before npm than to how it works now. The compensating fact is that the standard library is enormous: physics, audio, navigation, animation, tweening, networking, HTTP, JSON, regular expressions and a UI toolkit are all in the engine, so the number of dependencies a real project needs is much smaller.

The trade is worth stating clearly. TypeScript is more expressive by a wide margin — generics, unions, mapped types, structural typing — and it is a separate toolchain that erases at build time. GDScript's types are nominal, much simpler, and enforced by the runtime that runs your game, with no build step and no configuration. They are also opt-in per variable, which means a codebase can be half-typed; the project setting above is how a team makes untyped declarations a warning or an error, and turning it on is the closest thing to strict mode.

A web build is one artifact because the runtime is already installed on every machine. A Godot export bundles the engine with the game, once per platform, from a prebuilt "export template" — which is why a desktop build is tens of megabytes before your own content and why the Web export is around ten megabytes compressed. The Web target has the tightest constraints (no threads unless the server sends cross-origin isolation headers, no filesystem beyond a virtual one) and is the one a JavaScript developer will try first; it is worth knowing that it is a real Godot rather than a reduced one.

A Python developer expects this; a JavaScript developer usually does not. Beyond the obvious, two specifics bite: a file that mixes tab and space indentation fails to parse rather than merely looking untidy, and the editor defaults to tabs, so pasting space-indented code from a web page produces a confusing error on a line that looks fine. There is no formatter in the box comparable to Prettier — the editor reindents, and gdformat from the community gdtoolkit package is the nearest equivalent.

JavaScript has no dangling references: as long as you hold one, the object is alive. Godot's Node and Object are manually freed, so a variable can outlive what it points at, and touching it afterwards is undefined behavior rather than an exception. is_instance_valid(node) is the guard — it is WeakRef::expired() spelled as a function — and queue_free() is the safe way to destroy something, because it waits until the end of the frame rather than pulling the object out from under code that is mid-iteration. The habit worth forming: prefer queue_free(), and null out any long-lived reference you kept.

JavaScript's mutating array methods return the array, so chaining works and const sorted = names.sort() looks reasonable even though it is a lie about immutability. GDScript's mutating methods return void — sort, reverse, shuffle, append and clear all change the array and hand back nothing — so the same line assigns null and the mistake shows up several lines later. The rule is easy once stated: if a method changes the thing, it returns nothing; if it returns something, it made something new.

A small thing that costs a JavaScript developer a compile error a day for a week. There are no computed properties on the built-in types: length is a method on String, and on an Array or Dictionary it is called size instead. The mistake is caught when the script loads rather than producing undefined, so it is annoying rather than dangerous — which is a fair summary of most of the differences on this page.

GDScript removed the increment operators deliberately — they were a documented source of confusion between the prefix and postfix forms, and += 1 says the same thing without the question. There is likewise no comma operator and no three-clause for, so a loop with two moving indices keeps one in the header and advances the other in the body. None of this is hard; all of it will be typed wrong a dozen times in the first week.

The first half is familiar: an Array and a Dictionary are reference types, assignment aliases them, and duplicate() is the copy (duplicate(true) for a deep one). The second half has no JavaScript equivalent. Vector2, Rect2, Color and Transform2D are value types — assigning one copies it, so point_alias.x = 99 leaves point alone. The practical consequence appears constantly in real code: node.position.x += 1 works, but reading var where := node.position and then mutating where changes nothing, because you are holding a copy.