ESX vs QBCore vs QBox: Welches FiveM Framework solltest du 2026 waehlen?
Wenn du einen FiveM Roleplay Server aufbaust, ist die erste grosse Entscheidung dein Framework. ESX, QBCore und QBox dominieren die FiveM-Szene -- jedes hat seine Staerken, Kompromisse und idealen Einsatzgebiete.
Dieser Vergleich analysiert alle drei, ehrlich. Wir verkaufen Scripts, die mit allen funktionieren, also haben wir kein Pferd in diesem Rennen -- wir wollen nur, dass du die richtige Grundlage fuer dein Projekt waehlst.
Wenn du ganz neu bei FiveM bist, solltest du vielleicht zuerst Einen FiveM Server erstellen lesen.
Inhaltsverzeichnis
- Was ist ein FiveM Framework?
- Schnellvergleich-Tabelle
- ESX (Extended) -- der etablierte Marktfuehrer
- QBCore -- der moderne RP-Standard
- QBox -- der Performance-fokussierte Fork
- Feature-fuer-Feature-Vergleich
- Welches Framework solltest du waehlen?
- Haeufige Fragen zum Wechsel
- FAQ
Was ist ein FiveM Framework?
Ein Framework ist die Grundschicht deines FiveM Servers. Es verwaltet:
- Spielerkonten und Persistenz (Charaktere, Kennungen, Metadaten)
- Geldsysteme (Bargeld, Bank, Schwarzgeld)
- Jobs und Gangs (Polizei, Mechaniker, Rettungsdienst usw.)
- Inventar und Gegenstaende
- Fahrzeugbesitz
- Wohnen/Garagen
- Tod- und Respawn-Logik
Schnellvergleich-Tabelle
| Feature | ESX | QBCore | QBox |
|---|---|---|---|
| Erstveroeffentlichung | 2018 | 2021 | 2023 |
| Lizenz | GPL-3 | GPL-3 | GPL-3 |
| Aktive Wartung | ✅ Aktiv | ✅ Sehr aktiv | ✅ Sehr aktiv |
| Script-Oekosystem | ⭐ Riesig | ⭐ Gross | ⭐ Gross (QBCore-kompatibel) |
| Code-Qualitaet | ⚠️ Altlasten | ✅ Modern | ✅ Sehr modern |
| Performance | ⚠️ Variabel | ✅ Gut | ⭐ Hervorragend |
| Dokumentation | ✅ Umfangreich | ✅ Umfangreich | ⚠️ Wachsend |
| Einsteigerfreundlich | ⭐ Einfach | ✅ Mittel | ⚠️ Mittel-Schwer |
| Von grossen RP-Servern genutzt | ✅ Viele | ⭐ Die meisten | ⚠️ Wachsend |
| Community-Groesse (2026) | Gross | ⭐ Groesste aktive | Kleiner, aber engagiert |
ESX (Extended) -- der etablierte Marktfuehrer
ESX ist das aelteste und historisch beliebteste FiveM Framework. Erstmals 2018 als Fork des originalen ES (EssentialMode) veroeffentlicht, hat es ueber die Jahre Tausende von FiveM-RP-Servern angetrieben.Warum ESX 2026 noch wichtig ist
Riesiges Script-Oekosystem. ESX hat den groessten Katalog an Community-Scripts aller Frameworks. Open-Source-Scripts auf GitHub, kostenpflichtige Scripts auf Tebex, eigene Ressourcen von eingestellten Servern -- der Grossteil der FiveM-Geschichte wurde in ESX geschrieben. Wenn du "ein Script, das X macht" suchst, gibt es hoechstwahrscheinlich eine ESX-Version davon. Einfach Tutorials zu finden. Suche auf YouTube nach "FiveM Roleplay Tutorial" und 80% der Ergebnisse basieren auf ESX. Die Lernkurve ist sanfter als bei den Alternativen. Den meisten Entwicklern vertraut. Wenn du einen FiveM-Entwickler als Freelancer engagierst, kennt er mit ziemlicher Sicherheit ESX.Die Nachteile von ESX
Angesammelte technische Altlasten. ESX wurde ueber 6+ Jahre gepatcht und erweitert. Einige Kernbereiche des Codes zeigen ihr Alter. Die Performance kann je nach Server-Konfiguration stark variieren. Fragmentierte ESX-Versionen. "ESX" bedeutet heute normalerweise ESX Legacy (die gepflegte Version), aber es gibt auch Forks: ESX 1.x, ESX V1 Final usw. Waehle ESX Legacy -- alles andere wird nicht mehr gepflegt. Performance-Scripts brauchen oft Optimierung. Viele ESX-Ressourcen von 2018-2020 wurden geschrieben, bevor resmon-Optimierung in der Community Prioritaet hatte. Erwarte, aeltere Scripts optimieren oder ersetzen zu muessen.Am besten fuer
- Absolute Einsteiger, die maximale Tutorials und Community-Support wollen
- Server, die Script-Vielfalt ueber modernen Code priorisieren
- Communities, die von aelteren ESX-Servern migrieren und das Framework bereits kennen
ESX-Ressourcen
- Dokumentation: docs.esx-framework.org
- GitHub: github.com/esx-framework/esx-legacy
- Wichtige Ressourcen:
esx_addonaccount,esx_addoninventory,esx_property,esx_society
QBCore -- der moderne RP-Standard
QBCore entstand 2021 als saubere, moderne Alternative zu ESX. Von Grund auf mit besserer Architektur entwickelt, wurde es schnell zur De-facto-Wahl fuer neue RP-Server.Warum QBCore 2026 dominiert
Bessere Code-Architektur. QBCore wurde mit Modularitaet im Sinn entworfen. Job-Systeme, Inventar, Metadaten -- alles ist sauberer getrennt als bei ESX. Riesige aktive Community. QBCore hat ESX bei aktiven Community-Beitraegen ueberholt. Neue Scripts werden zuerst fuer QBCore veroeffentlicht und manchmal anschliessend fuer ESX portiert. Ausgefeilte UI-Komponenten. Moderne HUDs, Telefone und Inventar-Designs sind zunehmend QBCore-first. Grosse UI-Ueberarbeitungen (wieqb-inventory zu ox_inventory) erscheinen fuer QBCore.
Besseres Metadaten-System. Das Spieler-Metadaten-System von QBCore erleichtert das Hinzufuegen eigener Statistiken, Attribute oder Fortschritte erheblich, ohne das Datenbank-Schema aendern zu muessen.
Die Nachteile von QBCore
Weniger Script-Vielfalt als ESX (in absoluten Zahlen). Waehrend QBCore mehr neue Scripts hat, hat ESX dank seines 5-jaehrigen Vorsprungs mehr Scripts insgesamt. Etwas steilere Lernkurve. Die sauberere Architektur bedeutet, dass Neulinge mehr Konzepte verstehen muessen: Metadaten, State Bags, Shared/Server/Client-Aufteilungen. Einige Kernsysteme sind eigenwillig. QBCore trifft spezifische Entscheidungen (z.B. sein Job-System, Charakter-Erstellungsablauf), die nicht zu deiner Vision passen koennten. Erwarte, einige Kernmodule anpassen zu muessen.Am besten fuer
- Ernsthafte RP-Communities, die 2026 von Grund auf aufbauen
- Server-Betreiber, die modernen, wartbaren Code wollen
- Communities, die eigene Scripts schreiben oder anpassen wollen
QBCore-Ressourcen
- Dokumentation: docs.qbcore.org
- GitHub: github.com/qbcore-framework
- Wichtige Ressourcen:
qb-core,qb-inventory,qb-phone,qb-management,ox_lib
QBox -- der Performance-fokussierte Fork
QBox (manchmal QBX genannt) ist ein 2023 erschienener Fork von QBCore, der Performance und Modularitaet priorisiert. Gepflegt von ehemaligen QBCore-Mitwirkenden, zielt es darauf ab, architektonische Probleme zu beheben und dabei weitgehend mit QBCore-Ressourcen kompatibel zu bleiben.Warum QBox an Fahrt gewinnt
Bessere Performance ab Werk. QBox nutzt native FiveM-Features (State Bags,ox_lib, oxmysql) aggressiver als QBCore. Das Ergebnis: niedrigerer resmon-Wert, geringerer Speicherverbrauch, weniger Tick-Loops.
Saubererer Kern. QBox hat Legacy-Code-Patterns aus QBCore entfernt. Die Codebasis ist kleiner, lesbarer und einfacher zu erweitern.
Kompatibel mit den meisten QBCore-Scripts. Das ist das Killer-Feature. Die meisten QBCore-Scripts funktionieren auf QBox mit minimalen Anpassungen. Du erbst das gesamte QBCore-Oekosystem.
Aktive Entwicklung. QBox entwickelt sich schnell weiter. Neue Features erscheinen monatlich, und das Entwicklerteam reagiert auf Community-Feedback.
Die Nachteile von QBox
Kleinere Community (vorerst). QBox ist juenger. Der Discord ist kleiner, es gibt weniger Tutorials, weniger Stack-Overflow-Inhalte. Du musst moeglicherweise oefter den Quellcode lesen. Einige QBCore-Scripts brauchen Anpassungen. Waehrend die meisten funktionieren, haben einige QBCore-Ressourcen hartcodierte Pfade oder Annahmen, die auf QBox nicht funktionieren. Plane gelegentliches Debugging ein. Dokumentation noch in Entwicklung. Die QBox-Dokumentation ist gut, aber weniger umfassend als die von QBCore. Einige Features sind hauptsaechlich im Quellcode dokumentiert.Am besten fuer
- Technisch versierte Server-Betreiber, die bereit sind, Quellcode zu lesen
- Performance-kritische Server, die an der Kapazitaetsgrenze laufen
- Server-Betreiber, die eigene Frameworks auf Basis von QBCore-Patterns aufbauen
QBox-Ressourcen
- Dokumentation: qbox.re
- GitHub: github.com/Qbox-project
- Wichtige Ressourcen:
qbx_core,qbx_management,ox_inventory,ox_lib
Feature-fuer-Feature-Vergleich
Inventarsystem
- ESX: wird mit
esx_inventoryausgeliefert, oft durchox_inventoryersetzt. Brauchbarer Standard, leicht austauschbar. - QBCore: wird mit
qb-inventoryausgeliefert. Die meisten Server ersetzen es durchox_inventoryfuer bessere Performance. - QBox: wird mit integriertem
ox_inventoryausgeliefert. Bestes Inventarerlebnis ab Werk.
ox_inventory.
Job-System
- ESX: klassisches Society-System. Funktional, veraltete UI.
- QBCore:
qb-managementbietet Job-/Gang-Panels. Moderner. - QBox:
qbx_managementist noch sauberer.
Telefon-Integration
- ESX: jedes Telefon funktioniert (
gks-phone,lb-phone,qs-smartphone). Kein "offizielles" Telefon. - QBCore:
qb-phoneist die offizielle Option, aber die meisten Server nutzenlb-phoneoderqs-smartphonefuer mehr Qualitaet. - QBox: wie QBCore -- Telefon nach Wahl.
Voice-System
- ESX, QBCore, QBox: alle drei nutzen ueblicherweise
pma-voice. Framework-agnostisch.
Datenbank-Schema
- ESX: aelteres Schema-Design mit mehreren Legacy-Tabellen (
addon_account,addon_inventory_items). - QBCore: saubereres Schema mit
players-Tabelle, die die meisten Daten haelt. - QBox: sehr aehnlich wie QBCore, leicht normalisiert.
Performance
Gemessen auf dem gleichen 32-Slot-RP-Server mit vergleichbaren Scripts:
| Framework | Durchschn. Server-Tick (Leerlauf) | Durchschn. Server-Tick (voll) |
|---|---|---|
| ESX Legacy | 2,8 ms | 8,5 ms |
| QBCore | 1,9 ms | 6,2 ms |
| QBox | 1,4 ms | 4,8 ms |
Script-Kompatibilitaet
- ESX: der groesste Script-Katalog, aber viele altern.
- QBCore: grosser moderner Katalog. Die meisten neuen Scripts zielen zuerst auf QBCore ab.
- QBox: erbt ~85% des QBCore-Katalogs mit kleinen Anpassungen.
Welches Framework solltest du waehlen?
Es gibt kein universell "bestes" Framework. Waehle basierend auf deiner Situation:
Waehle ESX, wenn...
- Du ein absoluter Einsteiger bist und maximale Tutorial-Abdeckung willst
- Du einen bestehenden ESX-Server uebernimmst
- Du Script-Vielfalt ueber modernen Code stellst
- Du einen Entwickler hast, der mit ESX-Patterns vertraut ist
Waehle QBCore, wenn...
- Du einen ernsthaften RP-Server von Grund auf aufbaust
- Du die groesste aktive Community willst
- Du planst, viele Community-Scripts zu installieren
- Du modernen Code mit bewaehrter Stabilitaet willst
Waehle QBox, wenn...
- Performance fuer deinen Server kritisch ist
- Du bereit bist, Quellcode nach Loesungen zu durchsuchen
- Du frisch startest und die modernste Grundlage willst
- Dir eine kleinere (aber engagierte) Community nichts ausmacht
Waehle Standalone, wenn...
- Du keinen traditionellen RP-Server baust
- Du Minispiele, Drift, DM, Rennen oder andere Spielmodi betreibst
- Du maximale Kontrolle ohne Framework-Annahmen willst
Ein Framework-agnostischer Ansatz
Bei HZ-Scripts entwickeln wir unsere Ressourcen bewusst Framework-agnostisch. Jedes HZ-Script erkennt automatisch, ob dein Server ESX, QBCore, QBox oder Standalone nutzt, und passt sich entsprechend an.
Das bedeutet:
- Du kannst das Framework spaeter wechseln, ohne unsere Scripts neu kaufen zu muessen
- Du kannst mehrere Testserver auf verschiedenen Frameworks mit dem gleichen Script-Katalog betreiben
- Du vermeidest Vendor Lock-in bei einzelnen Scripts
- HZ-Weather Pro -- funktioniert auf ESX, QBCore, QBox, Standalone. Automatische Erkennung, keine Konfiguration noetig.
- HZ-Television -- ebenso. Plug-and-Play ueber alle Frameworks.
- HZ-AudioMixer -- vollstaendig standalone, keine Framework-Abhaengigkeit.
Haeufige Fragen zum Wechsel
Kann ich spaeter von ESX zu QBCore migrieren?
Ja, aber es ist ein erheblicher Aufwand. Plane ein:
- Datenbankmigration -- Mapping der
users-Tabelle aufplayers, Transfer von Inventaren, Jobs, Geld - Script-Ersatz -- die meisten ESX-Scripts funktionieren nicht auf QBCore. Finde QBCore-Aequivalente.
- Spielerdaten erhalten -- gehe sorgfaeltig mit bestehenden Charakteren um (oder akzeptiere Datenverlust)
- Zeitrahmen -- 2-4 Wochen dedizierte Arbeit fuer einen mittelgrossen Server, oft mehr
esx-to-qbcore-converter), aber keines funktioniert vollautomatisch.
Kann ich zwei Frameworks auf dem gleichen Server betreiben?
Nicht wirklich. Waehrend es technisch moeglich ist, sowohl es_extended als auch qb-core zu laden, wirst du staendige Konflikte bei Spieler-Kennungen, Geldsystemen und Event-Namen haben. Waehle eines.
Wird mein Framework aussterben?
Unwahrscheinlich fuer ESX, QBCore oder QBox. Alle drei werden aktiv gepflegt mit starken Communities. Das Risiko ist hoeher bei kleineren Forks (aeltere ESX-Versionen, weniger populaere Alternativen). Bleibe bei den grossen drei fuer Sicherheit.
Kann ich mein eigenes Framework schreiben?
Ja, und einige grosse Server tun das. NoPixel laeuft bekanntermassen auf einem stark angepassten hauseigenen Framework. Aber von Grund auf zu bauen erfordert erhebliche Lua-Expertise und 6-12 Monate Arbeit, bevor du Feature-Paritaet mit QBCore erreichst. Tu dies nicht, es sei denn, du hast einen spezifischen Grund -- starte mit QBCore oder QBox, dann passe schrittweise an.
Wie geht es weiter?
Jetzt, wo du dich entschieden hast (oder zu einem Framework tendierst):
- Richte deinen Server richtig ein -- Kompletter Einsteiger-Guide zum Erstellen eines FiveM Servers
- Meistere dein Verwaltungspanel -- txAdmin Setup Guide
- Waehle deine ersten Scripts -- Erste Scripts fuer deinen FiveM Server
Die Framework-Wahl ist keine Frage von Leben und Tod -- die meisten erfolgreichen Server laufen auf einem der drei. Was mehr zaehlt, ist Konsistenz: Waehle eines, lerne es gruendlich und baue deine Community auf einem stabilen Fundament auf.
FAQ
Lies die FAQ-Abschnitte oben fuer spezifische Fragen oder springe zu unseren anderen Guides fuer tiefere Einblicke in einzelne Themen.
