Langages de programmation FiveM : Comparaison de Lua, JavaScript et C#

FiveM prend officiellement en charge Lua, JavaScript et C#. Choisissez le runtime qui correspond à votre framework, aux compétences de votre équipe et aux bibliothèques requises, et non à un classement de performances universel supposé. Les trois peuvent appeler les natives FiveM, gérer les événements et exposer les API de ressources. Les différences pratiques sont la limite du runtime, l'écosystème de packages, le flux de travail de construction et le code déjà utilisé par vos dépendances.

Les exemples de configuration et de code ici ciblent FiveM pour GTA V Legacy. Enhanced a des règles d'exécution et de compatibilité différentes ; vérifiez les changements Legacy-to-Enhanced de Cfx.re avant de les appliquer à un serveur Enhanced.

Comparaison des langages FiveM

Runtime	Bonne adéquation	Limite importante	Flux de travail typique
Lua	Frameworks Lua existants, ressources compactes et exemples FiveM directs	CfxLua est un runtime Lua 5.4 modifié, pas une installation Lua système arbitraire	Modifiez les fichiers source et chargez-les via le manifeste de ressource
JavaScript	Équipes utilisant les outils JavaScript/TypeScript et npm	Les scripts client ne reçoivent pas les API de navigateur ou Node.js ; les scripts serveur utilisent le runtime Node de FiveM	Exécutez la source directement ou compilez/regroupez TypeScript en JavaScript listé dans le manifeste
C#	Équipes .NET, code de domaine typé et projets compilés	La ressource doit livrer les assemblages et les fichiers attendus par le runtime Cfx.re	Construire à partir d'un modèle Cfx.re, puis déployer la sortie de la construction

Lua : le chemin direct du framework

Cfx.re présente CfxLua en tant que runtime Lua 5.4 modifié. Cela est important lorsque vous comparez le code FiveM avec d'anciens tutoriels Lua : les fonctionnalités du langage et le comportement du runtime doivent être vérifiés par rapport à CfxLua, et non déduits du package du système d'exploitation d'un serveur.

Lua est généralement le choix le moins perturbateur lorsque le framework et les ressources voisines sont déjà écrits en Lua. Vous pouvez conserver les événements, les exportations et la configuration partagée dans le même langage et éviter d'ajouter une étape de construction uniquement pour le style. Un petit manifeste peut lister des scripts client, serveur et partagés distincts. Gardez les secrets et les vérifications d'autorité côté serveur hors des fichiers clients, même lorsque les deux côtés utilisent Lua.

La syntaxe courte facilite la lecture des gestionnaires d'événements, mais elle ne remplace pas la conception d'interface. Documentez chaque charge utile d'événement, validez les valeurs sur le serveur et évitez de traiter un événement client comme une preuve que l'argent, l'inventaire ou les autorisations sont valides.

JavaScript et TypeScript : sachez quel côté est en cours d'exécution

Le dépôt officiel guide d'exécution JavaScript décrit la prise en charge d'ES2017 et une séparation client/serveur critique. Les scripts client s'exécutent dans le runtime client de FiveM et n'ont pas d'API de navigateur ou d'API Node.js. Les scripts serveur utilisent un runtime Node.js personnalisé. Pour le runtime Legacy, la valeur par défaut documentée du serveur est Node.js 16 ; une ressource peut opter pour Node.js 22 avec node_version '22' dans fxmanifest.lua.

Ne supposez pas qu'un package fonctionnant dans un projet Node ordinaire fonctionne également dans un script client FiveM. Placez les dépendances de système de fichiers, de base de données et de npm côté serveur à la limite du serveur. Pour les définitions d'éditeur et de TypeScript, Cfx.re publie les @citizenfx/client et @citizenfx/server packages. Ils améliorent la vérification de type mais n'accordent pas les APIs que l'environnement d'exécution sélectionné ne possède pas.

FiveM documente également les contraintes d'affinité de thread pour certains appels natifs côté serveur. Lorsque le code Node asynchrone doit revenir au thread de jeu principal, suivez les directives d'exécution et utilisez setImmediate si nécessaire. Testez le JavaScript compilé que vous déployez réellement, y compris les cartes sources et l'ordre de démarrage, plutôt que seulement la source TypeScript.

C# : utilisez la forme de projet prise en charge

Le documentation du runtime C# fournit des modèles de projet actuels et des conseils de construction. Commencez par là au lieu de copier une ancienne disposition d'assemblage d'une application .NET sans rapport. Une ressource C# a normalement un projet qui référence les assemblages CitizenFX pris en charge, compile son code et place les fichiers résultants là où le manifeste peut les charger.

C# peut être un excellent choix lorsque l'équipe utilise déjà les types, les outils et les pratiques de test .NET. Le compromis est opérationnel : les contributeurs et l'intégration continue ont besoin du SDK et de la commande de construction corrects, et l'artefact déployé doit rester synchronisé avec sa source. Enregistrez le modèle, le framework cible et le processus de publication dans le référentiel afin qu'une mise à jour du serveur soit reproductible.

Le modèle commun : manifestes, fonctions natives, événements et exports

Le choix du langage ne modifie pas le contrat de ressource. Chaque ressource a besoin d'un fxmanifest.lua qui déclare les métadonnées et les fichiers à charger. Le code client s'exécute pour les joueurs connectés ; le code serveur s'exécute sous FXServer. Les fichiers partagés sont livrés aux deux côtés, ils ne doivent donc pas contenir d'informations d'identification ou de décisions de confiance uniquement côté serveur.

• Les fonctions natives exposent les fonctions du jeu et de la plateforme. Consultez la référence actuelle des fonctions natives et vérifiez si la fonction concernée s’exécute côté client ou côté serveur.
• Les événements transmettent des messages au sein d’un contexte ou entre le client et le serveur. Considérez les données reçues du réseau comme non fiables et validez-les côté serveur.
• Les exports publient des fonctions pour les autres ressources. Documentez les noms, les paramètres, les valeurs de retour et les dépendances nécessaires au démarrage.
• Dépendances appartiennent au manifeste ou à l'ordre de démarrage du serveur lorsqu'une autre ressource doit être disponible en premier.

Un serveur utilisant plusieurs langages est normal. La limite stable est l'événement ou l’export documenté, et non le langage d'implémentation qui le sous-tend. Cela permet de remplacer une ressource sans réécrire toute la pile.

Comment choisir pour un projet réel

1. Commencez par le framework. Si le serveur dépend d'une ressource ESX, QBCore, Qbox établie ou autonome, utilisez ses points d'extension et ses conventions linguistiques pris en charge.
2. Listez les bibliothèques requises. Confirmez que chaque pilote de base de données, pont UI et package est compatible avec le client ou le runtime serveur où il sera exécuté.
3. Tenez compte de l’équipe. Privilégiez le langage que les contributeurs pourront relire, tester et maintenir après le départ de l’auteur initial.
4. Définissez le processus de compilation. Lua peut être livré directement ; TypeScript et C# nécessitent généralement une compilation reproductible et un répertoire de sortie clair.
5. Créez un prototype des interfaces entre les composants. Vérifiez le fonctionnement d’un appel natif, d’un événement réseau validé par le serveur, d’un export et d’un redémarrage de dépendance avant de développer la fonctionnalité complète.

Liste minimale de vérifications

• Démarrez la ressource sur un serveur de staging et inspectez les journaux du serveur et du client F8.
• Reconnectez un client propre et redémarrez la ressource pour exposer les fichiers manquants ou les hypothèses d'ordonnancement.
• Envoyez des charges utiles d'événements invalides et non autorisées et confirmez que le serveur les rejette.
• Vérifiez la version de Node documentée ou la sortie de build .NET sur l'hôte de déploiement réel.
• Épinglez les versions des dépendances et conservez une copie de restauration de la dernière ressource fonctionnelle.

Rien ne permet d’affirmer, preuves à l’appui, qu’un des trois langages de programmation FiveM est toujours le plus rapide ou le plus populaire pour toutes les ressources. Choisissez Lua, JavaScript/TypeScript ou C# selon les capacités documentées du runtime pris en charge, le framework utilisé et le coût de maintenance que votre équipe peut assumer.

Différences du runtime Enhanced

Enhanced modifie l'environnement d'exécution JavaScript et C# ainsi que certains comportements de la plateforme. Utilisez la documentation pour l'édition client/serveur exacte plutôt que d'appliquer les hypothèses Legacy Node ou Mono. Reconstruisez et testez les dépendances par rapport à cet environnement.