Os recursos de linguagem que serão incluídos na próxima atualização anual do JavaScript serão decididos no início do ano novo, incluindo projetos que atingirão o marco final do estágio quatro até março de 2025 (e há alguns recursos que já chegaram tão longe).
Há outros que estão a caminho de ficarem prontos a tempo de entrar na lista — incluindo pelo menos um projeto muito solicitado que tem sido aguardado ansiosamente e parece estar finalmente na reta final. Dois novos recursos chegaram ao estágio quatro logo após a data limite do ECMAScript 2024: grupos de captura nomeados duplicados para lidar com expressões regulares e métodos para lidar com conjuntos.
Preparando o cenário para a eficiência do JavaScript
Poder usar os mesmos nomes em diferentes ramificações de uma regexp é um recurso pequeno, mas útil, que simplificará a escrita de expressões, onde você precisa corresponder a algo que pode ser expresso de diferentes maneiras, mas que corresponderá apenas uma vez (como o ano sendo 2025 ou apenas 25 em uma data). Atualmente, você obtém um erro se chamar ambos os padrões de "ano", então você tem que inventar nomes diferentes. Agora você pode usar o mesmo nome, desde que esteja em diferentes ramificações da expressão, separados por um |.
"É uma forte demonstração de apoio quando todos os navegadores produzem muito rapidamente essas [implementações] e é isso que aspiramos tanto quanto possível ao levar qualquer uma dessas propostas adiante." – Rob Palmer, copresidente do TC39
Novos métodos para trabalhar com a classe Set do JavaScript estão em discussão há anos: esse é um recurso em que a linguagem ficou para trás de muitas outras linguagens (como Python, Ruby, Swift, Rust e C#), deixando os desenvolvedores escreverem seus próprios métodos de conjunto ou usar um polyfill como o Core.js. O copresidente do TC39, Rob Palmer, descreveu isso como "outro caso clássico em que as pessoas têm escrito suas próprias funções utilitárias de três a quatro linhas para processar conjuntos e oferecer operações básicas de conjunto desde o ES 2015, que foi há nove anos".
"O motivo pelo qual essa proposta demorou tanto foi porque ela atingiu novos limites na linguagem", explicou Ashley Claymore , engenheiro de software da Bloomberg que trabalhou em várias propostas do TC39.
Definindo o que é um conjunto
Antes desses novos métodos de conjunto, o JavaScript não tinha um tipo complexo que pudesse ser combinado com outra instância do mesmo tipo e retornar uma instância, então não havia um exemplo de como a nova funcionalidade deveria funcionar.
"Passamos muito tempo falando sobre o que é um conjunto", disse Claymore. "Se eu tiver um conjunto que intersecciona com outro conjunto, o que esse outro conjunto poderia ser? Esse outro conjunto é um iterável? Deve ser uma instância oficial real do conjunto que foi criada com new Set? O que acontece se você passar um mapa para um método de conjunto?"
"…na verdade, responder o que é um conjunto foi algo que passamos muito tempo discutindo, e agora temos uma resposta para isso." – Ashley Claymore, engenheiro de software da Bloomberg
Era importante responder a essas perguntas técnicas de uma forma que não tivesse consequências indesejadas.
"Todos concordaram que isso é útil", ele continuou. "Set deve fazer essas coisas, esses são métodos que provavelmente deveríamos ter. Mas, na verdade, responder o que é um conjunto foi o que passamos muito tempo discutindo, e agora temos uma resposta para isso."
Toda essa discussão garantiu que o que parece ser uma funcionalidade básica fosse implementado de uma forma que se encaixasse adequadamente na linguagem.
Um conjunto é como um array, mas cada valor é único, então você só pode adicionar novos valores que ainda não estejam no conjunto. Isso significa que você pode estar interessado em trabalhar com todos os valores que estão em um conjunto e não em outro (diferença), em qualquer um dos dois conjuntos, desde que não estejam em ambos (symmetricDifference), ou apenas os valores que estão em dois conjuntos (interseção), ou em várias outras combinações. Os sete novos métodos cobrem o intervalo padrão do que os desenvolvedores precisam fazer com conjuntos: union, intersection, difference, symmetricDifference, isSubsetOf, isSupersetOf, isDisjointFrom.
"Eu uso muito conjuntos, mas você não costuma usá-los sem querer um ou mais desses, e você pensaria que eles estariam na biblioteca padrão imediatamente, mas eles simplesmente não estavam." – Brian Kardell, defensor do desenvolvedor Igalia
"Eu uso muito conjuntos, mas você não costuma usá-los sem querer um ou mais desses, e você pensaria que eles estariam na biblioteca padrão imediatamente, mas eles simplesmente não estavam", disse o defensor do desenvolvedor Igalia Brian Kardell ao The New Stack . " Como desenvolvedor (e defensor do desenvolvedor ), fico realmente animado com isso porque sei que os usarei para sempre — assim como meus poucos métodos Array favoritos."
Embora os desenvolvedores tenham conseguido fazer isso em JavaScript escrevendo suas próprias funções, tê-las na linguagem economiza tempo e ajuda na consistência.
"Os métodos Sets e Array são valiosos porque são muito usados", continuou Kardell, "e você não precisa reescrevê-los ou se preocupar se seu grande programa acabará com cinco implementações da mesma coisa".
Como atingir o estágio quatro significa que há pelo menos duas implementações principais, os desenvolvedores podem considerar usar ambos os recursos imediatamente. O novo recurso Set agora é suportado em todos os principais navegadores: ele foi lançado no Firefox e no TypeScript 5.5 em junho de 2024, tornando-o amplamente disponível o suficiente para se tornar parte do Baseline 2024 , que Kardell descreve como "quando lançamos as últimas implementações de algo".
Palmer vê a velocidade com que os métodos Set passaram para a linha de base como um bom exemplo do pipeline do padrão para a ampla disponibilidade que o processo de padronização do ECMAScript visa entregar: "É uma forte demonstração de apoio quando todos os navegadores produzem muito rapidamente essas [implementações] e é isso que aspiramos tanto quanto possível ao levar qualquer uma dessas propostas adiante. Você não quer que as pessoas deixem de usá-las porque elas não estão disponíveis em um navegador, embora, obviamente, sempre haja a solução de usar um compilador como Babel ou TypeScript."
Grupos de captura duplicados não são tão avançados: são suportados em todos os principais navegadores de desktop e na maioria dos navegadores móveis (ainda estão em versão prévia no navegador móvel da Samsung), mas ainda não no Node.js ou Deno.
O próximo estágio: decoradores, módulos JSON e promessas
Os outros recursos que provavelmente estarão prontos a tempo para o ECMAScript 2025 são propostas que já atingiram o estágio três: decoradores, módulos JSON, Promise.try e (finalmente) Temporal.
Decoradores
Decoradores adicionam funcionalidade extra ao código existente ao envolvê-lo em outro pedaço de código (como adicionar cortinas ou uma nova camada de tinta a um cômodo para torná-lo mais útil). Isso pode ser tão simples quanto mudar a aparência do código para torná-lo mais legível sem mudar o código subjacente, ou pode fornecer maneiras mais flexíveis de estruturar o código ao torná-lo mais modular.
Com decoradores, em vez de colocar a lógica para manipular seu armazenamento de dados e seus modelos juntos na classe que você está escrevendo, o que a tornaria menos flexível e mais difícil de reutilizar para outros projetos, você pode colocar as dependências fora da classe. Decoradores permitem que os desenvolvedores criem abstrações para tarefas comuns como registro, verificação de tipo dinâmico e outras verificações de segurança (como validação de parâmetros) e as adicionem às classes quando forem necessárias.
"Vimos que o caminho de transição do uso existente de decoradores era importante e queremos permitir a adoção incremental e tratar bem o ecossistema existente: não estamos projetando isso no vácuo." – Daniel Ehrenberg, vice-presidente da Ecma
Este é um padrão amplamente utilizado em frameworks como React e Angular, e tem suporte em TypeScript e Babel há muitos anos — embora não exatamente da mesma forma que a proposta do ECMAScript se desenvolveu após muitos anos de discussão (o que permite que decoradores trabalhem com campos e métodos privados).
Embora o conceito mais amplo de decoradores tenha sido amplamente validado pelo uso extensivo em transpiladores, levou algum tempo para concordar com a abordagem correta na linguagem JavaScript em si. "Passamos por muitas iterações da proposta do decorador e finalmente chegamos a uma que concordamos que atendia tanto aos casos de uso quanto aos caminhos de transição que eram necessários de decoradores anteriores e às preocupações de implementabilidade dos navegadores", explicou o vice-presidente da Ecma, Daniel Ehrenberg . "Finalmente conseguimos triangular tudo isso. Isso significa que há algumas diferenças, mas, ao mesmo tempo, realmente tentamos garantir que a transição fosse suave."
Parte disso é permitir que o código use a sintaxe existente dos decoradores experimentais do TypeScript ou a nova sintaxe da proposta. Você tem que escolher um ou outro para funções individuais, mas ele explicou: "Em uma declaração de classe exportada específica, os decoradores podem vir antes ou depois da palavra-chave exportada." É uma coisa pequena, mas evita que os desenvolvedores precisem reescrever o código existente.
"Vimos que o caminho de transição do uso existente de decoradores era importante e queremos permitir a adoção incremental e tratar bem o ecossistema existente: não estamos projetando isso no vácuo", observou Ehrenberg.
Como parte do processo de inclusão de decoradores no JavaScript, algumas das ideias mais ambiciosas sobre a aplicação de decoradores a objetos, variáveis e parâmetros foram retiradas da proposta — mas elas permanecem como uma possível extensão usando a mesma sintaxe.
Módulos JSON
Em outra simplificação, os módulos JSON eram originalmente parte da proposta Import Attributes, parte do grande esforço do Module Harmony para preencher as lacunas na funcionalidade do módulo ECMAScript em JavaScript. Ele foi movido para uma proposta separada para evitar atrasar o conceito mais geral de ser capaz de incluir instruções para lidar com o que você está importando com as especificidades de lidar com arquivos JSON.
As implementações dos módulos Import Attributes e JSON estão em andamento e provavelmente passarão para o estágio quatro ao mesmo tempo, ainda este ano.
Ser capaz de marcar um arquivo JSON ou CSS como texto a ser lido em vez de código a ser executado é bom para a segurança, porque significa que o arquivo não fará algo que um desenvolvedor não espera. Embora isso pareça simples, levou algum tempo para a comunidade HTML e de navegadores, juntamente com o comitê ECMAScript, trabalhar na sintaxe correta para integrar isso aos navegadores. O Chrome já havia enviado o recurso com a versão inicial da sintaxe (contribuída pela Microsoft), mas agora foi removido, e as implementações dos módulos Import Attributes e JSON estão em andamento e provavelmente passarão para o estágio quatro ao mesmo tempo no final deste ano. Isso não significa que dividir as propostas foi inútil; permitiu que ambas se movessem em sua própria velocidade, mesmo que pareça que chegarão juntas.
Promessas.tentar
Outro recurso que está em desenvolvimento há algum tempo preenche uma pequena lacuna no uso de promessas.
O Promises.try atingiu o estágio três em junho e já há implementações em diversos navegadores.
Promessas em JavaScript lidam com o eventual sucesso ou falha de uma operação assíncrona de forma estruturada: o método catch no final de uma cadeia de promessas deve capturar todos e quaisquer erros e o método then diz ao seu código o que fazer sobre o erro. Mas se você estiver chamando uma função ou usando uma API que recebe um retorno de chamada que pode ou não ser assíncrono, Promise.try envolve o resultado do retorno de chamada em uma promessa, então se ele lançar um erro, ele será capturado e transformado em uma promessa rejeitada. Dessa forma, você pode ter certeza de que pode lidar com erros síncronos e assíncronos em uma única cadeia de promessas. Este é outro recurso popular que é polyfilled em Core.js (bem como bibliotecas de promessas de terceiros que são anteriores à implementação do JavaScript, como Bluebird ).
Promises.try atingiu o estágio três em junho e já há implementações em uma variedade de navegadores (está no Edge e no Chrome, foi adicionado ao WebKit, está atrás de uma bandeira nas compilações atuais do desenvolvedor do Firefox e provavelmente será incluído no lançamento do Firefox em novembro de 2024 ou janeiro de 2025), bem como em tempos de execução como Bun e Cloudflare workers. Isso é o suficiente para atingir o estágio quatro assim que o comitê ECMAScript concordar, o que deve ser confortavelmente a tempo para o ECMAScript 2025.
Já é hora do Temporal
Parece cada vez mais provável que o Temporal (que o então editor do TC39, Brian Terlson, descreveu memoravelmente para nós como "o substituto para nosso objeto Date quebrado" em 2021, quando atingiu o estágio três pela primeira vez) também estará pronto para o ECMAScript 2025, porque houve muito progresso recentemente em lidar com os problemas que o atrasaram.
Quando o JavaScript foi criado em 1995, ele copiou o objeto de data do Java : uma implementação bastante simplista que o Java substituiu em 1997, mas que tem dificuldades no JavaScript (ou, mais frequentemente, é rotineiramente substituída por bibliotecas como Moment.js). Substituir isso pelo Temporal sempre foi esperado que desse muito trabalho, por causa da complexidade de datas, horas, fusos horários e calendários, mas também que fosse relativamente incontroverso.
O Temporal está claramente em demanda: como parte das discussões sobre o que seria incluído no Interop 2023 , Ehrenberg nos disse, "eles fizeram pesquisas sobre quais APIs os desenvolvedores gostariam e o Temporal obteve muitos votos". Então por que uma proposta popular ficou à beira de entrar na linguagem JavaScript por cinco anos?
"…o número de páginas de especificações dedicadas ao Temporal é aproximadamente do mesmo tamanho que a totalidade do ES6." – Palmer
Uma das coisas que a proposta estava esperando era o trabalho da Internet Engineering Task Force (IETF) para padronizar os formatos de string ISO usados para anotações de calendário e fuso horário. Um pouco atrasado pela pandemia, esse trabalho foi concluído como um novo RFC em abril de 2024, mas mesmo antes de ser concluído, ficou claro que não era
