Inspirado pela frustração com a qualidade do software moderno e pelo sentimento 'They don't make 'em like Sublime Text anymore', o autor empreendeu a construção de um editor de texto personalizado. A jornada explora três abordagens de renderização: <canvas>, contenteditable e <textarea>.

O experimento inicial com <canvas> alcançou uma renderização de 60–120 FPS, mas carecia de interatividade nativa. A implementação de recursos básicos como posicionamento do cursor, digitação e realce de linhas revelou elementos essenciais ausentes: seleção de texto, desfazer/refazer e rolagem de overflow. Uma solução híbrida usando um <div> oculto para cálculos nativos de rolagem melhorou a rolagem, mas <canvas> permaneceu fundamentalmente inacessível.

A mudança para contenteditable="plaintext-only" proporcionou seleção nativa, histórico de desfazer e acessibilidade gratuitamente. A API de Seleção permitiu o renderização personalizada do cursor, embora o desempenho tenha se degradado de forma imprevisível com arquivos maiores, especialmente no Chromium.

Por fim, a abordagem <textarea> provou ser muito mais performante para textos longos. O realce de sintaxe foi adicionado por meio de uma terceira camada usando Micro Lighter, embora a nova API de Intervalos Opacos possa permitir realces nativos. O autor observa que Tree-sitter e rolagem virtualizada poderiam melhorar a robustez, mas reconhece que a demonstração atual representa "90% de um editor de texto com 1% dos recursos".

Entidades-chave: Empresas: Apple, Chromium, Web Kit, Firefox

Perguntas Frequentes: Por que o <textarea> é mais performante que o contenteditable para arquivos de texto grandes?

<textarea> é um controle de formulário nativo otimizado pelos navegadores para entrada de texto simples, evitando a sobrecarga complexa de layout e renderização do contenteditable, que deve lidar com formatação de texto rico, verificação ortográfica e estruturas HTML arbitrárias mesmo no modo plaintext-only.