FiveM es compatible oficialmente con Lua, JavaScript y C#. Elige el entorno de ejecución que se adapte a tu framework, las habilidades de tu equipo y las bibliotecas necesarias, no una supuesta clasificación de rendimiento universal. Los tres pueden llamar a las funciones nativas de FiveM, manejar eventos y exponer API de recursos. Las diferencias prácticas son el límite del tiempo de ejecución, el ecosistema de paquetes, el flujo de trabajo de compilación y el código ya utilizado por tus dependencias.
Revisado el 10 de agosto de 2026 según la documentación oficial de Cfx.re para los tiempos de ejecución compatibles, introducción a los scripts y manifiestos de recursos. El comportamiento del tiempo de ejecución puede cambiar, así que verifica esas páginas antes de iniciar un proyecto de larga duración.
Comparación de lenguajes de FiveM
| Tiempo de ejecución | Buena opción | Límite importante | Flujo de trabajo típico |
|---|---|---|---|
| Lua | Marcos Lua existentes, recursos compactos y ejemplos directos de FiveM | CfxLua es un tiempo de ejecución Lua 5.4 modificado, no una instalación Lua de sistema arbitraria | Edite los archivos fuente y cárguelos a través del manifiesto de recursos |
| JavaScript | Equipos que utilizan herramientas JavaScript/TypeScript y npm | Los scripts de cliente no reciben API de navegador o Node.js; los scripts de servidor usan el tiempo de ejecución de Node de FiveM | Ejecute la fuente directamente o compile/agrupe TypeScript en JavaScript listado en el manifiesto |
| C# | .Equipos .NET, código de dominio tipado y proyectos compilados | El recurso debe enviar los ensamblados y archivos esperados por el tiempo de ejecución Cfx.re | Construya a partir de una plantilla Cfx.re, luego implemente la salida de la construcción |
Lua: la ruta directa del framework
Documentos Cfx.re CfxLua como un tiempo de ejecución modificado de Lua 5.4. Eso importa cuando comparas el código FiveM con tutoriales antiguos de Lua: las características del lenguaje y el comportamiento del tiempo de ejecución deben verificarse con CfxLua, no inferirse del paquete del sistema operativo de un servidor.
Lua suele ser la opción menos disruptiva cuando el framework y los recursos vecinos ya están escritos en Lua. Puedes mantener eventos, exportaciones y configuración compartida en el mismo idioma y evitar agregar un paso de compilación solo por estilo. Un pequeño manifiesto puede listar scripts de cliente, servidor y compartidos separados. Mantén los secretos y las comprobaciones de autoridad solo del servidor fuera de los archivos del cliente, incluso cuando ambos lados usen Lua.
La sintaxis corta facilita el escaneo de los manejadores de eventos, pero no reemplaza el diseño de la interfaz. Documenta cada carga útil de evento, valida los valores en el servidor y evita tratar un evento de cliente como prueba de que el dinero, el inventario o los permisos son válidos.
JavaScript y TypeScript: saber qué lado se está ejecutando
El oficial Guía de tiempo de ejecución de JavaScript describe el soporte de ES2017 y una división crítica cliente/servidor. Los scripts de cliente se ejecutan en el tiempo de ejecución del cliente de FiveM y no tienen APIs de navegador ni APIs de Node.js. Los scripts de servidor usan un tiempo de ejecución de Node.js personalizado. La versión de servidor documentada por defecto es Node.js 16; un recurso puede optar por Node.js 22 con node_version '22' en fxmanifest.lua.
No asumas que un paquete que funciona en un proyecto Node ordinario también funciona en un script de cliente FiveM. Coloca las dependencias de sistema de archivos, base de datos y npm del lado del servidor en el límite del servidor. Para las definiciones de editor y TypeScript, Cfx.re publica los @citizenfx/client y @citizenfx/server paquetes. Mejoran la verificación de tipos, pero no otorgan APIs que el tiempo de ejecución seleccionado carece.
FiveM también documenta las restricciones de afinidad de subprocesos para algunas llamadas nativas del lado del servidor. Cuando el código asíncrono de Node necesite volver al hilo principal del juego, siga la guía de tiempo de ejecución y use setImmediate donde sea necesario. Pruebe el JavaScript compilado que realmente implementa, incluidos los mapas de origen y el orden de inicio, en lugar de solo el código fuente TypeScript.
C#: use la forma de proyecto compatible
El Documentación de tiempo de ejecución de C# proporciona plantillas de proyectos actuales y guía de compilación. Comience allí en lugar de copiar un diseño de ensamblado antiguo de una aplicación .NET no relacionada. Un recurso C# normalmente tiene un proyecto que hace referencia a los ensamblados CitizenFX compatibles, compila su código y coloca los archivos resultantes donde el manifiesto puede cargarlos.
C# puede ser una buena opción cuando el equipo ya utiliza tipos, herramientas y prácticas de prueba de .NET. La contrapartida es operativa: los colaboradores y la CI necesitan el SDK y el comando de compilación correctos, y el artefacto implementado debe permanecer sincronizado con su origen. Registre la plantilla, el marco de destino y el proceso de lanzamiento en el repositorio para que una actualización del servidor sea reproducible.
El modelo compartido: manifiestos, nativos, eventos y exportaciones
La elección del idioma no cambia el contrato del recurso. Cada recurso necesita un fxmanifest.lua que declara metadatos y los archivos a cargar. El código del cliente se ejecuta para los jugadores conectados; el código del servidor se ejecuta bajo FXServer. Los archivos compartidos se entregan a ambas partes, por lo que no deben contener credenciales ni decisiones de confianza solo del servidor.
- Nativos expone funciones del juego y de la plataforma. Consulta la referencia nativa actual y si una función nativa es del lado del cliente o del servidor.
- Eventos mueve mensajes dentro o a través del límite cliente/servidor. Trata la entrada de red como no confiable y valídala en el lado del servidor.
- Exportaciones publica funciones para otros recursos. Mantén documentados los nombres, parámetros, valores de retorno y dependencias de inicio.
- Dependencias pertenecen al manifiesto o al orden de inicio del servidor cuando otro recurso debe estar disponible primero.
Un servidor de lenguaje mixto es normal. El límite estable es el evento o la exportación documentados, no el lenguaje de implementación detrás de ellos. Esto hace posible reemplazar un recurso sin reescribir toda la pila.
Cómo elegir para un proyecto real
- Empieza con el framework. Si el servidor depende de un ESX, QBCore, Qbox o recurso independiente establecido, utiliza sus puntos de extensión y convenciones de lenguaje compatibles.
- Lista las bibliotecas requeridas. Confirme que cada controlador de base de datos, puente UI y paquete sea compatible con el tiempo de ejecución del cliente o servidor donde se ejecutará.
- Coincide con el equipo. Prefiera el idioma que los colaboradores puedan revisar, probar y mantener después de que el autor original se vaya.
- Defina la compilación. Lua puede enviarse directamente; TypeScript y C# suelen necesitar una compilación reproducible y un directorio de salida claro.
- Prototipo del límite. Pruebe una llamada nativa, un evento de red validado por el servidor, una exportación y un reinicio de dependencia antes de construir la función completa.
Lista de verificación de verificación mínima
- Inicie el recurso en un servidor de prueba e inspeccione los registros del servidor y del cliente F8.
- Vuelva a conectar un cliente limpio y reinicie el recurso para exponer archivos faltantes o suposiciones de orden.
- Envía cargas útiles de eventos no válidas y no autorizadas y confirma que el servidor las rechaza.
- Verifica la versión de Node documentada o la salida de compilación de .NET en el host de implementación real.
- Fija las versiones de las dependencias y guarda una copia de reversión del último recurso que funcionó.
No hay ninguna razón basada en la evidencia para coronar a uno de los tres lenguajes de codificación FiveM como universalmente el más rápido o el más popular para cada recurso. Selecciona Lua, JavaScript/TypeScript o C# de los hechos de tiempo de ejecución admitidos, el marco circundante y el costo de mantenimiento que tu equipo realmente puede asumir.
