What a framework is: Qbox, ESX, QBCore
Open any roleplay server and you will see players with money, jobs, an inventory, and a saved identity that survives a restart. Someone had to build all of that. The good news is that they did not, at least not from scratch. A framework is one big resource that hands you players, money, jobs, and inventory out of the box, so your scripts plug into systems that already exist instead of reinventing them. This lesson is the map, not the keyboard. You will learn what a framework is and meet the three big names. Writing real code against one comes later, in the paid Tracks.
What a framework is
A framework is a foundation resource that other scripts are built on top of. Think back to the resource lesson: a resource is a folder of code FiveM loads as one unit. A framework is just a very large, very important one. Where a small resource might add a single shop, a framework adds the systems almost every other script needs in order to work at all.
Concretely, a framework manages four things for you. It tracks the player object: a bundle of everything known about a logged-in character. It handles money: cash, bank, and however else your server splits it. It handles jobs: police, mechanic, taxi, and the ranks inside each. And it handles identity: who this character is and how that gets saved to the database so it is still there tomorrow.
The key idea is that your scripts do not own any of this. They ask the framework. When your shop script needs to charge a player, it does not invent its own money system. It asks the framework, "take 500 from this player," and the framework does the real work. The framework is the shared foundation; your scripts are the floors built on top.
Vocabulary
- framework
- A large foundation resource that gives every other script a ready-made player system: money, jobs, inventory, and saved identity. Your scripts build on top of it instead of rebuilding those systems.
- player object
- A bundle of data the framework keeps for one logged-in character: their money, their job, their identity, and more. When a script asks 'who is this player and how much money do they have', it reads the player object.
- job
- A role a character holds on the server, like police or mechanic, usually with ranks inside it called grades. The framework stores each player's job so any script can check it.
- the core resource
- The single resource that is the framework itself. The other scripts depend on it and ask it for help. Each framework has its own core: qbx_core for Qbox, es_extended for ESX, qb-core for QBCore.
Why frameworks exist
To see why frameworks exist, look at what almost any roleplay feature actually needs. A drug-selling script needs to know who is selling and pay them. A car dealership needs to know if the buyer can afford the car and which one they bought. A police job needs to know who is an officer and what rank they hold. Strip away the surface and nearly every feature asks the same three questions first: who is this player, how much money do they have, and what job are they on.
Now imagine every script answering those questions on its own. The shop would build its own money system. The dealership would build a second, separate one. The two would disagree, the player would have $500 in one and $0 in the other, and the whole server would fall apart. That is the problem a framework solves.
A framework answers those questions once, in one place, and lets every script share the answer. There is a single player object, a single money balance, a single job. The shop and the dealership both read the same number, so they always agree. That shared, single source of truth is the entire reason frameworks exist, and it is why you will almost never see a serious roleplay server running without one.
Picture a busy restaurant. Every waiter could keep their own private notebook of what every table ordered, but then two waiters would bring the same table two different bills. Instead the restaurant keeps one shared ticket system that every waiter reads from and writes to. The framework is that shared ticket system for your server. One source of truth, and everybody works off it.
The three you will hear about
There are three frameworks you will run into again and again. They all do the same job, which is the player-money-jobs foundation you just learned. They differ mostly in their age, their popularity, and the exact way you ask them for things. The tiny code samples below are just a taste of how each one hands you the player object on the server. You are not expected to write these yet. Notice only that all three are the same idea spelled three different ways.
Qbox (qbx_core)
Qbox is the modern, ox-native successor to QBCore, and it is actively maintained. It started as a fork of QBCore and was rebuilt on the ox resources, the same family as ox_lib and oxmysql that you have already met. The practical result is a cleaner, more current way to call the framework. Its core resource is qbx_core. You get the player object by calling an export directly:
-- Qbox, on the server
local player = exports.qbx_core:GetPlayer(source)ESX
ESX is long-established and very widely used, with one of the largest pools of existing scripts and tutorials of any framework. Its core resource is es_extended, and its player object is usually called xPlayer. You grab a shared object first, then ask it for a player by their id:
-- ESX, on the server
local ESX = exports['es_extended']:getSharedObject()
local xPlayer = ESX.GetPlayerFromId(source)QBCore
QBCore is hugely popular and is the framework Qbox was forked from, so the two share a family resemblance in how player data is shaped. Its core resource is qb-core. You grab a core object first, then ask it for the player:
-- QBCore, on the server
local QBCore = exports['qb-core']:GetCoreObject()
local player = QBCore.Functions.GetPlayer(source)Read those three side by side and the lesson is clear. Every framework gives you a way to turn a player id into a player object. The exact words differ, but the question is identical. Once you can see that, learning a second framework is mostly learning its spelling.
How to tell which one a server runs
You do not have to guess which framework a server uses. The answer is sitting in plain sight in the list of resources the server has started. Each framework runs under its own core resource folder, and that folder name is the giveaway.
This is a real skill, not a trivia question. The moment you know which framework a server runs, you know which set of calls to use to read the player, the money, and the job. Reading the resource list is the first thing experienced developers do when they sit down at an unfamiliar server.
You pick one and Track B teaches it
You do not need to choose a framework right now. The whole point of Start Here is to make these names stop being scary, so that when a tutorial or a server config says qbx_core or es_extended, you know exactly what it means. That is enough for this stage.
Common beginner mistakes
These three traps catch nearly everyone the first time they touch frameworks. Knowing them now saves you a confusing evening later.
| Symptom | Fix |
|---|---|
A script does nothing or errors, and it was built for a different framework than the one the server runs | Scripts are written for a specific framework. A QBCore script dropped onto an ESX server cannot find the calls it expects. Match the script to the framework the server actually runs, or use a version built for that framework. |
attempt to index a nil value (assuming ESX code runs on QBCore unchanged) | The frameworks spell the same idea differently. ESX uses ESX.GetPlayerFromId; QBCore uses QBCore.Functions.GetPlayer. Copying one framework's calls into another's server gives nil, because that function does not exist there. Use the calls for the framework you are on. |
Scripts that depend on the framework error on startup with the framework missing | The framework core must start before any script that needs it. In server.cfg, ensure the core (qbx_core, es_extended, or qb-core) above the scripts that depend on it, so it is ready first. |
A server runs qbx_core. Which framework family is it in?
Qbox. The core resource qbx_core is the Qbox core. Qbox is the modern, ox-native successor to QBCore, so it sits in the QB family and shares a similar player-data shape, but the server is running Qbox specifically. If you instead saw qb-core it would be QBCore, and es_extended would be ESX.
Try it yourself
What you can do now
- Explain what a framework is: one foundation resource that hands every script a player object, money, jobs, and inventory.
- Say why frameworks exist: almost every feature asks who, how much money, and what job, so the framework answers it once and all scripts share the answer.
- Name the three you will hear about: Qbox (qbx_core), ESX (es_extended), and QBCore (qb-core), and that Qbox is the maintained ox-native successor to QBCore.
- Tell which framework a server runs by reading its started resources for the core name.
- Spot the three common beginner traps: mixing scripts across frameworks, assuming one framework's code runs on another, and starting the framework after the scripts that need it.
You now hold the map. You know what a framework is, why every serious server runs one, the three big names, and how to spot which is which. The next lesson, "NUI and React: in-game interfaces," opens up the other half of FiveM: the menus, HUDs, and screens players actually look at, built with the web technologies you may already know.