Executando verificação de segurança...
7
zeroskullx
4 min de leitura ·

Por que não usarei Next.js

Começo com o Post de @kentcdodds: Why I Won't Use Next.js: "Muita magia - Você já ouviu falar do Princípio da Menor Surpresa?"

Pois bem, Recentemente, o Next.js 14 foi lançado e gostaria de comentar sobre a extensão web fetch API. Essa atualização me fez lembrar do passado, revivendo a forma como eu costumava trabalhar com PHP. Acredito que o Next.js está seguindo por um caminho obscuro ao esticar a função global fetch para adicionar sua própria semântica de cache persistente. Isso realmente viola vários princípios(Consistência, Mínima surpresa e outros). A ideia deles(Next.js) é boa, mas vou adicionar a questão de segurança ao que o Kent escreveu. Estaremos voltando aos velhos 'SQL injections'? Hoje não é possível, mas e amanhã, quando a tecnologia sofrer mudanças? Como o próprio @kentcdodds escreveu, abre aspas - Fazer isso tem impactos negativos no futuro da plataforma web, e também significa que, ao tentar solucionar o motivo pelo qual algo não está funcionando, você terá que vasculhar os recursos disponíveis para encontrar a versão do fetch do Next.js VS a versão do fetch da plataforma web - fecha aspas.

Em relação aos pontos positivos e negativos da extensão Next.js fetch para permitir que cada solicitação no servidor defina sua própria semântica de cache persistente, há várias considerações que eu acho importantes; citarei algumas delas:

Pontos Positivos:

  1. Controle "Granulado" do Cache: A capacidade de definir semânticas de cache específicas para cada solicitação no servidor oferece um controle preciso sobre como os dados são armazenados em cache. Isso pode ser valioso para otimizar o desempenho e a eficiência, garantindo uma experiência de usuário mais rápida.

  2. Otimização de Desempenho: A capacidade de configurar o cache de acordo com as necessidades de cada solicitação pode levar a um melhor desempenho. Isso pode reduzir a carga do servidor, minimizar a largura de banda e diminuir os tempos de carregamento.

  3. Personalização por Requisição: Essa permite adaptar o comportamento do cache com base nas peculiaridades de cada solicitação, o que pode ser fundamental em casos nos quais diferentes recursos ou páginas têm requisitos de cache distintos.

  4. Flexibilidade no Desenvolvimento: A flexibilidade oferecida pode ser muito útil para os desenvolvedores, permitindo adaptações específicas em diferentes partes de um aplicativo para atender requisitos individuais de cache.

Pontos Negativos:

  1. Complexidade Adicional: Introduzir essa capacidade de definir semânticas de cache específicas para cada solicitação pode aumentar a complexidade do código. Isso pode exigir um entendimento mais profundo do cache e do gerenciamento de solicitações para garantir sua implementação correta.

  2. Possível Sobrecarga de Desenvolvimento: A personalização intensiva do cache por solicitação pode resultar em um aumento na carga de trabalho para o desenvolvimento, pois cada solicitação pode exigir considerações adicionais de cache.

  3. Potencial para Erros e Problemas de Debugging: A capacidade de definir semânticas de cache individualmente pode introduzir possíveis erros e desafios de debugging, especialmente em cenários nos quais várias configurações de cache são aplicadas em um ambiente complexo.

  4. Possível Sobrecarga do serviço/Servidor: Se não gerenciado adequadamente, configurar o cache individualmente para cada solicitação pode aumentar a carga do servidor, especialmente se forem usadas configurações de cache mais pesadas ou ineficientes.

🤔 Vejo nos pontos negativos aumento de cobrança e ou taxas extras por parte da vercel...

Em resumo, a extensão do Next.js à API nativa Web fetch API tem vantagens significativas em termos de controle e otimização, mas também pode introduzir complexidade e desafios adicionais no desenvolvimento e na manutenção do sistema, especialmente em cenários mais complexos. A aplicação cuidadosa e a compreensão aprofundada de como o cache é gerenciado são essenciais para maximizar os benefícios e minimizar os possíveis problemas.

Por fim, este é um território relativamente novo no universo do Next.js. Quero acreditar sinceramente que isso represente uma mudança positiva e traga benefícios. É importante destacar que Kent é um defensor do Remix. Em resposta, @leeerob também se manifestou e defendeu a feature em questão neste post: Why I'm Using Next.js.

P.S.: Se você não conhece, sugiro pesquisar sobre a problemática biblioteca de JavaScript chamada MooTools. Eu passei por essa infeliz! 🤬

👇Comente aí o que vocês acham, mas sem hater, combinado? That's all folks! Peeeeace!!!

Carregando publicação patrocinada...
8
MthRyan

Quando as práticas são confusas a área vira um museu de grandes novidades.

As vezes me questiono sobre como abandonamos a simplicidade em desenvolvimento web. Quantas camadas adicionamos a nossos softwares? Rodamos um código em uma vm ou runtime, que está em um container, que está em uma máquina virtual em uma máquina real na Califórnia. Se não estiver rodando em um sistema lambda. Isso para não falar das camadas do software, se utiliza JavaScript temos um bundler, um transpiler e sabe se lá Deus o que mais.

Php era simples e cumpria sua função bem: executar um script que recebia inputs e retornava html. Next faz algo similar. O problema está na stack. JavaScript é terrivelmente complicado.

Juro que adoraria ver uma linguagem simples em wasm que faça a mesma coisa que o next. Rodar tanto no back quanto no front. Simples e efeito.

7
mako

👇Comente aí o que vocês acham, mas sem hater, combinado? That's all folks! Peeeeace!!!

Gostei do sem hater, combinado? kkk, hoje em dia para uma parcela da sociedade se o outro pensa diferente, logo é meu inimigo.

Mas sobre o assunto, acho interessante como existe esse embate na comunidade JS, sobre libs/frameworks. Use esse, não, use aquele. Tenho a sensação que às vezes funciona dessa maneira:
"Não gostei do jeito que essa lib/framework trata essa situação. Como resolver isso? Abrir uma issue no github e levar a discussão aos criadores para entender os porque e tentar uma mudança? Não vai gerar muito desgaste. Já sei, vou criar meu proprio framework/lib que reinventa a roda ( continuando redonda ) mas agora com um aro diferente."

Comparando com outras comunidades, isso faz me ver como a comundiade JS pode ser desunida nesse quesito. Não é à toa que tem a brincadeira de. A cada x segundos nasce uma nova LIB JS para resolver um problema que já foi resolvido por outra anteriormente.

Fiz um post aqui ainda ontem sobre o que o pessoal usa para iniciar seus projetos com react. Desde que o CRA ( create react app ) foi extinto, vejo a comunidade indo pra Vite, remix, next e outros. Com uma forte inclinação ao NEXT pelo que pude perceber.

Sinceramente penso que o next, remix e afins são canhões usados para matar uma formiga em grande parte das vezes.

Quanto a questão de trazer interação para junto da view e que faz reviver a época dos anos em que se fazia o mesmo com PHP me faz pensar sobre uma questão que um professor da faculdade sempre dizia. A tecnologia é como a moda. Ela vive em ciclo. E sempre coisas do passado voltam, com algumas diferenças sutis mas fazem te lembrar de tempos passados ( bons ou ruins ).

Particularmente eu ainda gosto de ter as responsabilidades separadas. Continuarei por enquanto construindo apis para tratar toda parte de lógica de negócio e deixando ela o mais longe possível do front-end.

3
zeroskullx
Autor
Autor

"Gostei do sem hater, combinado?"😅 E você está absolutamente correto; nos dias de hoje, é bastante comum essa dinâmica. No fundo, o principal é respeitar opiniões divergentes e seguir em frente!

Concordo novamente com você, compartilho a visão de que a comunidade JS, parecer descentralizada, desorganizada e, infelizmente, marcada por egos inflados. Recentemente, em um grupo de uma grande framework/lib(não sei bem como defini-lo), ao tentar corrigir um erro de configuração e indagar sobre as atualizações das bibliotecas, fui simplesmente banido sem explicação. Isso acaba afastando aqueles que desejam genuinamente oferecer ajuda. Já presenciei situações em que plugins nascem de outros plugins, são ligeiramente modificados e vendidos como a revolução da internet.

Quanto a questão de trazer interação para junto da view, eu também não curto. Para projetos menores, até aprecio o modelo "PHP", mas para projetos mais complexos, acredito que manter cada aspecto separado é mais vantajoso, especialmente para facilitar a manutenção no futuro. O jeito é ver o que a comunidade do Next.js vai fazer com tudo isso. Faço parte de alguns grupos, incluindo o oficial do Next.js, e o que percebo é que há mais memes do que discussões sérias sobre o assunto.

Obrigado, Mako, por participar dessa conversa. Desejo muito sucesso para você e que tenha uma semana incrível!

3
clacerda

Primeiro, é inegável que, ao relembrarmos as práticas antigas do PHP e até mesmo as 'SQL injections', nem tudo era negativo. Por exemplo, a simplicidade e a praticidade do PHP foram justamente o que atraíram muitos desenvolvedores.

Muitas vezes, retornar a essas raízes e "reembrulhá-las" com as melhores práticas modernas pode ser benéfico. Em outras palavras, talvez não estejamos exatamente "regredindo", mas sim, "reaprendendo" a fazer algo de um jeito mais simples.

E é aqui que o Next.js brilha. O que destaco e valorizo tremendamente no Next.js é a sua capacidade de proporcionar uma experiência full stack quase realmente unificada. No desenvolvimento web tradicional, percebemos uma divisão clara entre front-end e back-end, muitas vezes tornando o processo de desenvolvimento fragmentado.

A ideia de ter uma experiência unificada é certamente atraente. O Next.js, de fato, oferece uma combinação poderosa de renderização no cliente e no servidor. Isso é revolucionário, não bom ou ruim. Como você bem pontuou, há muita "magia negra" por trás disso. E, embora esta "magia" possa otimizar o desenvolvimento, também pode esconder detalhes cruciais.

Como qualquer ferramenta poderosa, é vital que os desenvolvedores tenham uma compreensão sólida do fundamentos subadjacentes para usar a ferramenta de maneira eficaz.

O Next.js é, sem dúvida, uma ferramenta incrível, e é animador ver como ele está redefinindo o paradigma do desenvolvimento full stack. A capacidade de relembrar práticas antigas e integrá-las em um contexto moderno é um testemunho da evolução ciclica da tecnologia.

O importante é abordar o Next.js (e qualquer ferramenta, na verdade) com uma mente aberta, buscando sempre aprender e entender seus meandros. Dessa forma, podemos maximizar seus benefícios e minimizar potenciais riscos.

Muito obrigado por provocar esta reflexão! Sucesso em seus projetos e que possamos sempre encontrar equilíbrio entre inovação e práticas tradicionais! 🚀🌟

1
zeroskullx
Autor
Autor

Muito boa sua reflexão! Observar práticas antigas pode revelar aspectos positivos, e você está correto ao dizer "a simplicidade e a praticidade do PHP foram justamente o que atraíram muitos desenvolvedores", e realmente foi isso que me levou ao PHP. Retornar a essas raízes e fundir esses conceitos com as melhores práticas atuais pode ser benéfico, resultando em um tipo de "reaprendizado" para simplificar abordagens modernas.

Ainda que eu tenha um interesse, mesmo não concordando totalmente com a abordagem atual do Next.js, minha discordância reside principalmente nas atualizações e manutenções futuras. É nesse ponto que faço menção à biblioteca MooTools(Eu gostaria de falar mais sobre isso, mas o texto principal ficaria um textão...rs), que fez o que o Next.js está começando a fazer. Por exemplo, pegar uma web API e fazer um "puxadinho" nela. Isso pode funcionar bem hoje, mas e amanhã? Entretanto, paradoxalmente, aprecio o equilíbrio entre o antigo e o moderno, entre conhecimento consolidado e inovação. Considero esse equilíbrio vital para garantir um progresso sólido e seguro no mundo do desenvolvimento de software e do design web.

Obrigado pela sua reflexão. Desejo a você muito sucesso e uma semana incrível! 😇

1
-2