ESX vs QBCore vs QBOX: Technischer Framework-Vergleich 2026

Einführung

Die Wahl eines Frameworks ist die einzeln folgenreichste Entscheidung beim Aufbau eines FiveM-Servers. Sie bestimmt, welche Scripts du nutzen kannst, wie deine Entwickler Code schreiben, die Performance-Obergrenze deines Servers und die langfristige Wartbarkeit deines Stacks. In 2026 dominieren drei Frameworks die Szene: ESX Legacy, QBCore und QBox. Jedes hat eigene Stärken, Trade-offs und ideale Anwendungsfälle.

Das ist ein technischer Vergleich — kein Popularitätswettbewerb. Wir behandeln Architektur, API-Design, Performance, Ökosystem-Reife und zukünftige Entwicklung. Am Ende hast du ein klares Bild, welches Framework zu deiner spezifischen Situation passt.

Framework-Ursprünge und Philosophie

ESX Legacy

ESX (EssentialMode Extended) ist das älteste der drei, ursprünglich um 2017 veröffentlicht. ESX Legacy ist der community-gepflegte Fork, der die ursprünglich verlassene Version ersetzte. Seine Designphilosophie priorisiert breite Kompatibilität und Einfachheit — ESX-Scripts sind oft unkompliziert, server-autoritativ und selbst für Anfänger-Entwickler einfach zu modifizieren.

ESX operiert auf einem Job-Grade-System, bei dem jeder Spieler einen Job und eine Stufe innerhalb dieses Jobs hat. Dieses Modell passt sauber zu traditionellen RP-Server-Strukturen und wurde über Jahre durch Community-Beiträge verfeinert.

QBCore

QBCore startete 2020 als moderne Alternative zu ESX. Es führte eine opinioniertere Architektur ein, ein eingebautes Inventar-System, ein Spielerdatenmodell zentriert auf Bürger-IDs und eine Ressourcenstruktur, die konsistente Muster über Scripts hinweg förderte. QBCore wuchs schnell dank aktiver Community, großer kostenloser Script-Bibliothek und der Wahrnehmung einer saubereren Codebasis.

QBCores Philosophie ist Kohäsion — Scripts sollen gemeinsame Muster befolgen, gemeinsame Exporte nutzen und sich in das Core-Spielerdatenobjekt integrieren.

QBox

QBox ist das neueste der drei, als Fork von QBCore mit erheblichen Architekturverbesserungen. Seine primären Ziele waren Performance, Modularität und Korrektheit. QBox disaggregierte QBCores monolithischen Core in kleinere, unabhängig aktualisierbare Module, adoptierte ox_lib als erstklassige Abhängigkeit und führte strengere Muster für Inter-Ressourcen-Kommunikation ein.

Architektur-Vergleich

Core-Struktur

| Aspekt | ESX Legacy | QBCore | QBox | |---|---|---|---| | Core-Design | Monolithische Ressource | Monolithischer Core | Modular (geteilte Ressourcen) | | Spielerdatenmodell | Job + Grade + Accounts | CitizenID + Job + Gang | CitizenID + Job + Gang (verfeinert) | | Inventar | Extern (ox_inventory empfohlen) | qb-inventory (eingebaut) | ox_inventory (eingebaut) | | Primärsprache | Lua | Lua | Lua | | Server-seitige Autorität | Teilweise | Teilweise | Stark | | ox_lib-Abhängigkeit | Optional | Optional | Erforderlich |

Datenbankansatz

Alle drei Frameworks nutzen MySQL via oxmysql (moderner Standard) oder das ältere mysql-async. Das Schema-Design unterscheidet sich erheblich:

• ESX: Spieler gespeichert mit Job, job_grade, accounts JSON-Spalte.
• QBCore: Spieler gespeichert mit citizenid als Primärschlüssel, charinfo und metadata als JSON-Blobs.
• QBox: Ähnlich wie QBCore, aber mit saubererer Trennung zwischen Charakterdaten und Spieler-Metadata.

API-Design und Entwickler-Erfahrung

ESX API

local ESX = exports['es_extended']:getSharedObject()
local xPlayer = ESX.GetPlayerFromId(source)
xPlayer.addMoney(500)
xPlayer.setJob('police', 3)

Die API ist prozedural und leicht nachvollziehbar. Jeder Funktionsaufruf ist explizit. Der Nachteil ist Ausführlichkeit.

QBCore API

local QBCore = exports['qb-core']:GetCoreObject()
local Player = QBCore.Functions.GetPlayer(source)
Player.Functions.AddMoney('cash', 500)
Player.Functions.SetJob('police', 3)

Das Namespacing (QBCore.Functions, Player.Functions) ist strukturierter, erzeugt aber tief verschachtelte Aufrufketten.

QBox API

QBox refaktorierte die API, um ox_lib's Klassensystem und direkte Exporte statt eines globalen Core-Objekts zu nutzen. Das reduziert Kopplung und ermöglicht Tree-Shaking — Ressourcen laden nur, was sie brauchen.

-- QBox nutzt direkte Modul-Imports
local player = require '@qbox-core.modules.player'
local xPlayer = player.getPlayer(source)
xPlayer.addMoney('cash', 500)

Performance-Benchmarks

| Metrik | ESX Legacy | QBCore | QBox | |---|---|---|---| | Core-Ressource Tick-Rate | ~1ms Durchschnitt | ~0,8ms Durchschnitt | ~0,4ms Durchschnitt | | Spieler-Beitrittszeit | Mittel | Mittel | Schnell | | Speicher-Footprint (Core) | Höher | Mittel | Niedriger (modular) | | Script-Ökosystem-Overhead | Stark variierend | Moderat | Niedriger (ox_lib geteilt) | | Datenbankabfrage-Muster | Legacy (einige ineffizient) | Modern (oxmysql) | Modern (oxmysql, optimiert) |

QBoxs modulares Design bedeutet, dass nur geladene Module Speicher und Tick-Zeit verbrauchen. Dieser Unterschied wird bei 80+ Ressourcen messbar.

Script-Ökosystem-Größe

| Kategorie | ESX | QBCore | QBox | |---|---|---|---| | Kostenlose Scripts (GitHub) | Größte | Sehr groß | Wachsend | | Bezahlte Scripts (Tebex) | Größte | Sehr groß | Schnell wachsend | | Native Kompatibilität | Hoch | Hoch | Mittel (einiges Portieren nötig) | | ox_lib nativer Support | Teilweise | Teilweise | Vollständig | | Script-Qualitäts-Untergrenze | Variabel | Variabel | Höher (strengere Muster) |

ESX hat die größte absolute Script-Anzahl durch sein Alter. Viele ESX-Scripts sind jedoch ungepflegte Forks von 2018–2020. QBCores Ökosystem ist konsistenter gepflegt. QBox hat das kleinste Ökosystem, aber die höchste durchschnittliche Script-Qualität.

Community-Aktivität und Support

| Dimension | ESX Legacy | QBCore | QBox | |---|---|---|---| | GitHub Stars | Hoch | Sehr hoch | Hoch (wachsend) | | Discord-Aktivität | Groß, gemischte Qualität | Groß, aktiv | Kleiner, hohes Signal | | Dokumentationsqualität | Moderat | Gut | Gut | | Core-Update-Häufigkeit | Moderat | Aktiv | Sehr aktiv | | Breaking Changes | Selten | Gelegentlich | Öfter (frühes Stadium) |

Inventar-System-Integration

• ESX: Standard-Inventar ist einfach; die meisten Server ersetzen es durch ox_inventory oder lj-inventory
• QBCore: Kommt mit qb-inventory; viele Server wechseln zu ox_inventory für bessere Performance
• QBox: Kommt nativ mit ox_inventory; keine Migration nötig

Migrationspfade

ESX zu QBCore

Die ESX-zu-QBCore-Migration ist der häufigste Server-Übergang. Spielerdaten erfordern ein Migrations-Script. Die meisten Scripts erfordern eine framework-spezifische Version. Erwarte 2–4 Wochen Entwicklungszeit für eine vollständige Migration.

QBCore zu QBox

Das ist eine chirurgischere Migration. QBox ist ein QBCore-Fork, daher sind die Spielerdaten-Schemas ähnlich. Die Hauptarbeit beinhaltet das Aktualisieren von Ressource-Imports und das Ersetzen von qb-spezifischen UI-Aufrufen durch ox_lib-Äquivalente.

ESX zu QBox

Die schwierigste Migration. Im Wesentlichen den Server von Grund auf mit einem neuen Datenmodell neu aufbauen. Nur für kleine, frisch gewischte Server empfohlen.

Welches Framework solltest du wählen?

| Szenario | Empfehlung | |---|---| | Erster Server, Anfänger-Entwickler | ESX Legacy | | Etablierter Server, große kostenlose Script-Bedürfnisse | QBCore | | Neuer Server, Performance-Fokus, moderne Muster | QBox | | Großes Team, langfristige Wartbarkeit Priorität | QBox | | Bestehender ESX-Server, keine Migration | ESX Legacy (behalten, optimieren) | | Bestehender QBCore-Server, der ein Upgrade erwägt | QBox (migrieren) |

Server einrichten

Unabhängig davon, welches Framework du wählst, erfordert eine solide Grundlage mehr als nur den Core. Siehe unseren vollständigen FiveM-Server-Setup-Guide und unsere Übersicht der wesentlichen FiveM-Scripts.

Zukunftsausblick (2026 und darüber hinaus)

ESX Legacy wird durch die installierte Basis-Trägheit nach der reinen Server-Anzahl für Jahre dominant bleiben. QBCore wird weiterhin starke Community-Aktivität und Script-Releases sehen. QBox ist als Framework der Wahl für neue Projekte positioniert — seine Architekturentscheidungen sind auf den Kurs der FiveM-Entwickler-Community ausgerichtet: modulare Ressourcen, ox_lib als gemeinsamer Standard und strengere Server-Autoritäts-Muster.

Der Trend über alle drei Frameworks hinweg ist die Konvergenz in Richtung ox_lib für UI- und Utility-Funktionen. Wenn du heute einen neuen Server startest, gibt dir QBox den zukunftssichersten Ausgangspunkt.

FAQ

Kann ich QBCore-Scripts auf einem QBox-Server nutzen?

Viele QBCore-Scripts funktionieren auf QBox mit kleineren Modifikationen, da QBox ein Fork ist. Die Hauptänderungen sind das Aktualisieren von Import-Pfaden und das Ersetzen von qb-spezifischen UI-Aufrufen durch ox_lib-Äquivalente.

Ist ESX in 2026 tot?

Nein. ESX Legacy wird aktiv gepflegt und tausende Server laufen erfolgreich auf ESX in 2026. Es ist nicht die modernste Wahl für neue Projekte, aber weit entfernt vom Tod.

Beeinflusst die Framework-Wahl die Spieler-Erfahrung?

Direkt weniger als man denkt — Spieler erleben die auf dem Framework aufgebauten Scripts, nicht das Framework selbst. Indirekt beeinflusst die Framework-Wahl, welche Scripts installiert werden können, wie poliert diese sind und die Server-Performance unter Last.

Was ist ox_lib und warum benötigt QBox es?

ox_lib ist eine geteilte Ressourcen-Bibliothek, die vom Overextended-Team gepflegt wird. Sie bietet UI-Komponenten (Progress Bars, Kontextmenüs, Radial-Menüs, Benachrichtigungen), Utility-Funktionen und klassenbasierte OOP-Muster für Lua. Lerne mehr im ox_lib-Vollständigen-Guide.