mJS da Cesanta: scripting JavaScript enxuto para firmware em C/C++
O mJS é uma engine JavaScript embarcada criada pela Cesanta com foco claro em microcontroladores e integração com projetos escritos em C ou C++. Sua proposta não é oferecer uma implementação completa de JavaScript, nem reproduzir o ambiente do navegador ou do Node.js. A própria documentação oficial do projeto define o mJS como uma engine projetada para microcontroladores com recursos limitados, tendo como objetivos principais o pequeno footprint e a interoperabilidade simples com C/C++. Ela também deixa claro que o mJS implementa um subconjunto estrito de ES6: todo código válido em mJS é válido em ES6, mas nem todo código ES6 é válido em mJS. (GitHub)
Essa decisão de implementar apenas parte da linguagem é fundamental para entender o mJS. Em vez de tentar carregar toda a complexidade do JavaScript moderno para dentro do microcontrolador, o mJS reduz a linguagem ao necessário para servir como camada de scripting. Isso o torna mais adequado para firmwares que já têm uma base sólida em C/C++ e precisam apenas de uma forma mais flexível de configurar comportamentos, executar regras simples, personalizar respostas ou expor pequenas automações ao usuário final.
Na prática, o mJS se encaixa muito bem em uma arquitetura onde o firmware principal continua sendo nativo. Drivers, tarefas de tempo real, controle de periféricos, protocolos críticos e rotinas sensíveis a desempenho permanecem em C ou C++. O JavaScript entra como uma camada superior, mais próxima da lógica de aplicação. Por exemplo, um equipamento IoT pode ter sua pilha de rede, MQTT, HTTP, GPIO, armazenamento e segurança implementados em C, enquanto scripts mJS definem como reagir a eventos, como publicar mensagens, como tratar estados ou como personalizar regras de funcionamento.
Uma vantagem importante do mJS é justamente sua integração com C/C++. O desenvolvedor pode expor funções nativas para o ambiente JavaScript, permitindo que o script chame recursos do firmware sem acessar diretamente toda a estrutura interna do sistema. Essa abordagem é muito útil em produtos embarcados, porque cria uma fronteira controlada entre o que é seguro expor ao script e o que deve permanecer protegido na camada nativa. Isso permite criar dispositivos configuráveis sem abrir mão do controle arquitetural.
Outro ponto relevante é a relação histórica do mJS com o ecossistema Mongoose OS, também da Cesanta. A página da Cesanta no GitHub apresenta o Mongoose OS como um framework de firmware IoT com suporte a microcontroladores como ESP32, ESP8266, CC3220, CC3200, STM32F4, STM32L4 e STM32F7, além de indicar desenvolvimento em C ou JavaScript. (GitHub) Esse contexto mostra que o mJS nasceu dentro de uma visão prática de IoT embarcado, não como um experimento isolado de linguagem.
A economia de recursos também é um argumento forte. Em uma publicação técnica da própria Mongoose OS, o mJS é apresentado como uma engine restrita que não implementa toda a linguagem, não inclui biblioteca padrão completa e evita camadas pesadas de glue code. O texto afirma que essa abordagem permite caber em menos de 50 kB de Flash e usar menos de 1 kB de RAM em determinadas condições. (mongoose-os.com) Mesmo que valores exatos dependam da configuração, compilador, plataforma e recursos habilitados, o ponto central permanece: o mJS foi projetado para ser pequeno.
A desvantagem mais óbvia é que o mJS não é JavaScript completo. Um desenvolvedor vindo do mundo web pode tentar usar recursos modernos, bibliotecas NPM, módulos complexos ou padrões comuns de Node.js e rapidamente descobrir que esse não é o ambiente correto para isso. O mJS deve ser tratado como uma linguagem de scripting inspirada em JavaScript moderno, mas limitada pelas decisões necessárias para caber em microcontroladores. Essa limitação não é um defeito acidental; é uma escolha de engenharia.
Outra limitação é que a responsabilidade arquitetural aumenta. Como o script pode chamar funções nativas, o firmware precisa controlar cuidadosamente o que é exposto. Uma API mal projetada pode permitir usos indevidos, consumo excessivo de memória ou comportamentos difíceis de depurar. Em sistemas embarcados, o problema raramente está apenas na linguagem; está na fronteira entre a linguagem dinâmica e os recursos físicos do hardware. Por isso, funções expostas ao mJS devem ser simples, previsíveis, bem documentadas e testadas.
Também é importante observar a maturidade e manutenção do projeto conforme o uso pretendido. O repositório do mJS possui issues abertas relacionadas a falhas de memória e casos de crash reportados por usuários ou ferramentas de análise. Isso não significa automaticamente que a engine seja inadequada, mas indica que, em produtos profissionais, é prudente avaliar versão, histórico de manutenção, testes, superfície exposta ao script e criticidade da aplicação antes de adotá-la. (GitHub)
Em resumo, o mJS é uma boa opção quando queremos adicionar scripting JavaScript a um firmware C/C++ sem carregar uma engine pesada. Ele é especialmente interessante para configuração dinâmica, lógica de alto nível, automação simples e produtos IoT onde a base nativa continua responsável pelo trabalho crítico. Sua principal força está no footprint pequeno e na integração direta com C/C++. Sua principal fraqueza está no suporte limitado à linguagem e na necessidade de projetar muito bem a fronteira entre o script e o firmware.