Executando verificação de segurança...
11

Engenheiro do Google propõe dividir JavaScript em duas linguagens

A ideia é criar um núcleo para ser implementado diretamente pelos motores de execução e uma variante mais avançada, que dependeria de ferramentas para ser compilada nesse núcleo.

A proposta foi apresentada durante uma reunião do TC39, o comitê da Ecma International responsável por evoluir a especificação do padrão ECMAScript. Shu-yu Guo, engenheiro de software do Google especializado em JITs, VMs, compiladores e padronização, liderou a apresentação, que foi coautoria de representantes de empresas como Mozilla, Apple, Sony e Moddable, que oferece um SDK de código aberto para programação embarcada, incluindo o motor JavaScript XS.

Os autores da proposta argumentam que os novos recursos da linguagem têm impactado negativamente os usuários. Eles afirmam que essas funcionalidades “quase sempre” pioram a segurança, afetam o desempenho de forma “neutra ou negativa” e podem comprometer a estabilidade, enquanto só melhoram as funcionalidades dos aplicativos se os desenvolvedores adotarem as novidades. Como exemplo, citam o recurso “species”, cuja remoção já está sendo investigada, e o BigInt, para números grandes, que, segundo a apresentação, nunca teve um caso de uso significativo.

A proposta defende que a base do JavaScript deve permanecer simples, uma vez que falhas de segurança e a crescente complexidade da execução afetam bilhões de usuários, enquanto os benefícios se restringem a desenvolvedores que aproveitam essa complexidade. Apesar do envolvimento de várias organizações, o Google parece ser o principal impulsionador da iniciativa. A solução sugerida não propõe reverter funcionalidades existentes, mas mudar a abordagem para futuros recursos, de modo que a maioria das novidades seja implementada por ferramentas e não diretamente pelos motores JavaScript.

O núcleo da linguagem seria chamado “JS0”, enquanto a variante compilada pelas ferramentas seria “JSSugar”. Esses nomes são provisórios e utilizados apenas para facilitar a discussão. Do ponto de vista do desenvolvedor, o JavaScript seria o JSSugar, mas os motores de execução precisariam suportar apenas o JS0, o que implicaria em maior conformidade entre as ferramentas. Caso a proposta seja aceita, futuras funcionalidades de sintaxe seriam atribuídas ao JSSugar, enquanto os motores de execução ficariam limitados ao JS0. No entanto, isso exigiria que implementadores de ferramentas se envolvessem mais no processo de padronização e possivelmente formassem um novo grupo técnico.

A proposta gerou controvérsias. Embora haja um consenso de que priorizar segurança, desempenho e estabilidade seja importante, a ideia de tornar o JavaScript dependente de ferramentas intermediárias não foi bem recebida por todos.

Carregando publicação patrocinada...
3

Creio que o grau de complexidade dos runtimes e interpretadores do JavaScript deve estar já quase insuportável para as equipes de manutenção dessa plataforma. Por isso, acho que está surgindo essa pressão por divisão da linguagem. Porém tenho certeza que a pressão do ecossistema e da base de usuários vai prevalecer no médio prazo. Até lá, o WebAssembly deve amadurecer e conquistar uma parte do mercado. Na minha humilde opinião, tudo se encaminha para essa substituição tecnológica, que já está ocorrendo ao poucos.

0
2

Pra mim é simples. Deveriam estar discutindo sobre o acesso ao DOM e GC (ao menos um layer para facilitar o uso) do WebAssembly e deixar o js como está. Teve uma discusão sobre acessar o DOM e parece que o chrome até abriu como uma possível feature mas parece que não foi pra frente a ideia.

2

De verdade eu penso que por mais que a linguagem tenha se desenvolvido nos últimos anos, ainda acho que ela devia manter-se na origem ( simplecidade ) , várias funcionalidades acabam sendo desnecessárias ( a medida que aumentam muita complexidade ) e não melhoram em nada

1
1

Typescript não é linguagem, aliás após a compilação vira javascript puro bagunçado, typescript é somente para o dev que nao gosta de linguagem dinâmica

1
-2
-3