É a hora certa de adotar uma API de templates para o DOM

• A plataforma web se consolidou como um runtime de aplicações dinâmicas, mas o DOM padrão não tem uma API de templates declarativa que lide em conjunto com dados, eventos, propriedades, proteção contra XSS e atualização eficiente
• Frameworks modernos como React, Vue, Angular, Lit, Svelte e SolidJS têm como núcleo um sistema de templates que combina marcação e dados, e isso afeta legibilidade, segurança, desempenho, análise estática e renderização no lado do servidor
• No passado, E4X, E4H e a tag literal de template embutida html ajudavam a criar DOM, mas não resolviam a atualização do DOM; agora, tagged template literals e a experiência acumulada com frameworks oferecem uma base para padronização
• Uma API baseada em JavaScript tem escopo menor do que a padronização de JSX ou de templates baseados em HTML, e pode servir como alvo de compilação para transformações de JSX, abrindo caminho depois para templates HTML e elementos customizados declarativos
• O caminho proposto se conecta a mecanismos de nível inferior como DOM Parts, template identity, Signals e um scheduler de DOM, podendo oferecer uma base comum para desenvolvedores vanilla, usuários de web components e implementadores de frameworks

---

Uma camada de templates declarativos ausente no DOM padrão

• A plataforma web é o runtime de aplicações mais bem-sucedido da história, e a API do DOM é a base que transformou um visualizador de documentos estáticos em um runtime dinâmico e expressivo
• Até apps complexos como Photoshop são oferecidos como web apps, e o DOM é uma API poderosa a ponto de toda a UI poder ser construída com Web Components
• Ainda assim, a API padrão atual do DOM não oferece uma forma conveniente de lidar de uma vez com as seguintes tarefas
  • criar fragmentos de nós DOM a partir de dados
  • adicionar event listeners
  • definir propriedades de elementos
  • garantir segurança contra ataques XSS
  • atualizar com eficiência esse fragmento de DOM com novos dados

O valor dos templates já foi provado pelos frameworks

• Frameworks web modernos e bibliotecas de renderização usam como recurso central templates que combinam declarativamente marcação e dados
  • Isso inclui React, Vue, Angular, Preact, Lit, Svelte, SolidJS, Stencil, Quik, Ember, FAST, Polymer, Marko e outros
• Templates declarativos são mais fáceis de escrever e ler do que APIs imperativas de DOM
  • Interpolação, event listeners e definição de propriedades ficam próximos do template, o que facilita manter a localidade do comportamento
• Sistemas de templates podem escapar automaticamente valores interpolados, o que ajuda na proteção contra XSS
• Um bom sistema de templates pode atualizar apenas o DOM que precisa mudar e ser mais rápido do que a maior parte do código escrito manualmente
• Muitos sistemas de templates oferecem análise estática, como verificação de tipos e autocompletar
• Como definições de templates declarativos podem ser interpretadas fora do ambiente completo do navegador, é possível fazer renderização eficiente no lado do servidor

O custo da ausência de templates

• A plataforma ainda não atende diretamente a um requisito central de quase todas as aplicações web
  • Assim como APIs de internacionalização, Temporal, Scheduler e Sanitizer, templates também merecem ser tratados como um recurso padrão da plataforma
• Usuários sofrem com tempo de download do app, overhead de renderização e aplicativos com segurança fraca
  • O código de bibliotecas de templates pode ter, no melhor caso, alguns kB e, no pior, mais de 100kB
  • Mesmo alguns kB podem representar uma parte grande do orçamento inicial de renderização interativa
• Desenvolvedores precisam depender de bibliotecas, npm e CDNs até para tarefas básicas
  • Arquivos estáticos simples e a utilidade do DevTools ficam reduzidos
  • Não existe um conhecimento básico de templates que seja portável entre stacks
  • APIs nativas de criação de DOM como innerHTML não são seguras por padrão
• Frameworks e bibliotecas de templates precisam fazer trade-offs difíceis entre produtividade, velocidade de renderização, velocidade de atualização, segurança e tamanho do código
• A plataforma web compete com plataformas nativas como Flutter, SwiftUI e Jetpack Compose
  • Essas plataformas já trazem sistemas parecidos com templates embutidos, usam instalação de apps e linguagens compiladas, e são menos sensíveis a bundles de poucos kB

Por que agora dá para tentar de novo

• Já existiram no passado propostas de plataforma próximas de templates
  • E4X chegou a ser incluído de fato no Firefox e no Flash
  • E4H era uma ideia simplificada de Ian Hixie
  • Por volta de 2012, também houve um protótipo de tag literal de template embutida html
• As tentativas anteriores ajudavam na criação de DOM, mas não resolviam a atualização, então dificilmente poderiam ser uma solução suficiente
• Hoje, os frameworks já criaram casos de uso suficientes, e as soluções de templates em userland estão ficando cada vez mais parecidas entre si
• Também há demanda por manipulação conveniente de DOM e APIs reativas entre desenvolvedores que não usam frameworks e na comunidade de web components
• Estão em andamento propostas de primitivas de baixo nível para atualização de DOM, como DOM Parts
  • Uma API de templates declarativa de nível mais alto pode reduzir o peso de implementação nos frameworks e validar ou complementar propostas de APIs de baixo nível

O denominador comum de sintaxe e semântica

• A maior parte dos sistemas populares de templates no client side compartilha uma estrutura que combina marcação e bindings
  • Delimitadores de expressões, fluxo de controle e marcadores de tipo de binding variam um pouco, mas as semelhanças são maiores
  • Há semelhanças mesmo entre Vue, Angular e Svelte baseados em HTML e React, Lit e Solid baseados em JavaScript
• Em APIs baseadas em JavaScript, templates geralmente são expressões; a composição acontece por aninhamento ou referência de expressões de template; e o fluxo de controle fica a cargo do JavaScript
• Muitos sistemas baseados em API JavaScript retornam uma descrição de DOM a partir da expressão de template e depois a aplicam com uma chamada separada à função render
  • A maioria também atualiza o DOM com a mesma chamada render
  • Alguns evitam isso com reatividade granular
• E4X e E4H, como JSX, adicionavam uma nova sintaxe ao JavaScript para colocar marcação no código, mas retornavam o próprio fragmento de DOM, não uma descrição de DOM
  • Eram bons para a criação inicial do DOM, mas a atualização continuava imperativa

Uma API possível com o JavaScript de hoje

• O JavaScript já tem tagged template literals, que funcionam como uma DSL embutida semelhante a HTML
• Isso permite expressar templates em uma API de DOM sem adicionar nova sintaxe ao JavaScript
• Bibliotecas populares mostram que essa abordagem funciona bem
• O fato de ser possível avançar sem nova sintaxe é importante para a viabilidade de padronização

A relação entre JSX e uma API de templates nativa

• Tagged template literals são um recurso poderoso do ES2015, mas em sistemas de componentes em userland têm mais overhead sintático do que JSX
• JSX é popular, mas tem apenas sintaxe e não possui semântica de runtime
  • Para padronizar, seria preciso ir além de adicionar sintaxe nova e definir semântica
  • Fica descartada a abordagem de tratá-lo como chamadas a createElement() definidas ao redor
  • A abordagem de criar árvores de objetos pode misturar partes estáticas e dinâmicas e impedir padrões de atualização mais eficientes
• Se a proposta de Records and Tuples tivesse avançado, JSX talvez pudesse criar Records com box, mas essa proposta está travada especialmente em identity de record e no aspecto de box
• Para verificar se uma sintaxe e semântica no estilo JSX são adequadas para um sistema completo de templates para DOM, é preciso existir um sistema de templates-alvo
  • O template do React não tem uma forma explícita de fazer binding a propriedades e eventos de elementos nem de aplicar diretivas ao elemento
• Como o JSX não padronizado de hoje é sintaxe pura sem semântica de runtime, é possível criar compiladores que transformem JSX em tagged template literals
  • Já existem exemplos como JSX-to-Lit
  • Uma API de templates nativa pode virar um alvo de compilação para que desenvolvedores escolham a sintaxe que preferirem

Por que olhar primeiro para uma API JavaScript em vez de templates baseados em HTML

• Muitos desenvolvedores web querem um sistema completo de templates baseado em HTML
  • Há demanda entre usuários de web components, usuários de frameworks e a comunidade de desenvolvedores vanilla
  • Alguns esperavam que <template>, declarative shadow DOM e Web Components trouxessem esse tipo de funcionalidade
• Templates baseados em HTML são um trabalho muito maior do que uma API baseada em JavaScript
  • sintaxe de bindings
  • linguagem de expressões
  • sintaxe de fluxo de controle
  • mecanismo de atualização de templates
• Também não existe uma forma nativa de carregar definições de templates em HTML
  • HTML Imports do Web Components v0 desapareceram, e HTML Modules ainda não existem
  • Se for preciso colocar templates HTML dentro de módulos JavaScript, faz mais sentido usar expressões JavaScript no mesmo escopo léxico dos dados
• O Polymer 3 levou os templates HTML do Polymer 2 para JavaScript, o que resultou diretamente no Lit
  • Deixar o JavaScript cuidar desse tipo de tarefa reduziu código e melhorou a experiência
• Uma API JavaScript pode ser um subconjunto e uma base para uma API baseada em HTML
  • Depois que a API JavaScript entrar e for validada, a API HTML passa a ser principalmente uma questão de definir bindings, expressões, fluxo de controle e sistema de módulos

Opções de modelo reativo

• Propostas iniciais de templates para DOM não incluíam atualização, mas os sistemas em userland já exploraram bastante os modelos reativos e abordagens de implementação
• Dá para agrupar as abordagens reativas principais em três linhas
  • VDOM e diffing do React
  • template identity do Lit
  • Signals e reatividade granular usados em Solid, Svelte, Vue, Angular e outros
• Diffing é fácil de entender e funciona com qualquer dado, mas é mais lento do que outras abordagens
  • Diferenças entre algoritmos de diffing podem ser observáveis
  • É difícil padronizar um único algoritmo de diffing e convencer engenheiros da plataforma a aceitar o overhead
• Template identity funciona atualizando quando o DOM atual foi renderizado pelo template e substituindo quando não foi
  • É rápido e, em muitos casos de uso, produz resultados muito parecidos com diffing
  • Combina bem com tagged template literals, transformações de JSX e templates baseados em HTML
  • Sua semântica é simples, o que facilita especificação
• Signals são um modelo que poderia entrar em novas APIs reativas de DOM e de templates
  • Existe a proposta JavaScript Signals, mas ela ainda não é um recurso nativo da plataforma e sua adoção não é garantida
  • Sistemas baseados em Signals funcionam melhor quando todos os dados são envolvidos em signals
  • Como há muitos dados que não são signal e APIs da plataforma que não criam signals, rerenderizar é uma forma simples de refletir essas mudanças
• Template identity e Signals podem coexistir
  • Templates que recebem apenas signals em seus bindings podem ser atualizados só com signals, sem rerenderização
  • Templates que podem referenciar dados que não são signal precisam de rerenderização
  • Em geral, a rerenderização é feita automaticamente por uma camada de componente ou framework, como propriedades de componentes reativos

Discussão de padronização e desafios restantes

• A discussão sobre uma API nativa de templates declarativos em JavaScript começou em WICG webcomponents#1069
• Essa API pode ser o próximo passo lógico das APIs de criação de DOM
  • pode ser uma primitiva de criação de DOM segura e com boa ergonomia para desenvolvedores web vanilla
  • pode ser imediatamente útil para bibliotecas existentes de web components como Lit, FAST e HyperElement
  • pode ser útil para usuários da API bruta de Web Components e servir de base para uma API mais completa de definição de componentes reativos
  • novos frameworks podem ser construídos sobre essa API
  • frameworks existentes podem usá-la como alvo de compilação, backend de runtime ou suporte direto
  • é útil tanto para técnicas de rerenderização quanto para Signals
  • abre caminho para templates HTML declarativos e elementos customizados declarativos
  • a superfície de API para chegar a consenso e especificar é relativamente pequena
  • ajuda a definir a semântica dos templates
• Esse trabalho está ligado à conclusão da proposta DOM Parts
  • também contribui para definir DOM Parts e provar sua utilidade
• Embora a API de superfície e a sintaxe não sejam grandes, o espaço de comportamento e a API subjacente de DOM Parts são amplos
• A reatividade granular também exige algum tipo de scheduler de DOM
• Há muitos pontos a decidir, alinhar, especificar e testar, então será preciso colaboração
• Desenvolvedores interessados podem comentar em webcomponents#1069 ou entrar em contato pelo Bluesky

[GN⁺]

Opiniões do Hacker News

• A afirmação de que “sabemos qual é uma boa sintaxe para templates” chega a ser risível. Acho que ainda não sabemos nada disso. Um bom template quase certamente está mais para uma ferramenta visual do que para uma sintaxe simbólica, e é por isso que ferramentas antigas como o Dreamweaver fizeram sucesso e por que designers aprendem com ferramentas como o Photoshop. Também é uma pena, porque parece uma tentativa de recriar o XSLT. Alguém inevitavelmente vai querer criar templates de fragmentos que não são well-formed e que, ao serem combinados, resultam em algo well-formed. O mesmo vale para entidades que estão conectadas dentro da página, mas não pertencem à mesma árvore. Um exemplo simples é o label e o for em markup comum. Se possível, eu gostaria que houvesse menos tentativas de forçar todos os templates a caber nesse mecanismo de Rube Goldberg que é o layout documental padrão do markup. As pessoas seguem caminhos absurdamente complexos para reproduzir coisas que funcionam muito bem quando posicionamento absoluto é usado com cuidado. Para encaixar tudo, pode até ser necessário fazer cálculos, mas não entendo por que devemos obrigar a máquina a repetir esses cálculos continuamente para os mesmos dados.

  • Nunca gostei de XML, mas acho que XSLT era, e ainda é, o recurso matador capaz de salvar aquele ecossistema. Ele ainda é amplamente suportado nos navegadores. É uma pena que XML tenha virado moda em lugares inadequados, como configuração e comunicação entre processos, mas tenha perdido força onde poderia brilhar: como uma linguagem de marcação com uma excelente capacidade de transformação por meio do XSLT. Acho que o ponto em que o XSLT desmoronou foi o fato de ele ser uma DSL de verdade — e, ainda por cima, uma DSL declarativa, pura e funcional. As pessoas exaltam DSLs no discurso, mas, na prática, muitas vezes elas acabam sendo apenas brincadeiras sintáticas que não conseguem abstrair a semântica procedural de uma linguagem hospedeira popular. Quando encontram uma DSL bem projetada que torna tarefas difíceis em algo trivial, as pessoas não querem aprendê-la.
  • Não sei como você chegou a essa conclusão. O que você está dizendo parece mais uma reclamação sobre HTML+CSS em geral do que sobre formas de geração de templates. E também não entendo por que posicionamento absoluto entrou na conversa. Vejo esse tipo de comentário repetidamente no HN e, claro, posicionamento absoluto tem seus usos e muitas vezes é necessário. Mas, quando usado para layout de páginas ou apps, pela minha experiência, na maioria das vezes era um pesadelo que quebrava com qualquer pequena mudança no conteúdo ou no tamanho da tela. Nem mesmo o layout de jornais impressos consegue funcionar assim, porque a tipografia está envolvida. Na época em que eu mexia bastante com CSS, quando eu assumia um trabalho em que alguém tinha deixado um layout “quase pronto” usando posicionamento absoluto, levava um tempo enorme para consertar, e sempre era mais rápido refazer com flex ou fluxo normal. Isso porque usar posicionamento absoluto como principal ferramenta de layout tornava o problema praticamente impossível de corrigir. Pode haver técnicas que façam sentido usando calc() e unidades de viewport, mas, pela minha experiência, se o conteúdo e o tamanho da viewport não forem completamente estáticos, posicionamento absoluto não é adequado para layout.
  • Na Web, existe a exigência de que documentos tenham boa aparência em qualquer tamanho, proporção, orientação e conjunto de recursos de dispositivo. Apps comuns, por exemplo apps do Windows, não têm essa exigência, e apps móveis têm alguns tamanhos padronizados. Só a Web tem os dois.
  • Acho que entre React e Svelte há apenas uma semelhança superficial. Ambos usam uma sintaxe fortemente baseada em HTML, mas funcionam de maneiras muito diferentes. React é, em grande parte, o único grande framework que funciona com funções JavaScript comuns retornando uma representação adiada de markup em forma de JSX. O React não tem conceitos de repetição ou renderização condicional no nível do template; isso é tratado com JavaScript comum.
  • Rir de alguém que defende avanços na plataforma Web não é uma atitude muito boa. Esse avanço beneficia todo mundo. E acho que agora sabemos qual é uma boa sintaxe para templates. Basicamente, é JSX. Posso dizer isso mesmo sem gostar muito de React. JSX tomou conta da Web, foi adaptado para vários frameworks, e é difícil negar que os sistemas de template em JavaScript convergiram para características comuns: tratar templates como expressões, compô-los por aninhamento e lidar com fluxo de controle usando o próprio JavaScript em vez de uma sintaxe específica de template.

• Uma lição básica aprendida repetidamente é que API/ABI não são um estado final. As necessidades de uma aplicação não são atendidas para sempre por uma única API estável, e também não dá para empurrar todos os problemas futuros para o nível da aplicação.
  Esta proposta mostra bem o processo em que um problema comum da plataforma começa sendo resolvido em camadas superiores, como React, e, quando finalmente é reconhecido como problema, desce para a camada de baixo. Polyfills são outro exemplo disso.
  Quando uma proposta dessas dá certo, ela recebe atenção por um tempo, mas durante a maior parte de sua vida útil se torna algo antigo que as pessoas tentam contornar. Foi assim com a API do DOM, versões do ECMA, navegadores antigos e toda tecnologia útil que, por fazer parte do sistema, não pode ser mexida.
  Não seria possível pensar em entropia, expansão e compatibilidade retroativa como casos de uso principais?

  • Todo recurso de um padrão web é código adicional que precisa ser mantido com cuidado, e também código adicional que qualquer pessoa que queira criar um navegador compatível com os padrões precisa implementar. Eu gostaria que projetos como https://servo.org/ tivessem a chance de alcançar o restante com o tempo, não que ficassem apenas correndo atrás de um escopo cada vez maior.
    Quero que a plataforma web tenha todas as capacidades possíveis de uma plataforma nativa. Claro, respeitando as restrições de privacidade e sandboxing. E também quero que a experiência de desenvolvimento dos desenvolvedores web seja excelente.
    Mas isso precisa ser equilibrado com as consequências do aumento de complexidade. Neste caso, não tenho certeza de que templates nativos realmente melhorem a experiência de desenvolvimento. Não me parece que o benefício supere o custo.
  • getElementById não está estável há uns 25 anos? A frase “não existe API estável” é dita por pessoas que não têm capacidade ou vontade de criar interfaces duradouras. Não é uma lei do universo; parece mais uma resignação pessoal. Há inúmeros contraexemplos.
    As necessidades das aplicações são infinitas, como qualquer outra necessidade. Elas são atendidas não quebrando APIs que funcionam, mas adicionando novas APIs.
  • Na web, API/ABI são, sim, um estado final. Uma vez expostas na web, alguém vai depender daquele formato exato para sempre.
    É por isso que algumas APIs ainda se envolvem em casos como o smooshgate por causa de decisões de 20 anos atrás: https://developer.chrome.com/blog/smooshgate
  • Nesse processo, a funcionalidade básica sobe mais um degrau. O fato de as necessidades no espaço do usuário sempre encontrarem novas lacunas, casos de uso e pontos cegos não torna atualizações incrementais sem valor.
  • Não é por isso que se versiona e se mantém compatibilidade retroativa com versões antigas, sem alterar interfaces “antigas”?

• A web realmente precisa de templates nativos, reatividade e data binding. Nem consigo imaginar quanto CPU e largura de banda são desperdiçados por bilhões de usuários baixando, parseando e executando coisas como React.

  • Agora que temos LLMs e criptomoedas, esse desperdício parece muito pequeno.
  • Parte disso está avançando com a proposta Signals da TC39.
  • Um data binding bidirecional e algo como uma cópia de JSX, na verdade, já seriam suficientes para a maioria.
  • React não é meio difícil de chamar de template?

• A parte sobre Signals diz muita coisa e mostra bem que a ideia é excelente, mas difícil na prática.
  Dá para entender por que o autor gosta de Signals. Todo projeto suficientemente grande tem uma árvore de cálculo DAG meio improvisada, e faz sentido a linguagem padronizar uma.
  Mas esse tipo de abstração tem custo cognitivo e custo de implementação altos.
  Como em grande parte da engenharia, o problema é uma troca. O modelo do React atualiza o estado global e renderiza tudo de novo, então é lento, mas é fácil para a cabeça. O modelo de Signals é rápido, mas exige esforço demais.
  A maioria dos apps não precisa ser absurdamente rápida, e as pessoas vão escolher o React, que é mais simples.
  Só que Signals não têm pouca relação com templates? Então por que escolher isso? Não dá para ter templates e Signals separadamente?
  Quando se pensa em templates, passa a ser necessário um jeito de dizer ao DOM onde inserir nós de template e como atualizá-los quando algo mudar. É justamente nesse ponto que propostas assim fracassam.
  A API aqui precisa escolher um lado. Tecnicamente talvez pudesse permitir os dois, mas seria horrível. Desenvolvedores nunca vão chegar a um consenso sobre qual lado deveria ser.
  O grande problema de UI sempre foi não como defini-la, mas como atualizá-la. A Microsoft tentou definir muitos modelos, como MVC, MVP e MVVM, e falhou; todos eram dolorosos. Então o imgui disse: “e se a UI não tivesse estado algum?”, e isso é bem bom, mas pesa na CPU.
  Talvez um dos maiores motivos do sucesso dos apps web seja que o DOM não impôs uma forma de amarrar dados à view. Por isso talvez seja difícil escaparmos do inferno dos frameworks.

  • Hoje já existem vários frameworks que fazem bem diffing granular, sem depender de Signals, proxies ou outros primitivos reativos. Basicamente seguem o modelo do React de cima para baixo, mas são muito mais rápidos, sem conceitos estranhos como hooks ou arrays de dependências manuais e desperdiçadores.
    Meu favorito pessoal é o ivi-js: https://github.com/localvoid/ivi
    Ele é apenas 8% mais lento do que o JavaScript vanilla mais rápido, mais feio, imperativo e impossível de manter ao qual se poderia chegar pensando apenas em vencer benchmarks.
    https://krausest.github.io/js-framework-benchmark/2025/table...
  • A Microsoft usou esses modelos em vários momentos, mas o único que ela definiu diretamente foi MVVM. MVC veio da Xerox PARC, MVP veio da Taligent.
  • Mesmo como desenvolvedor, eu escolheria de bom grado o caminho que é mais fácil para o hardware, a largura de banda e o planeta, ainda que pese um pouco mais na cabeça do desenvolvedor.
    Em vez de dizer que a maioria dos apps não precisa ser absurdamente rápida, eu gostaria que se reconhecesse mais que apps precisam ser leves.
    Concordo que as pessoas escolhem React porque ele é mais simples, mas é exatamente por esse motivo que eu não gosto de React.

• Em vez de adotar JSX, eu gostaria que fosse algo mais próximo da forma como Kotlin oferece uma sintaxe generalizada para DSLs com receivers e builders, e essa sintaxe também se encaixa bem na representação de hierarquias de componentes
  Isso seria amplamente útil não só para templates HTML, mas também para expressar configurações e vários tipos de estruturas
  A semântica real de templates e data binding poderia ficar em um conjunto padrão de funções que usam esse recurso de sintaxe, como se vê no Jetpack Compose

  • Nem é preciso muita coisa. Basta repetição, condicionais para atributos e condicionais para nós. Na verdade, esse nível também seria possível como funcionalidade comum entre linguagens

• Também é importante notar que este texto foi escrito por uma das pessoas mais experientes nessa área. É um dos principais autores de Lit / Polymer e alguém que trabalhou em Web Components no Google, contribuindo para especificações fundamentais do DOM que se tornaram parte da plataforma web

  • Pelo contrário, vejo essa pessoa como uma das que criou muito mais problemas do que resolveu ao avançar de forma temerária com especificações meio cruas. Ela impulsionou uma “solução” que exigia mais de 20 novas especificações web para mal conseguir imitar o que o espaço de usuário já fazia, e ignorou ou fez gaslighting com quem não concordava 100%
    O Safari defendia desde 15 anos atrás que deveria haver uma abordagem declarativa para isso

• Fico curioso se há mais alguém que sente que templates declarativos são, na verdade, piores que jQuery. Uso React há quase 10 anos, mas quanto mais complexa uma SPA fica, mais tenho vontade de controlar diretamente o DOM de forma imperativa
  O motivo é que o DOM é uma abstração com vazamentos e, em certo nível, parece melhor adotar a regra de que a última escrita vence
  Sei que templates declarativos tentam lidar com isso, mas quando você começa a compartilhar estado mutável entre componentes, essa abordagem desmorona muito rápido

  • O pessoal do React tende a tratar chamadas diretas à API do DOM como um grande pecado. Às vezes tudo bem pegar um ref e, ouso dizer, localizar um componente por id e lidar com ele diretamente. Na prática, bibliotecas “rápidas” e com menos rerenderizações, como bibliotecas de formulário, fazem isso
  • Não gosto de React, mas não concordo com essa percepção. Primeiro, já é possível sair do DOM declarativo e fazer o que quiser com innerHTML e ref
    Segundo, não sei que coisas seriam menos trabalhosas de fazer controlando o DOM imperativamente do que de forma declarativa. Só me vêm à mente alguns métodos específicos como attachShadow() e showModal(), mas até isso pode ser tornado declarativo se for envolvido em um componente de 10 linhas
  • Concordo totalmente. Ainda não vi um único exemplo que me convença de que algo como React seja nem um pouco melhor do que usar HTML separado e jQuery

• Pelo que sei, Ryan Carniato e o Solid JS ainda estão explorando o que é possível fazer com Signals. Não acho que a exploração do espaço de usuário nessa área tenha terminado completamente, e pode haver espaço para mais inovação

  • Fora da bolha do desenvolvimento web, também há muita pesquisa interessante na área de computação incremental, e computação autoadaptativa, ou seja, até Signals, nem é um eixo tão interessante assim

• Gosto da direção, mas antes disso acho que algumas APIs de nível mais baixo deveriam chegar primeiro aos navegadores
  Será quase impossível todo mundo concordar com um sistema de templates padrão. Em vez disso, o que o navegador pode fazer é oferecer uma API de nível mais baixo que aplique diffs ao DOM de forma nativa e performática
  Seria muito bom ter algo assim nativo no navegador
  element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })
  Essa abordagem poderia aplicar diferenças de forma menos intrusiva, preservando foco de elementos, valores de entrada, estado de players de áudio e vídeo, alterando atributos etc. Bibliotecas JavaScript como Idiomorph fazem esse tipo de coisa, mas uma solução nativa provavelmente seria muito mais rápida

  • O texto inclui um link para a proposta de DOM part, que poderia ser uma API útil de baixo nível. Ela talvez não se encaixe bem em frameworks baseados em VDOM, mas em outros frameworks poderia simplificar o funcionamento e aumentar as oportunidades de otimização
    Também seria útil para projetos sem framework e, se a proposta de Signals também for adotada, seria especialmente útil

• A proposta Records and Tuples não está apenas parada; ela foi retirada. https://github.com/tc39/proposal-record-tuple/issues/394
  O lugar dela foi ocupado por https://github.com/tc39/proposal-composites