Discordo um pouquinho da sua observação. Velocidade de carregamento está mais re · caiquearaujo

Respondendo a "Vale lembrar que não é um movimento a ser segui..." dentro da publicação

Discordo um pouquinho da sua observação. Velocidade de carregamento está mais relacionado a experiência do usuário e outros fatores do que a quantidade de tráfego. Veja bem que uma das principais razões deles eliminarem o React não é sobre “tempo de download dos bundle”, mas tempo de processamento deles. Isso é bem diferente.

React aumentar o LCP (largest content paint) e o TBT (tempo de bloqueio na renderização inicial) o que pode ser um problema. Pouco tem haver com tráfego, pois tráfego está relacionado ao TTFB (tempo para receber o primeiro byte do servidor). Além disso, isso não é uma estratégia só dos grandes aplicativos, viu?

Hoje em dia, principalmente para empresas que investem bastante em tráfego pago, reduzir o LCP e o TBT é essencial. Isso porque plataformas de anúncios como o Meta Ads ou Google Ads, “punem” landing pages que tem uma velocidade de carregamento baixa. A forma deles punirem é simplesmente forçando a sua empresa a pagar mais pelos lances em anúncios.

Digo isso por experiência própria, uma das minhas especialidades é otimizar a performance para landing pages de anúncios. E a meta é jogar praticamente tudo que der fora. Tailwind, frameworks, etc. Tudo isso é uma porcaria na hora de realizar o processamento em dispositivos móveis. Um bundle de CSS com Tailwind de 30KB pode atrasar o TBT da sua página em 600ms, por exemplo.

Estou dizendo tudo isso para mostrar que (1) decisões assim pouco tem haver com volume de tráfego e (2) essas decisões impactam muito mais na geração de resultados do seu negócio do que muitos desenvolvedores pensam.

Justamente por eu ser bom nesse tipo de coisa tenho um NDA muito forte nos meus contratos, mas um concorrente do meu cliente utiliza React, fizemos o oposto na landing page de anuncio, fiz javascript na unha. Os resultados foram extremamente positivos, ele começou a ganhar lances em cima do concorrente só pela velocidade de carregamento e a landing page não está sequer hospedada nesses lugares de maluco, mas uma VPS de 20 dólares na Vultr com data center em São Paulo. Se fosse pelo tráfego, jamais teríamos feito isso.

uriel

15 dias atrás

Concordo plenamente, o povo usa um monte de traquitana só pq as ferramentas estão em hype de uso.

A pessoa trabalha sozinha com um site de 10 visitas por dia e coloca react só pq alguns usam kkk mas não pensa em Togo o resto que é mais importante

Mirakuru

15 dias atrás

Discordo um pouco de vc. Na maioria dos casos, pelo menos desenvolvedores experientes, vão utilizar frameworks pela a entrega rapida do trabalho, e não por questões ligadas a perfirmance ou outras coisas. A não ser que o projeto exija isso, dai o dev analisa o que é melhor. Pois vcs não devem esquecer aquele velho ditado: Time is Money

uriel

15 dias atrás

vão utilizar frameworks pela a entrega rapida do trabalho

Pelo que eles acham que será mais rápido pra entrega!
Mas um projeto não é só isso!

Se a gente for por na ponta do lapis. JQuery esta em mais de 90% dos sites
React não chega a 4%.

E quase todos os projetos não precisam de React. Pq ele foi feito para grandes esquipes
trabalharem juntas, não para 1 ou 2 quererem entrar no hype pq é legal usar! kkkkk

A não ser que o projeto exija isso, dai o dev analisa o que é melhor.

A maioria não analisa nada. Eles tem um martelo e querem pregar coisas!
Eles tem a solução e procuram o problema, mesmo que não se encaixe bem kkkk

Mirakuru

15 dias atrás

Então! JQuery é uma lib e não Javascript puro. Vc mesmo disse, JQuery está em 90% dos sites. O motivo é que ele traz produtividade e nao porque é hype. Além disso, se vc aprende a trabalhar com libs ou frameworks é muito mais fácil vc concorrer a uma vaga de emprego onde utiliza isso, do que alguém que nunca trabalhou. Então nada melhor do aprender em projetos reais. Desde que não atrase a entrega tá valendo, pois clientes, a unica coisa que se preocupam primeiramente, é com o prazo de entrega. Quanto aos problemas ou benefícios que o uso de uma ou outra tecnologia vai trazer, isso é para a minoria dos projetos, como falei anteriormente

rafael

15 dias atrás

Não há o que discordar sobre JavaScript puro ser melhor do que adicionar um framework nesses casos. Uma landing page pode ter só o básico (HTML + CSS + JS), porque é um site muito simples. React e outros frameworks ajudam mais os desenvolvedores do que os usuários. Até poderíamos argumentar que usar algo além do básico numa landing page é errado.

Mas fiquei curioso com um ponto do seu comentário:

Um bundle de CSS com Tailwind de 30KB pode atrasar o TBT da sua página em 600ms, por exemplo.

O Tailwind não importará todas as classes existentes ao realizar o build, apenas aquelas que você usou. E, por reaproveitar tantas classes, é possível que os arquivos gerados sejam menores com Tailwind do que sem (precisa testar isso na prática, imagino que os resultados variem).

O que aconteceu nesse exemplo de 30KB que você mencionou?

caiquearaujo

Autor

15 dias atrás

Esse foi até um dos casos extremos que resolvi recentemente (cada coisa que chega para mim resolver 😅). Percebo, por esse caso, que o maior problema é que o Tailwind não otimizou a produção de CSS para medias queries (breakpoints), além disso, quando falamos de otimização temos (1) CSS crítico e (2) CSS regular. Aí varia do que cada um vai fazer. No caso desse que otimizei foi: (1) breakpoints em excesso, (2) classes usadas uma única vez sem padronização, (3) uso excessivo de palheta de cores e (4) uso de utilitários como @tailwindcss/typography.

Outro ponto que acho horrível no Tailwind, por exemplo, é a incapacidade de quebrar o bundle em dois ou mais fragmentos. Ele simplemente vai pegar todas as classes utilizadas na aplicação e agrupar tudo. Aí quando você tem um desenvolvedor inexperiente ou, pior ainda, componentes com uma porrada de classe é fácil as coisas sairem do controle.

Além disso, muitos frameworks agrupam o font-face com o CSS do Tailwind produzindo um bundle ainda maior que vai ter que ser carregado pelo browser e processado antes de mostrar ao usuário.

Quando o foco é performance não uso Tailwind ou faço um misto. Gosto da ferramenta, ela facilita muito o trabalho. Geralmente utilizo ela para um mock e depois depois saio convertendo os estilos para classes normais do CSS para montar um bundle de CSS crítico. Assim separo o que é crítico do que pode ser processado depois. Aí vai da experiência de cada um.

O dia que o Tailwind resolver totalmente a questão de separação de bundles vou usar ele por completo.