- Um engenheiro do Google apresentou ao comitê oficial de padronização uma proposta para dividir o JavaScript em duas linguagens
- A proposta é separar um núcleo implementado nos motores de execução e uma variante com mais recursos que depende de ferramentas que o compilam
- A apresentação foi feita no início deste mês na reunião do Ecma TC39
- O TC39 é o comitê da Ecma International que evolui a especificação do JavaScript (oficialmente, ECMAScript)
- A apresentação foi conduzida por Shu-yu Guo, do Google, e os slides foram escritos em coautoria com participantes da Mozilla, Apple, Moddable e Sony
- Shu-yu é especialista em JIT, VM, compiladores e padronização
- Argumentos dos autores
- Novos recursos da linguagem quase sempre pioram a segurança e têm impacto neutro ou negativo no desempenho
- A estabilidade às vezes também piora, e a funcionalidade dos apps só melhora quando os desenvolvedores realmente usam os novos recursos
- A VM (máquina virtual) do JavaScript já se tornou extremamente complexa por causa da pressão por velocidade, o que compromete a segurança. Isso parece ainda pior especialmente quando novos recursos não são adotados
- Como falhas de segurança e o "custo de complexidade" do runtime afetam bilhões de usos, enquanto os benefícios ficam limitados aos desenvolvedores e aplicações que de fato aproveitam essa complexidade, a tecnologia de base do JavaScript deveria ser simples
- Embora várias organizações estejam envolvidas, esta iniciativa parece ser em certa medida liderada pelo Google
- Um dos slides inclui a ressalva: "Esta possível solução é a solução preferida do Google e não necessariamente a solução dos outros implementadores"
- Solução proposta
- A ideia não é reverter recursos existentes, mas mudar a abordagem daqui para frente para que a maioria dos novos recursos seja implementada em ferramentas, e não no motor
- A linguagem implementada no motor seria chamada de "JS0", e a linguagem implementada nas ferramentas de "JSSugar"
- É uma ideia especialmente adequada ao JavaScript porque muitos desenvolvedores, na prática, programam em TypeScript e dependem de compiladores como Babel, Webpack e o compilador do TypeScript
- Se adotada, os futuros recursos de sintaxe iriam para o JSSugar, enquanto apenas APIs e recursos funcionais iriam para o JS0
- Motores compatíveis precisariam oferecer suporte apenas ao JS0
- O ônus seria transferido para os implementadores de ferramentas, que teriam de dar suporte ao JSSugar
- Como efeito colateral, implementadores de ferramentas teriam de se envolver mais no processo de padronização e talvez formar um novo grupo técnico
- A proposta já é controversa
- Há desenvolvedores pedindo que ferramentas de JavaScript não recebam status oficial, e muitos desenvolvedores de JavaScript querem depender menos dessas ferramentas
- Existe amplo consenso sobre priorizar segurança, desempenho e estabilidade, mas a ideia de tornar o JavaScript dependente de ferramentas intermediárias não é popular
- Um desenvolvedor chegou a dizer: "RIP Vanilla JS"
Opinião do GN⁺
- Esta proposta pode trazer uma grande mudança para o ecossistema de desenvolvimento JavaScript. Há preocupações pelo fato de que os desenvolvedores precisariam depender mais de compiladores para usar novos recursos de sintaxe
- No entanto, o objetivo em si de reduzir a complexidade dos motores de runtime e melhorar segurança e desempenho é positivo. No longo prazo, isso pode ajudar na evolução do JavaScript
- Outra linguagem que adota uma abordagem semelhante é Dart. O Dart oferece uma sintaxe amigável para desenvolvedores, mas é compilado para JavaScript e executado no navegador
- Ao adotar essa proposta, será preciso considerar cuidadosamente diversos fatores, como compatibilidade com código existente, experiência do desenvolvedor e suporte de ferramentas. Também será necessário um processo que ouça suficientemente a comunidade
- Como o JavaScript é a linguagem que serve de base para o desenvolvimento web, espera-se que as discussões e a evolução continuem ativas daqui para frente
4 comentários
Parece que eles querem adicionar mais uma camada e incluir nela conteúdos que ajudem na DX.
Só o JSX, por si só, já mostra que o ecossistema foi construído para exigir transpilation, então acho que é uma opinião sem muita conexão com a realidade. Parece que a pessoa acha que NodeJS é tudo.
Não sei se entendi exatamente, mas existe o BOOST em C++, e a sensação é parecida com isso. Se a proposta do Google for aprovada e as bibliotecas existentes forem integradas ao JSSugar, o que entraria? Babel?
Comentários do Hacker News
A Hotspot VM do Java trouxe grande sucesso para outras linguagens. Também faz sentido que o JavaScript mire em uma linguagem central e faça pré-compilação do açúcar sintático
É melhor focar em WebAssembly. JavaScript deve ser usado para scripting, e outras linguagens devem ser usadas para aplicações maiores
Como alguém que prefere VanillaJS, há insatisfação com recursos da linguagem que mudam à força. O foco deveria estar em melhorar as APIs para que apps web fiquem no mesmo nível de apps nativos
Discordo da alegação de que não há casos de uso para BigInt. Mesmo que os desenvolvedores frontend do Google não o usem, outros desenvolvedores JS usam. É preciso focar na evolução da linguagem
JavaScript e Wasm deveriam ter sido separados. Em vez disso, o Wasm foi transformado em um cidadão de segunda classe sem acesso às APIs da web
A solução proposta não resolve o problema fundamental e acaba criando dependência de ferramentas. O JavaScript deveria migrar para uma nova linguagem para reduzir desempenho ruim e complexidade
Os problemas surgem da separação entre o TC39 e a comunidade de desenvolvedores. As ferramentas de TypeScript não foram padronizadas e não há plano de portar para Rust
Mudanças no JavaScript são propostas por causa de problemas de manutenção no motor V8 do Google. Questões de segurança e o custo da complexidade afetam os usuários. Deveriam tentar outra linguagem em vez de C++