~3 min read

Why a web developer should care about Godot

An open-source engine with a different philosophy — what it offers a developer coming from the TS/React world.

If Unity feels like a corporate IDE with a subscription (because it is), then Godot is something else. MIT license, 0% royalties, a ~100 MB editor that launches faster than VS Code. Its own ecosystem, its own language, and — for a web developer — a model that is far more intuitive in places.

This encyclopedia runs parallel to the Unity encyclopedia: the same concepts, the same “through web analogies” approach, but a different engine. You can read both, or just one.

What Godot does differently

The main architectural difference from Unity: in Godot a scene is also a prefab. Any object built in the editor as a scene can be instantiated into another scene, inherited from, and have individual nodes overridden. There is no “Scene vs Prefab” divide.

Web

A React component is both a page and a widget. <App /> can contain <Page />, which contains <Modal />. The same mental model at every level.

Unity

In Unity, Scene and Prefab are different entities with different semantics. In Godot, both are a PackedScene. A tree of nodes inside a .tscn file, serialized into a text format (reads like JSON — diffs through git without pain).

What might surprise you (pleasantly)

  1. One script per node, not as many components as you like. Behavior is assembled by composing child nodes, not by piling up components. This is closer to “a chain of HOCs” in React than to the Unity style.
  2. Signals — a built-in pub-sub in every node. Declare signal damaged(amount: int), emit damaged.emit(10), subscribe from anywhere. No UnityEvents and no custom event bus.
  3. GDScript is simple and fast, with a syntax similar to Python. Optional static typing speeds up code by 1.5–2x.
  4. @export var hp: int = 100 is the equivalent of [SerializeField] in Unity, but in one line and with type-hint support in the Inspector.
  5. await signal_name — coroutines and asynchrony are built into the language as a keyword.
  6. Text-based scene (.tscn) and resource (.tres) formats — git diffs are meaningful. Merging branches without the ritual of “who committed the .meta files”.

What might surprise you (unpleasantly)

  1. 3D capabilities trail Unity HDRP / Unreal: there is no native equivalent of Nanite/Lumen, and high-end rendering is more modest. This shows on large photorealistic projects.
  2. Consoles — only through paid partners (W4 Games). No “one-button Build for Switch”.
  3. C# is available, but it requires a separate engine build (“Godot .NET edition”) and does not work on the web. For the web — GDScript only.
  4. Fewer paid assets and plugins than in the Unity Asset Store. The Asset Library / Godot Asset Store works, but there are few “heavyweight” commercial solutions on the level of Cinemachine.
  5. A smaller job market — the industry still leans heavily on Unity and Unreal.

When Godot is the right choice

  • 2D games: a first-class 2D pipeline, not an imitation through a 3D camera. TileMaps with auto-tiles, pixel-perfect, parallax, lighting2D.
  • Small team / solo development: a fast start, open source, MIT.
  • Education and prototyping: a lower barrier to entry than Unity.
  • Web games with GDScript: Godot exports to HTML5/WASM out of the box.
  • Open-source / free software projects: no vendor lock-in.
  • If the ability to fork the engine and fix bugs yourself matters to you.

When it’s better to stay on Unity

  • AAA-level 3D graphics — HDRP/Unreal are still ahead.
  • Console publishing — has to go through middleware, costs money and time.
  • Large teams with an established tooling stack for Unity — migration is expensive.
  • Ready-made SDKs and integrations (mobile ads/mediation, real-time analytics, asset providers).

Where to go next

The next section is a short overview of the Godot stack: versions, languages (GDScript and C#), render pipelines, and accompanying tools. After that comes the main chapter on 3D development.