Framework-Vergleich
QBCore vs ESX Legacy
Wenn du 2026 einen neuen FiveM-Roleplay-Server aufsetzt, legt die Wahl des Frameworks fast jede spätere Entscheidung fest: welche Scripts du installieren kannst, wie sich der Einstieg für deine Spieler anfühlt und wie viel Zeit du mit dem Patchen von Updates verbringst. QBCore und ESX sind die zwei dominierenden Optionen, und obwohl sie sich stark überschneiden, kommt es auf die Unterschiede an. Dies ist ein technischer Vergleich ohne Marketing, basierend auf echtem Produktiveinsatz beider Frameworks im Jahr 2026.
Kurze Antwort
Fazit
Für einen komplett neuen Server im Jahr 2026 ist QBCore die sicherere Wahl: weniger mentaler Aufwand, moderne Statebag-Muster, bessere langfristige Wartbarkeit. ESX Legacy gewinnt weiterhin, wenn du eine bestehende Spielerbasis übernimmst oder eine Wirtschaft rund um legale Jobs aufbaust, bei der der riesige Script-Katalog schwerer wiegt als die Modernität des Frameworks. Wählst du rein nach Leistung, liegt QBCore knapp vorn.
Im direkten Vergleich
Vergleich Punkt für Punkt
14 Kriterien. Die hervorgehobene Zelle zeigt die Option mit Vorteil; Gleichstände bleiben unmarkiert.
| Kriterium | QBCore | ESX Legacy |
|---|---|---|
| Architektur | Modulares Ressourcensystem, Config pro Ressource Vorteil | Monolithischer Kern, gemeinsame Config |
| Shared-Object-Bootstrap | QBCore = exports['qb-core']:GetCoreObject() Vorteil | ESX = nil; TriggerEvent('esx:getSharedObject') |
| Standard-Inventar Gleichstand | qb-inventory (Raster), wechselt automatisch zu ox_inventory, falls vorhanden | esx_inventoryhud (Raster), wechselt automatisch zu ox_inventory |
| Menüsystem Gleichstand | qb-menu, qb-input, ox_lib | esx_menu_default, esx_context, ox_lib |
| Größe des Script-Ökosystems | ~40% des aktiven Tebex-Katalogs | ~55% des aktiven Tebex-Katalogs Vorteil |
| Neue Scripts (2025-2026) | Die meisten neuen Releases zielen zuerst auf QBCore Vorteil | Neue Releases werden meist nach QBCore portiert |
| Whitelist-Jobs / Rangsystem | Boss-Menüs + Ränge direkt in qb-core Vorteil | Manuelles TriggerServerCallback-Muster |
| Statebag-Muster | Moderne Statebag-Unterstützung ab Werk Vorteil | Nachgerüstet, manche Scripts nutzen noch Events |
| Serverübergreifende Migration | Shared-Items-Tabelle von qb-core ist portabel Vorteil | SQL-Exports funktionieren, aber mit Anpassung pro Server |
| Cfx.re-Escrow-Unterstützung | Fester Teil der Design-Doku von qb-core Vorteil | Unterstützt, aber mit eigenen Konventionen pro Ressource |
| Community-Doku | docs.qbcore.org – aktuell, offiziell Vorteil | Documentation.esx-framework.com – veraltet |
| Lernkurve | Mittel – das Modulare kann anfangs verwirren | Niedrig – flache Struktur, leichter per grep zu durchsuchen Vorteil |
| Resmon im Leerlauf | ~0.02ms Basis (qb-core) Vorteil | ~0.03ms Basis (es_extended) |
| Skalierung der Spielerzahl | Mit 128+ Spielern bei geringem Aufwand getestet Vorteil | Mit 96 Spielern getestet; 128 erfordert Tuning |
Entscheiden
Wann du was wählst
Wähle QBCore
- Du baust 2026 einen neuen Server
Bei QBCore findet die Entwicklung neuer Scripts statt – Releases aus 2025-2026 zielen zuerst darauf, dein künftiges Script-Budget reicht also weiter.
- Du willst Boss-Menüs + Whitelist-Jobs ab Werk
Das Rangsystem von
qb-coreund die Boss-Menüs für Polizei / EMS / Mechaniker sind fest eingebaut. Mit ESX kommst du auch ans Ziel, aber das Boss-Menü schreibst du selbst. - Dir sind Statebags + moderne Muster wichtig
QBCore ist für den Spielerzustand rund um Statebags aufgebaut – dieses Muster ist schneller und berechenbarer als das Callback- / Event-Modell von ESX.
- Langfristige Wartbarkeit
Dank des modularen Ressourcensystems lässt sich eine Komponente (Häuser, Inventar, Jobs) aktualisieren, ohne den Kern anzufassen. Ein saubererer Upgrade-Pfad.
Wähle ESX Legacy
- Du übernimmst einen bestehenden ESX-Server
Live-Daten von ESX nach QBCore zu migrieren ist möglich, aber nicht trivial. Läuft der Server bereits mit ESX und aktiver Spielerbasis, ist es meist richtig, bei ESX zu bleiben.
- Du brauchst sofort den größten Script-Katalog
ESX hält nach Produktanzahl weiterhin ~55% des aktiven Tebex-Markts. Brauchst du ein ganz bestimmtes Nischen-Script, das es nur für ESX gibt, ist die Sache entschieden.
- Dein Team kennt ESX in- und auswendig
Das Wissen im Team schlägt theoretische Vorteile eines Frameworks. Sind deine Entwickler ESX-Veteranen, ist die Lernkurve von QBCore ein echter Preis, den du vorab zahlst.
- Du willst flachen Code, leicht per grep durchsuchbar
Die monolithische Struktur von ESX lässt sich leichter von Anfang bis Ende erkunden als die modularen Ressourcen von QBCore. Ein einfacheres Denkmodell für Solo-Entwickler.
Gut zu wissen
Häufige Fragen: QBCore vs ESX
Ist QBCore 2026 besser als ESX?
Kann ich meinen ESX-Server zu QBCore migrieren?
esx-to-qbcore), aber rechne selbst bei einem mittelgroßen Server mit mindestens 1-2 Wochen Entwicklungsarbeit.Nutzen QBCore und ESX dieselben Scripts?
[QBCore/ESX] unterstützen beide per Erkennung zur Laufzeit. Scripts für nur ein Framework sind nicht austauschbar – sie hängen von framework-spezifischen Shared Objects und Event-Mustern ab.