Linguagens de Programação FiveM: Lua, JavaScript e C# Comparadas

O FiveM oferece suporte oficial a Lua, JavaScript e C#. Escolha o ambiente de execução que melhor se adapta à sua estrutura, habilidades da equipe e bibliotecas necessárias — não uma suposta classificação de desempenho universal. Todos os três podem chamar nativos do FiveM, lidar com eventos e expor APIs de recursos. As diferenças práticas são o limite de ambiente de execução, o ecossistema de pacotes, o fluxo de trabalho de construção e o código já usado por suas dependências.

A configuração e os exemplos de código aqui são voltados ao FiveM para GTA V Legacy. O Enhanced tem regras diferentes de runtime e de compatibilidade; verifique as alterações de Legacy para Enhanced do Cfx.re antes de aplicá-las a um servidor Enhanced.

Comparação de linguagens FiveM

Ambiente de execução	Boa opção	Limite importante	Fluxo de trabalho típico
Lua	Estruturas Lua existentes, recursos compactos e exemplos diretos FiveM	CfxLua é um ambiente de execução Lua 5.4 modificado, não uma instalação arbitrária do sistema Lua	Edite os arquivos de origem e carregue-os através do manifesto de recursos
JavaScript	Equipes usando ferramentas JavaScript/TypeScript e npm	Scripts de cliente não recebem APIs de navegador ou Node.js; scripts de servidor usam o ambiente de execução Node do FiveM	Execute o código-fonte diretamente ou compile/empacote TypeScript em JavaScript listado no manifesto
C#	Equipes .NET, código de domínio tipado e projetos compilados	O recurso deve enviar os assemblies e arquivos esperados pelo ambiente de execução Cfx.re	Crie a partir de um modelo Cfx.re e, em seguida, implante a saída da compilação

Lua: o caminho direto do framework

O Cfx.re documenta CfxLua como um ambiente de execução Lua 5.4 modificado. Isso importa quando você compara o código FiveM com tutoriais Lua mais antigos: os recursos da linguagem e o comportamento do ambiente de execução devem ser verificados em relação ao CfxLua, não inferidos do pacote do sistema operacional de um servidor.

Lua é geralmente a escolha menos disruptiva quando o framework e os recursos vizinhos já estão escritos em Lua. Você pode manter eventos, exportações e configuração compartilhada na mesma linguagem e evitar adicionar uma etapa de compilação apenas por estilo. Um pequeno manifesto pode listar scripts separados para cliente, servidor e compartilhados. Mantenha segredos apenas do servidor e verificações de autoridade fora dos arquivos do cliente, mesmo quando ambos os lados usam Lua.

A sintaxe curta facilita a leitura dos manipuladores de eventos, mas não substitui o design da interface. Documente cada carga útil de evento, valide os valores no servidor e evite tratar um evento do cliente como prova de que dinheiro, inventário ou permissões são válidos.

JavaScript e TypeScript: saiba qual lado está sendo executado

O oficial Guia de ambiente de execução JavaScript descreve o suporte ES2017 e uma divisão crítica cliente/servidor. Scripts de cliente são executados no ambiente de execução de cliente do FiveM e não possuem APIs de navegador ou APIs Node.js. Scripts de servidor usam um ambiente de execução Node.js personalizado. Para o ambiente de execução Legacy, o padrão de servidor documentado é Node.js 16; um recurso pode optar pelo Node.js 22 com node_version '22' em fxmanifest.lua.

Não presuma que um pacote que funciona em um projeto Node comum também funciona em um script de cliente FiveM. Coloque dependências de sistema de arquivos, banco de dados e npm do lado do servidor no limite do servidor. Para definições de editor e TypeScript, Cfx.re publica os @citizenfx/client e @citizenfx/server pacotes. Eles melhoram a verificação de tipo, mas não concedem APIs que o tempo de execução selecionado não possui.

FiveM também documenta restrições de afinidade de thread para algumas chamadas nativas do lado do servidor. Quando o código Node assíncrono precisa retornar ao thread principal do jogo, siga a documentação do ambiente de execução e use setImmediate , onde for necessário. Teste o JavaScript compilado que você realmente implanta, incluindo mapas de origem e ordem de inicialização, em vez de apenas a fonte TypeScript.

C#: use o formato de projeto suportado

O documentação de ambiente de execução C# fornece modelos de projeto atuais e orientações de compilação. Comece por aí em vez de copiar um layout antigo de assemblies de um aplicativo .NET não relacionado. Um recurso C# normalmente tem um projeto que referencia os assemblies CitizenFX suportados, compila seu código e coloca os arquivos resultantes onde o manifesto pode carregá-los.

C# pode ser uma ótima opção quando a equipe já usa tipos, ferramentas e práticas de teste .NET. A desvantagem é operacional: contribuidores e CI precisam do SDK e do comando de construção corretos, e o artefato implantado deve permanecer sincronizado com sua fonte. Registre o modelo, a estrutura de destino e o processo de lançamento no repositório para que uma atualização do servidor seja reproduzível.

O modelo compartilhado: manifestos, nativos, eventos e exportações

A escolha da linguagem não altera o contrato do recurso. Cada recurso precisa de um fxmanifest.lua que declara metadados e os arquivos a serem carregados. O código do cliente é executado para jogadores conectados; o código do servidor é executado sob o FXServer. Arquivos compartilhados são entregues a ambos os lados, portanto, não devem conter credenciais ou decisões de confiança apenas do servidor.

• Nativos expõem funções de jogo e plataforma. Verifique a referência nativa atual e se um nativo é do lado do cliente ou do servidor.
• Eventos movem mensagens dentro ou através do limite cliente/servidor. Trate a entrada de rede como não confiável e valide-a no lado do servidor.
• Exports publicam funções para outros recursos. Mantenha nomes, parâmetros, valores de retorno e dependências de inicialização documentados.
• Dependências pertencem ao manifesto ou à ordem de inicialização do servidor quando outro recurso deve estar disponível primeiro.

Um servidor de linguagem mista é normal. O limite estável é o evento ou exportação documentado, não a linguagem de implementação por trás dele. Isso torna possível substituir um recurso sem reescrever toda a pilha.

Como escolher para um projeto real

1. Comece com o framework. Se o servidor depende de um ESX, QBCore, Qbox ou recurso autônomo estabelecido, use seus pontos de extensão e convenções de linguagem suportados.
2. Listar bibliotecas necessárias. Confirme que cada driver de banco de dados, UI bridge e pacote é compatível com o ambiente de execução do cliente ou servidor onde será executado.
3. Considere as habilidades da equipe. Prefira a linguagem que os colaboradores podem revisar, testar e manter depois que o autor original sair.
4. Defina a compilação. Lua pode ser enviado diretamente; TypeScript e C# geralmente precisam de compilação reproduzível e um diretório de saída claro.
5. Prototipagem do limite. Prove uma chamada nativa, um evento de rede validado pelo servidor, uma exportação e um reinício de dependência antes de construir o recurso completo.

Lista mínima de verificação

• Inicie o recurso em um servidor de teste e inspecione os logs do servidor e do cliente F8.
• Reconecte um cliente limpo e reinicie o recurso para expor arquivos ausentes ou suposições de ordenação.
• Envie cargas inválidas e não autorizadas e confirme que o servidor as rejeita.
• Verifique a versão documentada do Node ou a saída de compilação .NET no host de implantação real.
• Fixe as versões das dependências e mantenha uma cópia de reversão do último recurso funcional.

Não há razão baseada em evidências para coroar uma das três linguagens de programação FiveM como universalmente a mais rápida ou mais popular para cada recurso. Selecione Lua, JavaScript/TypeScript ou C# a partir dos fatos de ambiente de execução suportados, da estrutura circundante e do custo de manutenção que sua equipe pode realmente suportar.

Diferenças do ambiente de execução no Enhanced

Enhanced altera o ambiente de execução JavaScript e C# e alguns comportamentos da plataforma. Use a documentação para a edição exata do cliente/servidor em vez de aplicar suposições do Legacy Node ou Mono a ela. Reconstrua e teste as dependências contra esse ambiente.