Mudei para o Zed na semana passada. Ou algo assim.
A real é o seguinte: o Zed é mais rápido que o VSCode em tudo que importa. Tempo de inicialização, resposta aos comandos, ausência daquele atraso irritante de 200ms quando você digita num arquivo gigante. Tudo isso funciona. O editor parece que foi feito nesta década, não montado com peças recicladas de Electron vindas de uma build do Chromium de 2015.
Mesmo assim, ainda estou usando dois editores ao mesmo tempo, como um masoquista funcional. Já explico.
O Que o Zed Faz Direito
Depois de anos vendo o VSCode acumular extensões, telemetria e sobrecarga de Electron, o Zed parece um gole de água gelada. É assim que um editor moderno deveria ser.
Velocidade que realmente importa. O Zed abre instantaneamente. O VSCode leva de 2 a 3 segundos no meu computador, e ainda mais na minha máquina remota. Multiplica isso pelas dezenas de vezes que abro projetos por dia e pronto: tempo real economizado. Mais importante ainda, não existe lag de digitação. Nada de micro travadinhas em arquivos grandes. Nada de congeladas rápidas quando o extension host resolve inventar moda. Só edição fluida.
Uso de memória que não me obriga a abrir o Activity Monitor. O VSCode facilmente vai para 1.5–2GB de RAM com alguns projetos abertos. Soma extensões e você ganha vários processos torrando mais um giga. O Zed fica ali, de boa, entre 200–300MB para a mesma carga. Não preciso fechar o editor para rodar Docker ou abrir um navegador com mais de três abas. As ventoinhas do PC agradecem e ficam quietas.
Agilidade em tudo. Trocar de arquivo é instantâneo. Servidores de linguagem parecem bem mais rápidos, e go-to-definition acontece na hora. O realce de sintaxe atualiza em tempo real, sem aquele tremelique estranho que o VSCode às vezes faz. São centenas de micro otimizações que fazem a ferramenta sumir da frente.
Descoberta de keybinds do jeito certo. A paleta de comandos do Zed mostra os atalhos ao lado de cada comando. Parece óbvio depois que você vê, mas muda o jogo para aprender e lembrar keybindings. Em vez de caçar em menus ou jogar no Google “como dividir editor no VSCode”, a resposta já está ali.
Pensado para desempenho, não para extensibilidade. Isso é polêmico, mas é a arma secreta do Zed. O VSCode virou uma plataforma, e plataforma vem com compromissos, camadas de compatibilidade e complexidade. O Zed é um editor. Esse foco único aparece em tudo.
Na primeira semana usando o Zed, esses pequenos momentos de satisfação apareceram o tempo todo. Cmd+P é instantâneo. Git blame abre sem lag. Diffs grandes não engasgam a UI. Nada disso é recurso chamativo. É a base de uma ferramenta que respeita seu tempo.
O Efeito Composto da Eficiência
Aqui está algo que eu não esperava: desempenho muda o jeito que você trabalha. Quando uma ação é instantânea, você faz mais vezes. Navego pelo código com mais liberdade. Experimento mais. Não fico pensando duas vezes antes de abrir ou fechar arquivos porque não existe atrito.
No VSCode, eu tinha criado workarounds inconscientes. Manter menos abas abertas para aliviar a memória. Evitar extensões específicas porque deixavam tudo lento. Esperar um pouquinho antes de digitar depois de abrir um arquivo. No Zed, esses workarounds simplesmente desapareceram.
O Que Ainda Falta (Mas Não Impede)
O Zed é novo. Alguns recursos que eu uso ainda não chegaram lá.
-
Integração com Git é básica. Nada de gráfico de árvore, nada de histórico de commit mais rico (só histórico por arquivo). Para investigações mais cabeludas de merge ou branches, ainda volto para o VSCode ou GitKraken. Dito isso, tem gente trabalhando ativamente nisso. É uma lacuna conhecida, não abandono.
-
Realce de sintaxe ainda é raso. Alguns recursos avançados de linguagem perdem destaque correto. Dá para ler e trabalhar, mas quem está acostumado com semantic tokens do VSCode ou gramáticas TextMate super refinadas vai sentir falta.
-
Desenvolvimento remoto precisa amadurecer. Trabalho com instâncias EC2 o tempo todo. O Remote-SSH do VSCode é sólido: debugging, encaminhamento de portas, a experiência completa via SSH. O Zed tem suporte a projetos remotos, mas coisas como debugging ainda falham de forma inconsistente. Para trabalho remoto sério, isso pesa.
-
Estranhezas em multi-root workspace. Projetos com múltiplas pastas têm arestas. O terminal integrado sempre abre na primeira pasta. Arquivos de config só salvam ali também. Funciona, mas não é polido.
-
Limitações de personalização da UI. Nada de rolagem suave (eu gosto da estética, me julgue). A visualização de Markdown usa a fonte da UI sem opção de trocar por monospace. Pequenos incômodos que se acumulam se você liga para esses detalhes.
A Estratégia dos Dois Editores
Não estou forçando migração. É assim que você perde um dia inteiro ajustando config ou descobre uma limitação crítica em cima do prazo.
Minha estratégia atual:
- Zed para trabalho diário, projetos novos e desenvolvimento local. Onde velocidade e resposta importam mais.
- VSCode para remote debugging, operações complexas de git e projetos legados. Quando preciso do ecossistema maduro e das ferramentas já testadas na guerra.
Essa configuração de dois editores (Zed à direita, VSCode à esquerda) não é definitiva, mas me deixa aproveitar o melhor do Zed sem ignorar suas limitações atuais.
Por Que Acho Que o Zed Vai Vencer
O cemitério de editores é grande. Atom, Brackets, Light Table. Todos tentaram e caíram. Mas o Zed tem algo diferente: vantagem clara de desempenho e desenvolvimento rápido, focado.
Os recursos que eu preciso não são vaporware. São issues rastreadas, com progresso real. O time entrega com frequência, constrói em público e não tenta agradar todo mundo.
O Zed acerta o básico. É rápido. É estável. Respeita minha atenção. O resto são recursos, e recursos podem ser construídos. Velocidade é arquitetura. E isso o Zed acertou desde o dia um.
Já vi muita ferramenta começar enxuta e virar um monstro irreconhecível. O Zed pode seguir esse caminho. Mas hoje, ele é exatamente o que eu preciso.
Quando as ferramentas de git amadurecerem e o desenvolvimento remoto estabilizar, desinstalo o VSCode sem drama. Até lá, fico com o melhor dos dois mundos e passo a maior parte do tempo no Zed.
Minha Configuração Atual
Uso o Zed para 70% do meu trabalho: edições rápidas, programação exploratória, qualquer coisa que não envolva arqueologia de Git ou remote debugging. É meu editor padrão no shell.
Uso o VSCode para os outros 30%: operações complexas de Git, desenvolvimento remoto em EC2, depuração de bugs estranhos de multi-root workspace e visualizações de Markdown que não deixam meus exemplos de código com cara de bagunça.
Não é elegante. Funciona. Espero que essa proporção continue mudando.
A Aposta
Vou dar seis meses para o Zed. Se o gráfico de Git sair, se o desenvolvimento remoto ficar utilizável, se os multi-root workspaces forem corrigidos, eu deleto o VSCode e sigo a vida.
Se não, eu reavalio. Mas sinceramente, acho que não vai ser necessário. A distância entre “rápido mas incompleto” e “completo mas inchado” está diminuindo. E rápido.
Eu recomendaria? Se você valoriza desempenho e não depende pesado dos recursos avançados de git ou desenvolvimento remoto do VSCode, sim. Testa por uma semana. Só a velocidade talvez já te convença.