FiveM ondersteunt officieel Lua, JavaScript en C#. Kies de runtime die past bij je framework, teamvaardigheden en benodigde bibliotheken – niet een vermeende universele prestatieranglijst. Alle drie kunnen FiveM natives aanroepen, events afhandelen en resource APIs blootstellen. De praktische verschillen zitten in de runtime-grens, het package-ecosysteem, de build-workflow en de code die al door je afhankelijkheden wordt gebruikt.
Beoordeeld op 10 augustus 2026 tegen de officiële Cfx.re documentatie voor de ondersteunde runtimes, scripting introductie En resource manifests. Runtime-gedrag kan veranderen, dus verifieer die pagina's voordat je een langlopend project start.
FiveM taalvergelijking
| Runtime | Goede keuze | Belangrijke grens | Typische workflow |
|---|---|---|---|
| Lua | Bestaande Lua-frameworks, compacte resources en directe FiveM-voorbeelden | CfxLua is een aangepaste Lua 5.4 runtime, geen willekeurige systeem Lua-installatie | Bronbestanden bewerken en laden via het resource-manifest |
| JavaScript | Teams die JavaScript/TypeScript en npm-tooling gebruiken | Clientscripts ontvangen geen browser- of Node.js APIs; serverscripts gebruiken FiveM's Node-runtime | Broncode direct uitvoeren of TypeScript compileren/bundelen naar in het manifest opgenomen JavaScript |
| C# | .NET-teams, getypeerde domeincode en gecompileerde projecten | De resource moet de assemblies en bestanden leveren die door de Cfx.re-runtime worden verwacht | Bouwen vanuit een Cfx.re-template, vervolgens de build-output implementeren |
Lua: het directe frameworkpad
Cfx.re documenten CfxLua als een aangepaste Lua 5.4 runtime. Dat is belangrijk wanneer je FiveM code vergelijkt met oudere Lua tutorials: taalfuncties en runtimegedrag moeten worden gecontroleerd tegen CfxLua, niet worden afgeleid van het besturingssysteem-pakket van een server.
Lua is meestal de minst storende keuze wanneer het framework en aangrenzende resources al in Lua zijn geschreven. Je kunt events, exports en gedeelde configuratie in dezelfde taal houden en een build-stap vermijden, alleen voor de stijl. Een klein manifest kan aparte client-, server- en gedeelde scripts vermelden. Houd server-only geheimen en autoriteitscontroles buiten clientbestanden, zelfs wanneer beide kanten Lua gebruiken.
De korte syntaxis maakt event handlers gemakkelijk te scannen, maar het vervangt geen interface-ontwerp. Documenteer elke event payload, valideer waarden op de server en vermijd het behandelen van een client-event als bewijs dat geld, inventaris of permissies geldig zijn.
JavaScript en TypeScript: weet welke kant draait
De officiële JavaScript runtime gids beschrijft ES2017-ondersteuning en een kritieke client/server-splitsing. Client-scripts draaien in de client-runtime van FiveM en hebben geen browser APIs of Node.js APIs. Server-scripts gebruiken een aangepaste Node.js runtime. De standaard gedocumenteerde serverversie is Node.js 16; een resource kan kiezen voor Node.js 22 met node_version '22' in fxmanifest.lua.
Ga er niet van uit dat een pakket dat werkt in een gewoon Node-project ook werkt in een FiveM client-script. Plaats filesystem-, database- en server-side npm-afhankelijkheden aan de servergrens. Voor editor en TypeScript-definities publiceert Cfx.re de @citizenfx/client En @citizenfx/server pakketten. Ze verbeteren typecontrole, maar verlenen geen APIs die de geselecteerde runtime mist.
FiveM documenteert ook thread-affinity beperkingen voor sommige server-side native aanroepen. Wanneer asynchrone Node-code moet terugkeren naar de hoofdgame-thread, volg dan de runtime-richtlijnen en gebruik setImmediate waar nodig. Test de ingebouwde JavaScript die je daadwerkelijk implementeert, inclusief source maps en opstartvolgorde, in plaats van alleen de TypeScript broncode.
C#: gebruik de ondersteunde projectvorm
De C# runtime documentatie biedt huidige projecttemplates en build-richtlijnen. Begin daar in plaats van een oude assembly-layout te kopiëren uit een niet-gerelateerde .NET-applicatie. Een C#-resource heeft normaal gesproken een project dat verwijst naar de ondersteunde CitizenFX-assemblies, compileert de code en plaatst de resulterende bestanden waar het manifest ze kan laden.
C# kan een sterke keuze zijn wanneer het team al .NET-typen, -tools en -testpraktijken gebruikt. De afweging is operationeel: bijdragers en CI hebben de juiste SDK en build-commando nodig, en het geïmplementeerde artefact moet gesynchroniseerd blijven met de broncode. Documenteer de template, het doel-framework en het releaseproces in de repository, zodat een serverupdate reproduceerbaar is.
Het gedeelde model: manifesten, natives, events en exports
Taalkeuze verandert het resourcecontract niet. Elke resource heeft een fxmanifest.lua nodig die metadata en de te laden bestanden declareert. Clientcode wordt uitgevoerd voor verbonden spelers; servercode wordt uitgevoerd onder FXServer. Gedeelde bestanden worden aan beide kanten geleverd, dus ze mogen geen inloggegevens of server-specifieke vertrouwensbeslissingen bevatten.
- Natives game- en platformfuncties blootstellen. Controleer de huidige native referentie en of een native client- of server-side is.
- Evenementen berichten verplaatsen binnen of over de client/server-grens. Behandel netwerkinvoer als onbetrouwbaar en valideer deze server-side.
- Exports functies publiceren voor andere resources. Houd namen, parameters, retourwaarden en opstartafhankelijkheden gedocumenteerd.
- Afhankelijkheden horen in de manifest- of server-opstartvolgorde wanneer een andere resource eerst beschikbaar moet zijn.
Een mixed-language server is normaal. De stabiele grens is het gedocumenteerde event of de export, niet de implementatietaal erachter. Dat maakt het mogelijk om één resource te vervangen zonder de hele stack te herschrijven.
Hoe te kiezen voor een echt project
- Begin met het framework. Als de server afhankelijk is van een gevestigde ESX, QBCore, Qbox of standalone resource, gebruik dan de ondersteunde extensiepunten en taalconventies.
- Vereiste bibliotheken weergeven. Controleer of elke database driver, UI bridge en package compatibel is met de client- of serverruntime waar deze zal draaien.
- Match het team. Geef de voorkeur aan de taal die bijdragers kunnen beoordelen, testen en onderhouden nadat de oorspronkelijke auteur vertrekt.
- Definieer de build. Lua kan direct worden verzonden; TypeScript en C# vereisen meestal reproduceerbare compilatie en een duidelijke uitvoermap.
- Prototypeer de grens. Bewijs één native call, één server-gevalideerd netwerkevenement, één export en één dependency herstart voordat de volledige functie wordt gebouwd.
Minimale verificatielijst
- Start de resource op een staging server en inspecteer zowel de server- als F8 client logs.
- Maak opnieuw verbinding met een schone client en herstart de resource om ontbrekende bestanden of volgorde-aannames bloot te leggen.
- Verzend ongeldige en niet-geautoriseerde event payloads en bevestig dat de server deze afwijst.
- Verifieer de gedocumenteerde Node-versie of .NET build-output op de daadwerkelijke deployment-host.
- Pin dependency-versies en bewaar een rollback-kopie van de laatst werkende resource.
Er is geen op bewijs gebaseerde reden om een van de drie FiveM programmeertalen te kronen als universeel de snelste of meest populaire voor elke resource. Selecteer Lua, JavaScript/TypeScript of C# op basis van de ondersteunde runtime-feiten, het omliggende framework en de onderhoudskosten die je team daadwerkelijk kan dragen.