3 pontos por GN⁺ 2023-11-28 | 1 comentários | Compartilhar no WhatsApp
  • O formatador de código JavaScript Prettier percebeu que sua lógica de formatação estava perto de atingir um nível de estabilidade e quis estimular uma competição de desempenho por meio de uma implementação compatível baseada em Rust
  • Em 9 de novembro, o Prettier ofereceu uma recompensa de US$ 10 mil com a condição de passar em 95% da suíte de testes, e com contribuições adicionais do CEO da Vercel, Guillermo Rauch, e do napi.rs, o total chegou a US$ 22.500
  • O Biome recebeu a recompensa após várias pessoas elevarem a compatibilidade ao longo de cerca de 3 semanas, e nesse processo o alcance real de compatibilidade com o Prettier se expandiu rapidamente
  • No processo de fazer os testes passarem, também vieram à tona bugs e decisões questionáveis do Prettier, dando ao lado do Prettier evidências concretas para melhorar
  • O Prettier vem pagando US$ 1.500 por mês a 2 mantenedores com doações, mas o orçamento atual tem apenas 8 meses de runway, então são necessárias mais doações

Biome recebe a recompensa do Prettier

  • O Prettier é um formatador de código JavaScript amplamente adotado por lidar com cuidado com as muitas formas diferentes como as pessoas escrevem código
  • A lógica de formatação já está em um estado robusto, e a avaliação é que, quando o trabalho de ternaries for incorporado, chegará a um estágio satisfatório
  • O próximo desafio é melhorar o desempenho
    • O Prettier nunca foi exatamente uma ferramenta rápida, mas era rápido o suficiente para a maioria dos casos de uso
    • Para não ficar parado no estado atual, a equipe induziu melhorias por meio de uma forma amistosa de competição
  • Condições da recompensa e participação

    • Em 9 de novembro, foi oferecida uma $10k bounty para um projeto escrito em Rust que passasse em 95% da suíte de testes do Prettier
    • Guillermo Rauch, CEO da Vercel, acrescentou o mesmo valor, elevando o total para US$ 20 mil
    • O napi.rs adicionou mais US$ 2.500
    • A Algora criou uma landing page para a recompensa
  • Resultado alcançado pelo Biome

    • O projeto Biome ficou com a recompensa
    • Cerca de 12 pessoas se reuniram ao longo de aproximadamente 3 semanas para melhorar a compatibilidade
    • Mais detalhes estão no full report do Biome
    • No processo de adequar os testes, também foram encontrados vários bugs and questionable decisions do Prettier, e isso permitiu que o Prettier os melhorasse

A pressão criada pela competição de desempenho

  • O motivo de a equipe do Prettier oferecer dinheiro a outro projeto foi criar uma competição de desempenho
    • O Prettier ocupava uma posição dominante no campo dos formatadores de código JavaScript
    • A falta de concorrência reduzia o incentivo para melhorar desempenho e corrigir vários casos de borda
  • Agora o Biome tem uma implementação muito mais rápida, compatível com o Prettier, e os usuários podem migrar
  • Fabio Spampinato aproveitou o desafio para fazer um profiling adequado da CLI do Prettier e encontrou várias ineficiências extremas
    • Esses problemas devem ser corrigidos até o fim do ano

Doações e orçamento de manutenção do Prettier

  • A recompensa do Prettier e sua operação contínua só foram possíveis graças a grandes doações de várias pessoas e empresas
  • Principais doações de empresas

    • Indeed: US$ 20.000
    • Frontend Masters: US$ 10.850
    • Sentry: US$ 10.529
    • Salesforce: US$ 10.025
    • Airbnb: US$ 8.426
    • Cybozu: US$ 6.086
  • Principais doações de pessoas físicas

    • Shintaro Kaneko: US$ 1.635
    • Suhail Doshi: US$ 1.000
    • icchiman: US$ 500
    • Mariusz Nowak: US$ 270
    • Benoît Burgener: US$ 270
    • Jeremy Combs: US$ 270
    • f_subal: US$ 230
    • Graças a essas doações, o Prettier vem pagando US$ 1.500 por mês a duas pessoas e mantendo os lançamentos nos últimos 2 anos
    • Fisker Cheung e Sosuke Suzuki desempenham esse papel
    • Com o orçamento atual, restam apenas 8 meses de runway, então mais doações são necessárias
    • Se você usa o Prettier e já foi ajudado por ele, pode doar em https://opencollective.com/prettier
    • O Open Collective ajuda bastante na operação do projeto
    • Mantenedores podem se cadastrar sem fornecer informações pessoais
    • Ele funciona como um banco e permite enviar e receber dinheiro do mundo todo
    • Ele lida adequadamente com documentos fiscais
    • O Prettier arrecadou um total de US$ 110 mil e redistribuiu US$ 75 mil desse valor
    • Esta recompensa é pontual, mas o objetivo é energizar o ecossistema de formatação de código e criar uma experiência de desenvolvimento melhor

1 comentários

 
GN⁺ 2023-11-28
Comentários do Hacker News
  • Eu até entendo a curiosidade sobre por que a equipe do Prettier financiaria outro projeto, mas a resposta não me parece totalmente convincente
    Em vez de oferecer uma recompensa por melhorias no Prettier, não fica claro por que criar um projeto concorrente para incentivar melhorias no Prettier
    Também fico pensando se o objetivo final é abandonar o Prettier e migrar para uma ferramenta baseada em Rust, e isso parece fragmentar ainda mais um ecossistema que já é confuso sem necessidade

    • Parece haver três motivos para isso ter virado um projeto separado, em vez de uma recompensa por melhorias no Prettier
      Primeiro, escrever um formatador em Rust é algo diferente de melhorar a base de código do Prettier. O Prettier não foi escrito em Rust, e Rust já provou ser uma escolha sólida para implementar formatadores, então o objetivo em si está mais próximo de criar um formatador em Rust
      Segundo, $20k não é tão atraente para pedir que alguém escreva um formatador em Rust que pertença ao Prettier. Para um ótimo desenvolvedor isso dá algo como 100 horas de trabalho, o que não basta para concluir o projeto, mas se a recompensa vier junto com um projeto que a própria pessoa possa manter como seu, isso fica muito mais atraente
      Terceiro, se o Prettier fosse dono do projeto vencedor, a responsabilidade de manutenção também cairia sobre a equipe do Prettier. A equipe original teria menos incentivo para continuar mantendo, e a competição desapareceria, deixando o ecossistema menos ativo
    • Do ponto de vista de um mantenedor de código aberto, o mais importante não é que todo mundo use a minha implementação específica, e sim que o problema seja resolvido
      Eu não ganho nada diretamente porque alguém usa meu código; o trabalho foi para criar uma solução acessível. Se eu tivesse paixão por formatação de código JS, provavelmente ficaria bem feliz se outra pessoa resolvesse esse problema de um jeito mais rápido
    • Há uma grande diferença entre “somos os líderes atuais e não há alternativa viável para desenvolvedores JavaScript” e “o pessoal de Rust conseguiu e agora existe uma alternativa bastante viável”
      Isso parece mais um caso de escapar de um ótimo local. Dá para olhar para os maiores gargalos de desempenho e dizer que dá para melhorar, mas sem um ponto de comparação objetivamente melhor é difícil ter certeza
      Imitação é a forma mais sincera de elogio, e o simples fato de esse problema difícil poder ser resolvido em outra linguagem já cria valor durante o processo competitivo
      Sem alternativa real, não existe concorrência de verdade. Se a implementação em Rust remover menos de 5% da suíte de testes e ainda assim for mais rápida, isso já ensina bastante sobre os limites teóricos desse problema em comparação com a implementação padrão
      Não conheço essa área a fundo, mas acho que sempre existe valor intangível em ter implementações semelhantes em outras linguagens
    • Quando pessoas com perspectivas e intenções diferentes implementam algo, podem surgir novas direções de melhoria
      https://biomejs.dev/formatter/#differences-with-prettier
      O Biome identificou vários pontos problemáticos em que divergiu das decisões do Prettier, e só isso já mostra valor suficiente em um desenvolvimento paralelo
    • Uma abordagem com restrições e bagagens diferentes pode encontrar áreas de melhoria que não apareciam no projeto original
      Talvez justamente por não estar presa a uma forma de pensar ao estilo Prettier
  • Parece que muita gente dá explicações sem considerar este ponto junto: “ao passar em todos os testes, o projeto Biome encontrou muitos bugs e decisões questionáveis do Prettier, e isso permitiu melhorá-los”
    Para mim, isso significa que eles puderam fazer uma verificação de sanidade da própria implementação por meio de outra implementação

  • Essa notícia realmente me anima
    A velocidade com que a equipe do Biome alcançou 95% de compatibilidade com o Prettier foi impressionante https://github.com/biomejs/biome/issues/720
    Graças ao Rust, dá para aumentar bastante a velocidade da formatação de JavaScript, seguindo uma linha parecida com a do formatador Python ruff
    Não está no texto, mas a Wasmer também ofereceu uma recompensa de $2.500 para compilar o Biome para WASIX, e também foi legal ver a equipe trabalhando nisso
    Espero que em breve o Biome rode no Wasmer: https://wasmer.io/, https://wasix.org/, https://console.algora.io/challenges/prettier

    • Eu nunca tinha visto WASIX antes, mas lendo sobre isso, parece uma reencarnação da JVM
      Queria saber se esse entendimento faz sentido. Se ele pode acessar o sistema e não é um sandbox de verdade, não entendo qual é a vantagem de executar código no WASIX
    • Fico curioso se alguém sabe por que querem torná-lo compilável para WASIX
  • Melhorias de velocidade são sempre bem-vindas, mas eu gostaria que o Prettier fosse um pouco menos opinativo
    Principalmente em relação ao comprimento da linha, ele simplesmente não deixa minha formatação como está. Código formatado pelo Prettier é muito menos legível do que código não formatado, e isso é um problema que não tenho com outros formatadores como o rustfmt

    • Fico curioso se há algum exemplo de código do Prettier que seja muito menos legível
      Eu quase nunca tive esse problema e venho ficando bastante satisfeito com o Prettier
    • Fico curioso se você já tentou a opção print width: https://prettier.io/docs/en/options.html#print-width
    • O verdadeiro problema do Prettier é que ele praticamente se tornou o padrão de fato
      Pessoalmente, eu não gosto nada do Prettier, mas gosto de Svelte, e o formatador oficial do Svelte, pelo que sei, usa o Prettier. Então eu uso Prettier no Svelte, e o mesmo vale para algumas outras coisas
      Se o usuário está numa situação em que pode escolher a ferramenta, o princípio de “somos muito opinativos e, se você quiser configuração, vá para outro lugar” pode ser excelente. Mas, quando ele se torna praticamente a única opção para uma certa base de usuários, ele deveria ser um pouco mais configurável
    • Em relação ao comprimento de linha, o Prettier tem efeitos colaterais mais sutis, e por isso eu evito formatadores opinativos
      O Prettier altera o diff de maneiras não intencionais
      Se você remover um membro de uma atribuição por desestruturação e isso fizer o código ficar abaixo do limite de comprimento de linha, o diff pode virar +1/-5 em vez de 0/-1. A pessoa revisando não consegue ver de imediato exatamente o que saiu entre 5 linhas removidas e 1 adicionada
      Se você tentar corrigir um erro de digitação em um commit anterior com o rebase interativo do Git, o Prettier pode reformatar o bloco inteiro de código e fazer com que os commits seguintes talvez não se apliquem
      Se você configurar um hook de pre-commit para rodar o Prettier e depois tentar dar stage em apenas parte das mudanças de um arquivo, surgem outros problemas divertidos. Eu passo
    • Concordo. Indo além, eu diria até que seria melhor se o Prettier nunca tivesse existido
  • Ainda me irrita que vários plugins do eslint tenham removido um linter perfeitamente bom e o substituído pelo Prettier
    O Prettier é autoritário demais, difícil de prever, e mais uma ferramenta que eu nunca pedi

    • As regras de estilo descontinuadas foram portadas para um novo projeto: https://eslint.style/guide/why
    • O propósito desse tipo de ferramenta é justamente acabar com as discussões sobre estilo
    • Não entendo muito bem em que casos seria necessário “prever” o Prettier
      A única coisa que me vem à mente são problemas ocasionais com conflitos de merge
  • Há sim uma tendência de portar para Rust, mas como o Prettier roda toda vez que se salva, o ganho de velocidade deve ser bem grande
    Pretendo testar o Biome em breve, e deixo meus parabéns ao projeto Biome

    • Nunca percebi latência quando o Prettier roda em um único arquivo
      Onde o desempenho passa a importar é ao rodar formatação no repositório inteiro
      Em uso interativo, você deveria usar um processo de longa duração e já aquecido; nesse caso, o tempo de inicialização do Node não importa. Idealmente, verificação de tipos, linting, destaque e formatação deveriam estar todos em um único serviço de linguagem, fazendo parsing incremental a cada tecla e atualizando um AST compartilhado
    • Isso me lembra o entusiasmo da comunidade Python com o ruff
      Espero melhorias amplas de eficiência e velocidade
    • Recomendo usar a ferramenta lint-staged para que o Prettier rode, a cada salvamento, apenas nos arquivos alterados e não no projeto inteiro
      Em projetos grandes, a diferença é enorme
  • “Agora podemos focar no próximo aspecto importante: desempenho. O Prettier nunca foi essencialmente rápido, mas foi rápido o suficiente para a maioria dos usos. Isso nunca me satisfez, então eu queria fazer algo a respeito. O que poderia ser melhor do que uma competição amigável? Em 9 de novembro, ofereci uma recompensa de US$ 10 mil para um projeto em Rust que passasse em 95% da suíte de testes do Prettier”
    Não entendo como o simples fato de algo ter sido escrito em Rust leva a um desempenho melhor. Alguém poderia até ter simplesmente transpilado a base de código existente para Rust e levado a recompensa

    • Quando vejo a palavra “simplesmente”, tendo a achar que o que vem depois não vai ser simples
      Porque, se fosse realmente simples, não haveria necessidade de qualificar desse jeito
      Nesse caso, não sei se transpilação de uma base JavaScript para Rust seria algo simples. As duas linguagens têm modelos de pensamento, bibliotecas usadas e formas de escrever código bem diferentes, e mesmo que exista um transpiler de JS para Rust, duvido que ele seja robusto o suficiente para uma base do tamanho do Prettier
    • Rust idiomático muitas vezes é 5 a 10 vezes mais rápido do que código JavaScript/TypeScript aparentemente parecido, mesmo sem otimizações especiais
      Depende da tarefa e nem sempre é assim, mas analisadores com muita manipulação de strings certamente entram nesse caso
    • Em processamento de strings, Rust é muito mais rápido que JS
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fasta.html
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html
    • A resposta que recebi de vjeux foi esta: “há muitas ferramentas web rápidas sendo escritas em Rust hoje em dia”
      https://twitter.com/Vjeux/status/1722769322299609565
      Isso não me convence, e parece que o vjeux embarcou na onda do Rust
  • O projeto vencedor, Biome, é um fork ou uma renomeação do projeto Rome, iniciado alguns anos atrás por Sebastian McKenzie, criador do Babel
    Ele aparentemente esteve ausente por cerca de um ano, e como muitos acessos a recursos do projeto estavam só com ele, os contribuidores não conseguiam fazer atualizações, então houve o fork
    Espero que ele esteja bem e, independentemente disso, fico feliz em ver que o projeto Biome parece estar indo bem

  • Não entendo por que precisava ser necessariamente em Rust
    Não bastava simplesmente ser “mais rápido”? A implementação em Rust é de fato mais rápida? Também fico em dúvida se segurança de memória ou vazamentos são realmente tão importantes para um programa como o Prettier

    • Especialmente no HN, há muita gente que acha que Rust é atualmente a linguagem mais rápida e segura
      Então, em certa medida, isso pode ter sido um desafio com recompensa do tipo “se é isso mesmo, então provem na prática”
  • Fico curioso se existe algum benchmark do Biome por aí
    Exatamente quanto melhor é o desempenho em relação ao Prettier?