13 pontos por GN⁺ 2025-08-18 | 2 comentários | Compartilhar no WhatsApp
  • O OverType é um editor WYSIWYG de código aberto projetado para editar documentos Markdown visualmente, de forma direta
  • O maior diferencial deste editor é ser implementado usando apenas HTML textarea, oferecendo leveza e carregamento rápido
  • Não exige instalação nem bibliotecas externas adicionais, podendo ser usado imediatamente até em ambientes simples
  • Em comparação com outros editores Markdown, tem menos restrições de ambiente de execução, e o código é legível e fácil de manter
  • Com pré-visualização em tempo real e uma UI intuitiva centrada no usuário, até desenvolvedores iniciantes conseguem criar e editar documentos Markdown com facilidade

Principais recursos e vantagens

  • Leveza: sem código ou dependências desnecessárias, pode rodar diretamente no navegador
  • Estrutura simples: design baseado em um único textarea, facilitando depuração e expansão
  • Suporte a WYSIWYG: quando o usuário digita a sintaxe Markdown, recebe pré-visualização visual imediata
  • Acessibilidade: qualquer pessoa pode acessar sem processos de instalação complexos
  • Facilidade de uso: a estrutura do projeto é intuitiva, o que favorece aprendizado e adoção rápidos

Diferenciais

  • Em relação a editores WYSIWYG comuns, tem tamanho extremamente pequeno
  • Em comparação com editores baseados em grandes frameworks, é mais fácil de manter e personalizar
  • Com carregamento rápido e baixo uso de memória, funciona bem até em ambientes com poucos recursos
Publicidade

Formas de uso

  • Um editor Markdown simples para anotações
  • Pode ser facilmente embutido em serviços que precisem de um editor de documentos incorporado
  • Adequado para fins educacionais e ambientes de desenvolvimento de protótipos

2 comentários

 
m00nlygreat 2025-08-18

Adorei isso!

 
GN⁺ 2025-08-18
Comentários no Hacker News
  • Muito legal; se tudo funcionar imediatamente no modo plug-and-play, acho que seria muito útil. Fazendo uma pequena provocação, dizer que isso "renderiza" Markdown parece, na prática, mais próximo de "realce de sintaxe". Outra abordagem interessante seria usar a CSS Custom Highlight API; assim não seria necessário um div de pré-visualização, e também talvez desse para aplicar fontes não monoespaçadas ou diferentes tamanhos de texto em cabeçalhos etc. Mais detalhes sobre a CSS Custom Highlight API
    • Fico curioso se também dá para aplicar destaque ao conteúdo dentro de um textarea
    • Ao ver a demo expandida com animação, dá para confirmar que ele formata de um jeito claramente diferente do texto comum, como texto em negrito ou símbolos transformados em pontos
  • Concordo totalmente com a parte sobre "houve uma bagunça por causa do CSS herdado da página-pai, que desalinhava margens, paddings, line-height etc.". Nesses casos, web components com Shadow DOM seriam a solução perfeita. Se esse componente encapsulasse o textarea em vez de usar div.editor, daria para fazer um upgrade progressivo da experiência existente de textarea
  • Parece muito bom; eu já tinha reunido alguns links sobre abordagens parecidas no passado, então vou compartilhar
  • Explorando o site overtype.dev, acabei caindo num rabbit hole realmente incrível. Recomendo o app em HTML único hyperclay.com; me diverti muito com ele
    • Acho que essa abordagem é muito próxima da direção que a WWW originalmente pretendia seguir. O primeiro navegador web na verdade também oferecia recursos de edição. O app que Tim Berners-Lee criou no NeXT era basicamente um wrapper em torno da classe de rich text nativa do sistema operacional (TextView, depois NSTextView, ainda usada no app TextEdit do Mac). Mas a edição desapareceu por dois motivos: primeiro, não havia HTTP PUT, então o HTML editado só podia ser salvo localmente; segundo, o Mosaic criou um navegador multiplataforma, mas implementar também a parte de edição seria complexo demais, então ela foi removida. No fim, a maioria dos usuários se acostumou com um ambiente sem recursos de edição
    • Eu não costumo me impressionar assim, mas dessa vez fiquei realmente chocado. Não entendo por que esse método não explodiu em popularidade do jeito que está. Numa era como a atual, em que vibe coding está em alta, acho esse caminho muito mais eficiente e melhor
    • Isso me lembra os experimentos incríveis que se tentava fazer no desenvolvimento web em meados dos anos 2000. Acredito que projetos assim ajudam a elevar o padrão e as expectativas dos usuários
  • Parece muito bem acabado. Fico curioso se também daria para implementar algo como o autocomplete prateado na frente do cursor, igual ao Cursor no IDE, que ao apertar TAB é incorporado ao .value
  • Muito bom mesmo; acho que talvez combinasse mais chamar isso de "realçador de sintaxe transparente". Na demo adventure que eu fiz, também usei um <input text> oculto de forma parecida, para preservar recursos básicos como colar e selecionar, ao mesmo tempo em que integrava totalmente o estilo. Inputs nativos são muito mais simples e atraentes do que contentEditable. Se aqui ele renderizasse Markdown de verdade, mantendo o textarea completamente escondido e apenas o foco ativo, e emulasse no textarea os eventos de seleção do markup renderizado, acho que daria para juntar a estabilidade de uma caixa de texto com a beleza de um editor bonito
    • Um detalhe interessante: o realce de sintaxe na caixa de busca do GitHub foi adicionado dessa forma. Antigamente, o Shortwave (cliente de e-mail) também implementava isso do mesmo jeito, com uma view sobre um input transparente. E, com base neste blog, foi possível dar um salto de qualidade na UX de busca Delightful Search: More Than Meets the Eye (blog da Superhuman)
  • Muito incrível; gosto demais dessa simplicidade. Não parece ter desvantagens em relação a um textarea existente e ainda oferece mais benefícios. Acho que ele levou o textarea para um nível totalmente novo. Eu tinha feito no passado um projeto parecido chamado contextarea.com, e parece que seria legal combinar isso com o overtype
    • Acho que a limitação de só poder usar fonte monoespaçada é um ponto fraco. Fora do público de desenvolvedores ou programadores, isso reduz a utilidade no produto. Claro, o projeto continua sendo ótimo; só quero dizer que é uma restrição bem clara
  • Fico curioso se já consideraram encapsular isso como um web component, para poder usar direto sem precisar de div + chamada de construtor
  • Se isso fosse realmente um editor WYSIWYG, deveria haver pré-visualização de imagens; na prática, parece fornecer apenas realce de sintaxe dentro de uma área de texto. O projeto em si é bom, mas a frase de divulgação é um pouco enganosa
    • Este é um caso de uso incorreto do termo. Um editor WYSIWYG de verdade não mostra o markup de formatação
    • Você digita o texto, marca a parte que quer destacar e aperta o botão "B" para deixá-la em negrito; tirando a pré-visualização de imagens, ainda daria para chamar isso de WYSIWYG
    • Não encontrei a parte de imagens; será que deixei passar alguma coisa?
  • Compartilhando a demo spell, que funciona com 912 bytes
    • Isso é absurdo de bom; fiquei extremamente impressionado. Pode não bater exatamente com Markdown, mas parece um WYSIWYG com muito mais recursos do que o overtype (embora o overtype também seja um projeto muito bom). Fiquei chocado com o quanto se consegue fazer com 912 bytes. Parece que daria para criar um post de blog bem simples com menos de 14kb, incluindo até suporte a comentários, e ainda carregar absurdamente rápido. Fiquei impressionado num nível difícil de expressar