O biome ainda é mais rápido. Mas, olhando só para velocidade, o oxlint da voidzero é ainda mais rápido.

Como o biome é mais conveniente em termos de usabilidade e documentação, a não ser que o ESLint existente fique mais rápido ao mesmo tempo em que se estabiliza com a combinação ESLint + ESLint Stylistic em vez de ESLint + Prettier, essa otimização com multithreading é impressionante, mas acho que um dia ele pode acabar sendo substituído.

Credo;;;;;;;

Interessante.

Isso também é uma boa notícia para o Firefox.
Sem o dinheiro que o Google dá para a Mozilla, nem que seja só para parecer que não é um monopólio, a Mozilla quebraria imediatamente.
Se perder o Chrome, não haverá motivo para continuar pagando.

Parece que ainda não perceberam que o React prejudica a produtividade.

Se o código for muito longo, mas ainda for fácil explicar "o que ele faz", então isso não é dívida.

A questão é que o uso indiscriminado de IA torna isso mais difícil, e por isso se diz que ele gera dívida.

Não foi a comunicação em si que foi invadida, e sim o gateway.
Como os servidores do jogo aumentam e diminuem de acordo com a carga,
o gateway informa no momento do login a qual servidor se conectar.
Hoje em dia dá para obter certificados TLS de graça, então também é possível implementar HTTPS com segurança, certo?

A história provavelmente é que o gateway comprometido aponta para o servidor errado, e esse servidor intercepta todos os dados para realizar um ataque MITM.

O comentário do Hacker News logo abaixo está certíssimo.

"O Next.js tem uma camada de abstração enorme e desnecessária para 99,9999% dos projetos; e, nos poucos casos em que isso realmente seria necessário, acho muito melhor criar uma solução sob medida com componentes de nível mais baixo"

APIs excessivamente complexas sem necessidade, a postura de promover algo instável e incompleto como se fosse production ready, e uma dependência absurda da Vercel que torna difícil até operar de verdade sem usar a Vercel.

Talvez porque eu tenha começado minha carreira na web, mas a web (especialmente o front-end) sempre foi desenvolvida com esse jeitão(?) mesmo haha
Com aquele gostinho de mudar o tempo todo...

O pessoal do lado de JS é meio assim mesmo. Tem um monte de coisas que dizem ser boas, mas todas têm algum probleminha, e as tendências mudam rapidinho conforme a moda...
Pode ser que eu sinta isso por ter trabalhado principalmente com Java, EJB e Struts.

Obrigado.

https://github.com/kelseyhightower/nocode

Superficialmente, a quantidade de linhas de código (LOC) também é importante. Em termos de produtividade, ler e entender uma página é diferente de ler e entender 3 linhas.

Claro, eu também uso .asyncio até cansar em produção, mas não estou tão satisfeito com a experiência de uso atual a ponto de avaliá-la como "estou usando bem"..

O asyncio atual foi projetado tendo o GIL como premissa e, de certa forma, como uma estratégia para contorná-lo, então o GIL não interage diretamente com o asyncio.

Mas, olhando da perspectiva de toda a programação concorrente baseada em asyncio, acho que dizer que o GIL não tem relação com isso acaba soando como algo do tipo: "é Python, então é natural que não dê certo."

Concordo que não dá para esperar que a direção atual do GIL vá se tornar algo que não fique devendo nem quando comparada a “outras alternativas”,
mas dizer que é preciso adotar outras alternativas além do Python não deveria levar a uma linha de argumentação de que não há problema, e sim de que há um problema, não é?

Desta vez, por interesse pessoal, experimentei fazer desenvolvimento web, uma área totalmente sem relação com a área em que eu originalmente desenvolvia. Fiz um fórum com next.js v15 app router... mas sempre que vejo textos assim, parece que perco a vontade de tentar algo novo no lado web. Por que o ecossistema é tão instável assim? Aí, quando surgir outra novidade, vai todo mundo correr em massa para ela, usar um pouco, depois reclamar de novo e procurar outra coisa? Desenvolvimento web realmente deve ser bem difícil.

Poder e dinheiro realmente são a força motriz para manter um projeto.
Não tem como evitar suspirar toda vez que vejo uma página da web que não funciona direito a menos que seja no Chromium.

Sinceramente... provavelmente não existe outra empresa além do Google que conseguiria manter o Chrome mais ou menos nesse nível. Além disso, ainda que não seja no mesmo grau dos semicondutores, o domínio do mercado de navegadores também é algo que os EUA não querem perder.... Acho que, daqui para frente, algum nível de monopólio ainda vai ser tolerado.

Demorei para verificar.
Obrigado pela resposta tão atenciosa!