O crime contra o GitHub e o software

• O GitHub é usado como peça central da infraestrutura de desenvolvimento, mas há avaliações de que sua confiabilidade básica está abalada por incidentes frequentes, páginas lentas e quebras no navegador
• A Microsoft disse que a carga aumentou fortemente por causa de agentic workflows, mas também cresce a crítica de que ela própria empurrou funções do GitHub, Copilot e agentes para induzir o uso
• Em um experimento com um repositório mínimo, o GitHub baixou 291 requisições, 15 MiB de resposta comprimida e 544.564 linhas expandidas, em forte contraste com as 11 requisições do Codeberg
• Na medição de frontend, o GitHub usou cerca de 69 MiB de heap em estado normal, e a página de pull request do rust-lang usou 148 MiB, o que foi avaliado como desperdício excessivo para páginas centradas em texto
• A conclusão é que o desperdício do GitHub não é apenas uma piora do produto, mas uma falha de software que prioriza recursos de IA e interesses de investidores acima de resolver os problemas dos usuários

---

Confiabilidade e prioridades do GitHub

• O GitHub é usado como peça central da infraestrutura de desenvolvimento de software, mas sua confiabilidade básica é colocada em dúvida por downtime, degradação de desempenho e problemas de compatibilidade com navegadores
• O histórico do GitHub Status registra dezenas de incidentes por mês, e há situações que também podem ser vistas como violações pelos critérios da página oficial de status e do SLA
• Há críticas de que ele quebra com frequência no Firefox e no Safari, que páginas de comentários e revisão de pull request são lentas, e que o uso de RAM e os picos de heap são excessivos
• O GitHub Actions é descrito como lento e mal documentado, e a tela de logs é apontada como causadora de vazamento de memória e travamentos do navegador ao longo de vários anos
• O comportamento de cache de ações básicas como setup-go também é avaliado como sem invalidação ou excessivamente simples
• Existem sites como githubstars.com que anunciam abertamente a compra de stars, e também é citada a frase “fake stars are highly related to malicious activities” de um artigo da Carnegie Mellon
• O alvo que o GitHub deveria perseguir é o de um sistema distribuído de alto desempenho, alta disponibilidade e grande escala, mas o produto real é avaliado como priorizando recursos de IA e fluxos com agentes acima da confiabilidade básica

Carga “agentic” e a responsabilidade da Microsoft

• No texto ‘an update on github availability’, o GitHub afirmou que, desde a segunda metade de dezembro de 2025, os agentic development workflows aceleraram de forma acentuada, com rápido aumento na criação de repositórios, atividade de pull requests, uso de API, automação e workloads de repositórios grandes
• Essa explicação trata o aumento de carga como se fosse um fenômeno externo, mas leva à crítica de que o GitHub e sua controladora Microsoft empurraram IA e “agents” para vários produtos e estimularam diretamente o uso
  • Quase toda barra superior das páginas do GitHub tem 3 botões de IA, dos quais 2 servem exclusivamente para iniciar agentes, e muitas páginas têm 4
  • Na área superior direita de uma página comum de repositório, há 4 maneiras de iniciar o Copilot
  • É apresentado um link crítico dizendo que o GitHub subsidiou por anos o custo de uso dessas ferramentas para impulsionar a adoção, o que equivale a financiar um ataque distribuído de negação de serviço contra si mesmo
• A Microsoft explica que um único pull request pode acionar o repositório Git, verificação de possibilidade de merge, branch protection, GitHub Actions, busca, notificações, permissões, webhooks, APIs, jobs em background, cache e banco de dados
• Em grande escala, até pequenas ineficiências podem levar a filas mais profundas, cache miss, carga no banco de dados, atraso de indexação e amplificação de tráfego por novas tentativas, mas a avaliação é de que as ineficiências do GitHub não são “pequenas”, e sim gigantescas e avassaladoras
• A Microsoft declarou “availability first, then capacity, then new features”, mas, no changelog público do GitHub, nos 30 dias após essa atualização, as notas de patch mencionaram “copilot” 59 vezes, “agent” 8 vezes, e “performance” e “reliability” 0 vezes
  • O filtro do changelog tem uma categoria própria para copilot, mas não há categorias performance nem reliability
  • O Visual Studio Code também é integrado diretamente com recursos do GitHub e “agentic”, e há críticas de que funções de agente continuam sendo adicionadas mesmo enquanto recursos básicos como o terminal embutido pioram
• O trecho em que a Microsoft diz estar reduzindo “unnecessary work”, melhorando cache, isolando serviços críticos, removendo pontos únicos de falha, migrando caminhos sensíveis a desempenho, reduzindo acoplamentos ocultos, limitando o blast radius e implementando graceful degradation é interpretado como uma admissão de que o projeto do sistema está errado

Por que o frontend sugere problemas no backend

• A raiz dos problemas de confiabilidade do GitHub está no backend e no banco de dados, mas isso não pode ser visto de fora; em vez disso, é possível observar o código de frontend baixado a cada acesso, como HTML, JavaScript e CSS
• Assim como ver ratos no salão de uma pizzaria dificulta acreditar que a cozinha esteja limpa, entende-se que a deterioração visível do frontend do GitHub sugere problemas no backend, ainda que não os prove
• As páginas iniciais de repositórios no GitHub, GitLab e Codeberg consistem em listas de links, pequenos elementos de UX, botões, abas e campo de busca, com quase nenhum elemento caro como mídia interativa ou imagens
• Essas páginas deveriam rodar de forma barata em quase qualquer computador ou celular, mesmo sem uma boa conexão de internet, e é apontado que o GitHub realmente funcionava assim no passado até em iPhone 4 com conexão 3G
• Se a funcionalidade for a mesma, o melhor código é definido como aquele que usa menos largura de banda de rede, tempo de CPU e RAM, e que tem menos bugs
• Não é possível saber diretamente o número de bugs do frontend, mas pesquisas históricas indicam que a quantidade de bugs costuma ser proporcional ao número de linhas de código
  • Steve McConnel, Code Complete, 2nd Ed (2004) é citado dizendo que a média do setor para software entregue fica entre 1 e 25 erros por mil linhas de código
  • Cita-se que a Microsoft Applications Division observou de 10 a 20 defeitos por mil linhas de código em testes internos, e 0,5 defeito por mil linhas em produtos lançados

Desenho do experimento e método de coleta

• Para reduzir variáveis de confusão, a velocidade da internet foi limitada a uma conexão “fast 3G”
  • Essa configuração serve para reduzir o impacto de variações das condições de rede e simular a experiência de clientes do GitHub em situações menos ideais, como áreas rurais
• O mesmo repositório mínimo ghsucks foi usado nos três serviços
  • branch única master
  • arquivo único README.md
  • 0 elementos adicionais, como issues e tags
• Foi usado o mesmo navegador e o mesmo computador
  • Firefox
  • Apple Macbook Pro M5 Max
  • 48 GiB de RAM
• Em cada serviço, foram examinadas quatro páginas
  • página “landing”: layout do código
  • página de “pull requests” ou “merge requests”
  • página de “issues”
  • página de “settings”
• Com o cache limpo, foi coletado um HTTP Archive (HAR) para analisar as requisições de rede, e, após o término do carregamento, foi coletado um heap snapshot para obter uma estimativa do uso de RAM em estado estável
• Para a análise do HAR, foi usado o anhar escrito pelo próprio autor; para análise com suporte a compressão, o testcompress; e, para verificação cruzada, o pagespeed.web.dev

Uso de heap e desperdício de memória

• O uso de heap na página padrão de repositório foi medido em 69 MiB no GitHub, 68 MiB no GitLab, 14 MiB no Codeberg e 1,3 MiB no eblog.fly.dev
• A renderização da primeira página de issues em https://github.com/rust-lang/rust/pulls usa 148 MiB de RAM
• 148 MiB é mais memória do que o iPhone original tinha e, para uma página centrada em texto com alguns links, isso é avaliado como desperdício extremo
• Como comparação, são citadas memórias de dispositivos como Apple iphone 1 com 128 MiB, iphone 4 com 512 MiB, Sony playstation 2 com 32 MiB e Nintendo wii com 88 MiB

Comparação do volume de requisições e do tamanho das respostas

• anhar é um programa em Go que faz parsing de HAR JSON, formata automaticamente o HTML, CSS e JavaScript das respostas com deno fmt e depois calcula tamanho de requisições e respostas, totais por MIME, tempo de carregamento e número de linhas da resposta
• As principais métricas são: tamanho das requisições, tamanho real das respostas minificadas recebidas, tamanho e número de linhas das respostas expandidas após aplicar deno fmt, o Content-Load como tempo de carregamento do HTML básico e o Load como tempo de carregamento de todo o conteúdo
• A página de repositório do Codeberg foi medida com 11 requisições no total, 9 KiB de requisições, 1 MiB de respostas, 1 MiB de respostas expandidas, 3.480 linhas expandidas, Content-Load de 2.934s e Load de 3.172s
• A página de repositório do GitHub foi medida com 291 requisições, 178 KiB de requisições, 15 MiB de respostas minificadas, 22 MiB de respostas expandidas, 544.564 linhas expandidas, Content-Load de 843ms e Load de 21.330s
  • application/javascript: 214 requisições, 12 MiB de respostas, 19 MiB de respostas expandidas, 481.849 linhas expandidas
  • text/css: 42 requisições, 2 MiB de respostas, 60.016 linhas expandidas
  • GitHub pulls: 266 requisições, 14 MiB minificados, 20 MiB expandidos, 487.922 linhas expandidas, Content-Load de 592ms, Load de 6.754s
  • GitHub settings: 255 requisições, 14 MiB minificados, 20 MiB expandidos, 486.067 linhas expandidas, Content-Load de 778ms, Load de 6.963s
• O GitLab é menor que o GitHub, mas continua pesado
  • Repositório no GitLab: 78 requisições, 8 MiB de respostas, 101.682 linhas expandidas, Content-Load de 6.880s, Load de 12.941s
  • GitLab merge_requests: 65 requisições, 7 MiB de respostas, 90.567 linhas expandidas, Content-Load de 6.947s, Load de 12.096s
  • GitLab edit: 117 requisições, 7 MiB de respostas, 71.916 linhas expandidas, Content-Load de 6.964s, Load de 13.302s
• Afirma-se que o GitHub busca cerca de 540 mil linhas de código e dados até para mostrar um repositório vazio, mais do que DOOM com 35 mil linhas, Windows Quake com 120 mil linhas, MS-DOS 4.0 com 332 mil linhas e a toolchain do Zig com 460 mil linhas
• Considera-se problemático que páginas individuais busquem 40 arquivos CSS e centenas de arquivos JavaScript
• A divisão em chunks do Webpack pode, em teoria, separar recursos centrais de recursos opcionais e favorecer cache e CDN, mas aqui ela é interpretada como algo que atrasa o carregamento porque cada arquivo exige uma requisição HTTP independente
• Esperar 22 segundos para ver uma página vazia é considerado inaceitável, e avalia-se que mesmo com fibra de mais de 1 GiB/s e um processador de consumo de alto desempenho ainda leva mais de 1 segundo até que o repositório fique minimamente utilizável

Comparação de suporte à compressão

• A compressão é apresentada como uma forma útil de reduzir a carga no cliente, no servidor e no caminho intermediário
• gzip é um padrão de compressão comprovado e deveria ser suportado por todos os sites, enquanto zstd tem boas características de desempenho, mas por ser mais moderno é tratado como algo “bom de ter”
• testcompress é um programa em Go que testa se uma URL suporta compressão gzip e zstd; se não suportar, ele compacta o corpo da resposta diretamente para mostrar a economia potencial
• eblog.fly.dev/startingsystems3.html: codificações suportadas zstd gzip, original 575.77KiB, gzip 67.64KiB, zstd 60.17KiB
• github.com/ef0xa/ghsucks: codificações suportadas gzip, original 224.70KiB, gzip 43.27KiB, zstd 37.96KiB
• gitlab.com/efronlicht/ghsucks: codificações suportadas gzip, original 43.08KiB, gzip 11.48KiB, zstd 11.34KiB
• codeberg.org/efronlicht/ghsucks: codificações suportadas n/a, original 43.88KiB, gzip 13.00KiB, zstd 12.79KiB

Resultados mobile do PageSpeed

• Na medição mobile do pagespeed.web.dev, o Codeberg recebeu PASS com First Contentful Paint de 1.2s, Largest Contentful Paint de 1.3s e Interaction to Next Paint de 86ms
• eblog.fly.dev recebeu PASS com First Contentful Paint de 1.1s, Largest Contentful Paint de 1s e Interaction to Next Paint N/A
• O GitHub recebeu FAIL com First Contentful Paint de 1.8s, Largest Contentful Paint de 2.1s e Interaction to Next Paint de 242ms
• O GitLab recebeu FAIL com First Contentful Paint de 2.1s, Largest Contentful Paint de 2.4s e Interaction to Next Paint de 243ms

Avaliação por serviço

• GitHub

  • Traz cerca de 300 arquivos, com aproximadamente 550.000 linhas de código e dados, e estima-se que tenha 550 bugs
  • O Content-Load é de cerca de 800 ms, o Load total é de cerca de 7 s, e o heap em estado estável é resumido em cerca de 69 MiB
  • Suporta gzip, mas não zstd
  • Recebe nota F, sendo avaliado como tendo um peso de código extremamente grande
  • Aponta-se que o GitHub carrega todos os temas em todas as páginas, independentemente de serem usados ou não
  • Como o pagespeed.web.dev indica que 528 KiB de JavaScript e CSS não são usados de forma alguma, considera-se que essa redução poderia começar por aí
  • Caso precise continuar no GitHub, surge a sugestão de que ele estaria violando o SLA do próprio GitHub, e de abrir um ticket de suporte para pedir reembolso

• GitLab

  • O Content-Load é de cerca de 7 s, o Load é de cerca de 13 s, e ele traz 7 MiB em mais de 70 arquivos, com cerca de 10.000 linhas
  • O heap em estado estável é de cerca de 68 MiB, e ele suporta gzip, mas não zstd
  • Recebe nota D+, sendo avaliado como menos desperdiçador que o GitHub, mas ainda assim trazendo recursos demais e sem usá-los direito
  • Baixa mais de 1 MiB de JavaScript e CSS, mas há partes que na prática não são usadas de forma alguma, e mesmo no código utilizado há chunks de 3 MiB cujo parsing sozinho leva 255 ms
  • Considera-se que a landing page não precisa de 55.000 linhas de CSS, e que tanto o CSS quanto o JavaScript poderiam ser reduzidos para algo como um décimo do nível atual

• Codeberg/Forgejo

  • O Content-Load é de 2,9 s, o Load é de 3,1 s, e ele traz 1 MiB em 11 arquivos, com cerca de 1.100 linhas
  • O heap em estado estável é de cerca de 14 MiB, e ele não suporta nem gzip nem zstd
  • Recebe nota C+, sendo avaliado como tendo o básico, mas faltando atenção aos detalhes e experiência
  • O fato de não fazer minify de HTML é um problema pequeno, mas a falta de suporte a compressão é vista como uma omissão grave
  • A maior parte do JavaScript e do CSS não é necessária para renderizar a página, mas o problema apontado é que eles são carregados de forma bloqueante para a renderização
  • Surge a proposta de combinar os payloads de JavaScript e CSS para reduzir o número de requisições, e de oferecer suporte a compressão gzip e zstd para os payloads HTTP, incluindo o HTML
  • Como é software livre, destaca-se como vantagem a possibilidade de migrar para outra instância ou fazer self-hosting

• eblog.fly.dev

  • eblog.fly.dev/startingsystems3.html foi medido com Content-Load de 76 ms, Load de 1,1 s, 766 KiB em 5 arquivos e cerca de 3.800 linhas
  • O arquivo HTML único tem 576 KiB e é comprimido para cerca de 70 KiB com zstd
  • O heap em estado estável é de cerca de 11 MiB, e ele suporta tanto zstd quanto gzip
  • Recebe nota A-, sendo avaliado como bom no geral, mas com HTML grande e repetitivo mesmo considerando a compressão, e com uma página que poderia terminar em uma única requisição, mas exige 5

Não é só piora do produto, é questão de custo

• “enshittification” é resumido como o processo em que um bom produto começa favorecendo usuários e clientes empresariais, depois passa a prejudicar os usuários, em seguida também prejudica os clientes empresariais, e acaba favorecendo o operador
• Microsoft e GitHub também não são totalmente dissociados de Embrace, Extend, Extinguish, mas considera-se que o problema aqui é diferente por gerar custos não só para usuários e clientes empresariais, mas também para a própria Microsoft
• Uma base de código inchada aumenta diretamente os custos de servidor e largura de banda, além de consumir indiretamente tempo de engenharia para manter uma base instável e excessivamente grande
• Partindo da suposição de que há cerca de 800 engenheiros no GitHub, trabalhando 40 horas por semana e 48 semanas por ano, isso equivale a 1.536.000 horas-engenheiro por ano
• Considera-se que a maior parte dos problemas de frontend poderia ser corrigida ou mitigada por um engenheiro competente em menos de uma semana apenas seguindo as recomendações do pagespeed
• Interpreta-se que melhorias de baixo nível capazes de reduzir custos são deixadas de lado por desinteresse, incompetência extrema ou por estarem bloqueadas por uma liderança centrada em IA e investidores
• O software é descrito como uma ferramenta poderosa e bela porque, uma vez escrito corretamente, pode ser copiado de forma perfeita, para sempre e de graça, para que todos o usem
• Conclui-se que o desperdício e a incompetência do GitHub e de serviços semelhantes não são apenas um produto ruim, mas sim um crime contra o software

[GN⁺]

Opiniões no Lobste.rs

• Seria bom incluir Trac e Sourcehut nessa comparação

• Os 4 botões de agente de IA são engraçados, e os números relativos mostrados no texto também são interessantes, mas isso não significa que eu queira defender o GitHub; ainda assim, alguns detalhes do texto carecem de contexto e não parecem suficientes para sustentar o argumento do autor
  O uso de memória ociosa pode ser um sinal de que o GitHub faz mais coisas que o Codeberg, mas é difícil tirar uma conclusão significativa comparando o uso absoluto de RAM em um computador com 48 GB de RAM com o computador de guiagem da Apollo
  Estimar o número de linhas de código formatando bundles minificados de JavaScript e comparar isso com o número de linhas de um projeto em Zig sem dependências também é comparar coisas totalmente diferentes. Seria como pedir para decompilar o executável em Zig e ver quantas linhas aparecem
  Também não entendi a recomendação de que o Codeberg “deveria combinar os payloads de JavaScript e CSS para reduzir o número de requisições”. Pelo jeito como fala do “overhead adicional” das requisições HTTP, fico até em dúvida se o autor conhece HTTP/2
  Eu teria muito mais a dizer sobre desempenho de páginas web, mas deixo isso para outro texto; para uma perspectiva melhor sobre tema parecido, recomendo reler o texto do Danluu sobre inchaço da web, de 2017: https://danluu.com/web-bloat

• Se o autor estiver vendo isso, talvez valha a pena olhar a discussão entre Casey Muratori e Uncle Bob. O primeiro encontrou uma degradação de desempenho muito interessante
  “Não resisti, fui olhar uma captura de desempenho do Chrome e descobri o culpado :) era o ‘emoji picker’!”
  “Só dei uma olhada rápida no código, mas o problema parece ser que, a cada caractere digitado, o ‘emoji picker’ volta para trás e verifica se o que acabou de ser digitado é um emoji”
  Argh. Dito isso, nesse caso o culpado talvez não seja o código de frontend do GitHub, e sim um navegador baseado em Chromium

• A frase “Codeberg é um produto oferecido por voluntários livres e dependente de doações independentes” não está correta
  O Codeberg depende de membros. Não só das contribuições, mas também em termos de política; e, embora atualmente as contribuições não sejam suficientes para contratar funcionários em tempo integral, então ele ainda dependa bastante de voluntários, pelo que entendo também há contratados
  Não acompanho o Codeberg tão de perto (prefiro mais o lado do sourcehut), mas o fato de ser uma cooperativa é uma das partes centrais da proposta de valor. Eles também tentam publicar os gastos com transparência. Ex.: https://blog.codeberg.org/codebergs-budget-of-2026.html
  Se você usa o Codeberg, talvez valha considerar virar membro agora: https://join.codeberg.org/

• Eu realmente odeio o GitHub. Meu problema não é uptime, e sim o fato de ser absurdamente lento e consumir memória demais. “Esse diff é grande demais para ser exibido por padrão”, fala sério
  Também quebra fluxos de desenvolvimento perfeitamente razoáveis. Se você faz rebase de um PR, o feedback e os comentários da revisão somem; se faz squash dos commits, o feedback e os comentários da revisão também somem
  Mesmo que exista um link para um comentário específico, se aquele commit desaparecer, o comentário vai junto \o/
  Se houver uma correção de bug, mandam abrir um PR; e mesmo que esse bug tenha sido corrigido por outra mudança, como PR e bug existem no mesmo nível, o PR morto fica para sempre na fila de revisão
  Se eu quiser saber qual bug este commit corrigiu, ele só me mostra o histórico do PR. É como se dissesse para olhar o PR, não o bug; se eu quiser saber do bug, tenho que ir caçá-lo manualmente

  • O próprio conceito de “pull request” veio, assim como o git, do desenvolvimento do kernel Linux. O fluxo é pedir ao mantenedor do kernel para “puxar” um patch para a mainline
    O GitHub pegou esse fluxo, deixou mais conveniente com o botão “fork”, adicionou nomes de usuário centralizados para deixá-lo mais “social” e colou um rastreador de issues e uma wiki, conquistando o mundo. Do ponto de vista de negócio, foi genial
    Mas o fluxo inteiro ainda é voltado para desenvolvimento open source em que pessoas separadas pedem que seus patches sejam “puxados”
    Não entendo por que uma equipe de desenvolvimento próxima, em que o mecanismo real é “discutir a branch e aprovar o merge”, precisa usar “pull request”. Puxar de onde, exatamente? Está tudo no mesmo repositório e a mudança já foi enviada com push
    Mesmo deixando a questão do termo de lado, a falta de mudanças acumuladas, comentários estáveis e diffs de conjunto de mudanças é absurda
    Desculpem por mais uma reclamação tediosa sobre o GitHub. Existe alguma alternativa melhor? Claro, ninguém consegue obrigar os outros a usá-la, mas...

• Já vi várias vezes a reação de que “gráficos sem rótulos nos eixos ou pontos de dados individuais são sempre suspeitos” sobre gráficos publicados pelo GitHub
  O valor máximo aparece no gráfico, então dá para estimar visualmente que o ponto médio do eixo y seja algo como 45M, 0,7B e 10M, respectivamente. Claro, isso assumindo que não seja uma escala logarítmica escondida e que a carga não tenha aumentado 100000 vezes
  Eu não chamaria um gráfico ruim aqui de “suspeito”; diria só que é má comunicação. Pessoalmente, sempre prefiro uma saída bruta do ggplot
  Concordo com o sentimento geral, mas na parte do cavalo gordo e das muitas tabelas ficou um pouco difícil de acompanhar. Ainda assim, se eu estivesse listando todos os defeitos do GitHub, provavelmente também começaria a sonhar que enlouqueci, subi num cavalo gordo e fui embora rumo ao pôr do sol
  Eu também comecei a fazer uma lista parecida, mas desisti quando cheguei a uns 12 problemas de UX/desempenho. Gosto da análise minuciosa deste texto e espero que a equipe do GitHub realmente o examine direito
  Como eu disse antes, a Microsoft deveria alocar alguns engenheiros de performance para o GitHub. Enquanto métricas de desempenho não entrarem de fato nos KPIs, esse inchaço vai continuar e outras plataformas vão parecer mais atraentes. Se houver um próximo CEO do GitHub, espero que trate isso como prioridade

  • Você está assumindo que o eixo y do gráfico começa em 0. Em gráficos corporativos isso muitas vezes não acontece
    É comum alegarem “crescimento enorme”, a linha do gráfico atravessar a imagem na diagonal inteira, mas o eixo y ir só de 100 a 101

• Concordo com a observação de que “os logs do GitHub Actions vazam memória e matam meu navegador há anos, e ainda não existe um jeito de simplesmente fazer pipe do stdout para algum lugar”
  Infelizmente o Forgejo herdou isso também. Às vezes recebo uma notificação de build falho e tento ver rápido pelo celular, mas em muitos casos o navegador do telefone nem consegue carregar a saída

• Quando cliquei neste texto, achei totalmente que seria mais uma reclamação sobre uptime do GitHub, mas no fim fiquei agradavelmente surpreso: é um texto que avalia com calma e de forma sensata os problemas atuais de GitHub, GitLab e Codeberg, e ainda propõe soluções
  Seria bom incluir Tangled na comparação também
  O autor deveria escrever um pouco de CSS para que o site fosse legível no celular. Tive que usar o modo de leitura do navegador
  A única parte de que discordo é a ideia de que nenhum site deveria carregar mais de um arquivo de JavaScript/CSS
  Se essas 550 mil linhas de JavaScript estivessem todas em um único arquivo, levaria bem mais tempo para fazer parsing e executar tudo. CSS até pode ser empacotado, mas por exemplo o padrão de ter um chunk comum e um chunk por rota pode ser útil. Acho que esse tipo de abordagem, ou algo parecido, vai continuar sendo amplamente usado

• Não dá para ler essa página
  E se você odeia o GitHub, é só não usar. Me impressiona que as pessoas tenham tempo para juntar uma lista de reclamações tão longa. Ou estão sendo pagas para usar, ou então é só usar outra coisa