Creating a new React project?! Watch this video first (new React documentation). 

tbm to achando, mas eu fico na duvida se é viavel ou sou obrigado a ir para o next de cara

@@joao-lucky estou indo no vite, acredito que é muito utilizado ainda e com o tempo e tiver uma base mais solida podemos ir para o next sem pular etapas (não colocar os bois na frente da carroça)

Só tenho receio com os hooks novos, pois lançaram uns novos que eu to tendo dificuldade pra entender bem. Uma pessoa que é MUITO fera e é referência já em React pra aprender conceitos avançados em inglês é o "Jack Herrington: www.youtube.com/@jherr (sério quem souber inglês confira o canal dessa lenda!)

@@alisonhj O Jack é um mostro, recomendo muito também! Sobre os hooks, poderia citar quais esta com dificuldades?

Em algum momento faz full refresh nos seus apps em Next?

Exato

Pelo que vi especificamente do Remix, ele tem a mesma experiência de um SPA(Sem full refresh) e ao mesmo tempo é renderizado no servidor, isso fritou minha cabeça porque não achei que fosse possível um SSR com experiência de "SPA"

angular lib? kkkkkkk vc é mt leigo.

O Material usa Emotion por baixo dos panos então temos que acompanhar o estado da evolução da lib em relação a essas novas atualizações: github.com/emotion-js/emotion/issues/2928

Penso mesmo Welton, as novidades que tornou o React grande, serão as mesmas que irão prendê-lo em na concorrência a novos frameworks como Svelte e Solid.

sempre me pergunto pq a curva de aprendizado do Angular é maior sendo que ele ja te da o café com leite para resolver todos os problemas

n fala bosta, o dart é uma linguagem de programação utilizada pra codificar no flutter, o flutter sim é um framework. o que vocÊ tá dizendo é como se o javascript/react fosse a mesma coisa, mas o next sim é um framework.

@@MarcosAlmeida-pn6sp Calma princeso. Já programei em Dart/Flutter (inclusive dei apoio no desenvolvimento de aplicativo que está na Google play store) e com um pouco da stackJS/TS/React também, então sim, eu sei que o Flutter e NextJs são frameworks. Quis dizer que agora com essa recomendação da comunidade React para utilizar um framework para desenvolver aplicações, vai ficar parecido com o que acontece com a stack Dart/Flutter, onde normalmente se inicia estudando os dois juntos, e principalmente agora, que é possível desenvolver para Web e Desktop com flutter. Interprete melhor as coisas, para não querer vir bancar de sabichão na internet

Acho que a trilha correta é - JS - TS - React - Frameworks

Next, Typescript e Git até o talo mano... depois você vai completando a base! Mas é NextJs na cabeça

E o Nextjs é o framework full stack, não ? Deveríamos estudar back antes de ir p next ?

Se eu fosse vc faria uma engenharia reversa. Aprende Next e depois vem descascando a cebola. Isso tornará teu aprendizado rápido e concentrado em resultados. Infelizmente tamo sem tempo, depois tu destrava os outros requisitos com mais profundidade. Programação se trata de paciência pra resolver problemas que em grande parte das vezes você não sabe resolver, ou só tem uma vaga ideia de como resolver.

@@NathanOnCodes cara acho super errado apesar que o nextjs ser muito bom, mas utilizar base sempre é melhor acostumar com framework quando precisar de algo que referencia ao dom, que não tem no framework ou ele permite ai o bicho pega

Eu acho que vocês estão sendo muito frescos e limitados, da mesma forma que você não precisa aprender HTML pra depois aprender CSS, você também não precisa aprender React pra depois aprender Next, JS é algo a parte, vocês se limitam muito, ai acabam não aprendendo é nada.

Eu aprendi e pratiquei React através do Next. Facilitou muito minha vida e meu aprendizado, hoje eu consigo fazer tudo no react graças ao Next.

além disso, para usar next deve saber um pouco de Nodejs (backend), não só Javascript

@@lucasduarte7558 Não exatamente, eu não tinha experiência nenhuma com node e back. Aprendi tudo fuçando e com a base do javascript.

@@thiagodiniz8224 sim, tambem acho que depende da experiência da pessoa. Estava pensando em uma experiência Junior, no NodeJs não tem window, por exemplo… é importante saber as particularidades Nodejs para usar o SSR, que é o render padrão do Nextjs

O Next possui um compilador próprio que não encaixa com o Vite.

acho muito boa sua colocação criado em um proposito e depois interagindo com vários problema que tinha, mas agora ficou meio politico escolhendo um lado , cara na minha opinião o que precisa em cada projeto e não fala que esse certo .

@@evertonf.costasouza3692 acho justo msm. Querem amarrar a gente, fixando somente uma coisa pra usar. Acho isso perigoso

Fala Elton, acho que você está confundindo um pouco. Quando falamos de SSR no contexto do React não estamos falando de SSR do mesmo contexto de Rails, Laravel, etc... Devemos entender que não é porque fazemos o uso de um mecanismo de renderização como SSR que perdemos a interatividade que o React traz pra uma interface front-end. Fora isso, todos esses avanços estão mirando em performance e diminuir a carga de JavaScript pelo lado do cliente, mas sem perder a flexibilidade de usar uma biblioteca de UI. Quando usamos Rails, por exemplo, o front-end construído pelo servidor perde toda sua interatividade no momento que chega ao cliente, ou seja, não há hidratação, não há possibilidade de recarregar parcialmente partes da tela como é a proposta do Streaming SSR, ou seja, o buraco é bem mais em baixo. Comparar SSR do React com SSR do que conhecemos de anos atrás é um erro comum, mas que devemos evitar.

No Ignite, a partir do segundo projeto, todos usam Next.js

Sim, com certeza

eu uso e continuo no styled-components e tb material-ui acho bem melhor não gostei do tailwindCSS achei muito verboso

Eu uso o styled components TBM, se eu não estiver errado usando o plugin Babel ou pondo no nextjs.cofig você transforma o carregamento da styled components em lado do servidor.

Hoje existem muitas opções variadas de deploy, tanto na Vercel, quanto Cloudflare, Open Next, etc... Não existe mais um vendor lock-in nos frameworks, principalmente nos outros além do Next

Fica tranquilo, o maior desafio é não sofrer com a ansiedade e filtrar bem os estudos pra não sair estudando coisa antes da hora.

Tentei usar styled compoents com next e não consegui de jeito nenhum, você instalou normalmente Ricardo?

O Next possui várias formas de deploy. Se você procura um SPA com Next, pode ter, basta usar o comando "export" do Next e ele vai gerar um projeto muito semelhante ao que criamos com Vite ou create-react-app. Caso você procura utilizar as features do Next de geração estática incremental (ISR) e renderização pelo lado do servidor (SSR), por exemplo, você precisa de um ambiente que suporte Node.js e isso é suficiente pra executar o projeto Next.

Não entendo esse apego todo com a Vercel, na empresa que e trabalho são mais de 80 projetos usando Next.js, todos são hospedados na AWS e nenhum deles deixou de perder alguma funcionalidade por isso, tem gente que acha que só da pra usar Next na Vercel, isso ta muito longe de ser verdade. Queria saber de onde as pessoas tiraram essas conclusões.

@@eumanjodisso2060 amigo, acho que você interpretou a minha pergunta de maneira equivocada. Foi apenas um questionamento de alguém que está tentando entender melhor a situação, e não de alguém que está defendendo um ponto de vista, como por exemplo, o ponto de vista de que o Next não funciona sem a Vercel. Portanto, esse apego ao qual você se referiu não existe nesse caso. Como eu disse, um cliente tem estrutura própria de infra, ou seja, não é Amazon, nem Heroku, nem Vercel, é estrutura própria com equipe própria, um Cluster bem grande onde foram investidos algumas centenas de milhares. Até o próprio GitLab está em estrutura própria interna. Nessa infra-estrutura tem aplicações em Python, Java com Spring, Java com JSF, Wordpress, Node com Express, SPA com Vite, servidores de arquivos, servidores de email, serviço de telefonia VoIP, diversos bancos de dados etc etc etc. Esse tipo de infra própria é bem comum em empresas grandes, instituições financeiras, autarquias e empresas públicas. Voltando a pergunta original, a dúvida foi sobre quais seriam as adequações necessárias para que nenhuma funcionalidade do Next seja perdida mantendo-se o mesmo ambiente. Ou seja, se apenas um servidor Node é suficiente para rodar um projeto feito no Next sem que se perca nenhuma funcionalidade ou se seria necessários usar recursos extras como o terraform, por exemplo.

@@dieegosf Valeu Diego.

Não é o Next, o time do React fez uma nota pra criadores de lib css in js e desencorajou o uso. Os problemas de performance são os principais argumentos para não utilizar.

Infelizmente tenho pouca visibilidade sobre micro front-ends, ainda não vi casos de uso em produção.

Continua sendo uma boa opção sim, mas temos cada vez mais motivos em utilizar um framework como esses no lugar do Vite ou qualquer opção de criação de um projeto React. Porque a ideia do framework é trazer de forma padronizada coisas comuns que temos que lidar no dia-a-dia de projetos React como roteamento, chamadas HTTP, otimização de imagens, carregamento de fontes, estilização, etc...

Pode sim!

Sempre existem vantagens em um e no outro, acho que não existe um melhor e sim preferências e até casos de uso específicos, mas hoje não tem como comparar se teu propósito for achar um emprego com a tecnologia, Next ainda é e vai ser uma opção mais segura por muito tempo.

@@dieegosf obrigado por responder, tmj!

Olha, acho que vale sim, mas recomendo fortemente aos poucos ir migrando pra TS :)

se eu não me engano, se tu não usa module.css tu acaba sempre importando o arquivo css de forma 'global' quando o arquivo JS é chamado (runtime) e quando troca de tela o CSS ainda perpetua. Ou seja, lá no arquivo viewProduct, por exemplo, tu consegue acessar todas as classes da Home. Isso pode dar conflito se tu usa o mesmo nome nas classes em dois arquivos diferentes.

tá repreendido

Estudar backend, mesmo que você tenha preferência por front é importante independente do framework e linguagem. E se tratando de react de qualquer forma você já mexe com um pouco de back, assim como no angular vc precisar de um processamento das informações antes de exibir na tela.

não precisa usar o backend se não quiser

Não, acho que back-end é um plus, mas não necessariamente você vai ter que ter conhecimentos back-end pra desenvolver com o Next.js. O back-end pode ser um projeto totalmente separado.

@@dieegosf Obrigado !

@@The96tiago Eu quero, essa seria a questão, estudar back com node antes ou estudar direto no NextJs, da maneira que é usada lá.

Não, o Next usa por baixo dos panos um compilador em Rust, não faria sentido migrar para usar o ESBuild que é o mecanismo do Vite.

Material usa Emotion então vale acompanhar o estado do Emotion com essas novas atualizações: github.com/emotion-js/emotion/issues/2928

www.rocketseat.com.br/newsletter

Bom dia Patrick, as classes fixas sim, mas tem coisa que não é gerada em build time e sim em runtime. É uma longa discussão e não tô aqui pra defender um ou outro, mas vale ficar de olho nas issues do Github deles: github.com/styled-components/styled-components/issues/3856

@@dieegosf estou muito feliz com todo o aprendizado que a Rocketseat proporciona e fico mais feliz ainda por ser respondido por você fera. Lhe admiro muito. Sucesso 🚀💚. Detalhe da minha resposta anterior foi gerada pelo nosso amigo ChatGPT.

Quando falamos de SSR no contexto do React não estamos falando de SSR do mesmo contexto de Rails, Laravel, etc... Devemos entender que não é porque fazemos o uso de um mecanismo de renderização como SSR que perdemos a interatividade que o React traz pra uma interface front-end. Fora isso, todos esses avanços estão mirando em performance e diminuir a carga de JavaScript pelo lado do cliente, mas sem perder a flexibilidade de usar uma biblioteca de UI. Quando usamos Rails, por exemplo, o front-end construído pelo servidor perde toda sua interatividade no momento que chega ao cliente, ou seja, não há hidratação, não há possibilidade de recarregar parcialmente partes da tela como é a proposta do Streaming SSR, ou seja, o buraco é bem mais em baixo. Comparar SSR do React com SSR do que conhecemos de anos atrás é um erro comum, mas que devemos evitar.

@@dieegosf perfeito. O comentário é mais pra provocar (num bom sentido). Entendo que estamos chegando a um ponto de equilíbrio. "Tudo no server. Não, tudo no client. Devolve para o server. Calma, não tanto..." E assim vai.

​@@dieegosf Não entendo muito essa lógica. A cada ano que passa, os PCs e celulares e a própria internet estão ficando mais rápidos, mais agora estamos cada vez mais voltando para processar tudo no servidor como era nos anos 2000 quando não existia tanto poder de processamento no cliente. Isso é meio contraintuitivo. Trabalho com SPAs de gestão e não vejo muito sentido em usar SSR para isso já que não preciso de SEO e o SPA me entrega um resultado muito mais próximo ao nativo. Sem contar que os SPAs reduzem a carga de processamento e custo com server.

Também estou com essa duvida, eu até manjo de next, porêm comecei um dashboard para uma empresa a algumas semanas atrás somente em vite, sistema interno mesmo, agora fico com essa questão, deveria ter feito com next ou não...

Sim, dash não precisa de SEO

A ideia que eu passo no vídeo e não ver o Next ou Remix como frameworks para adicionar SEO ou SSR em um app React porque você pode usar várias outras funcionalidades do Next que vão te ajudar como otimização de imagens, de fontes, redução do bundle JavaScript para melhorar a performance e por aí vai. Ou seja, na minha opinião, hoje vale a pena usar essas ferramentas independente do tipo de projeto.

Eu comecei meu primeiro projeto com React com Vite para rodar de início em um servidor sem Nodejs, então para mim ainda vai demorar para trabalhar com. Next em produção, pois a empresa aqui está engatinhando ainda no desenvolvimento. Mas acredito que no futuro quando a empresa estiver com uma visão melhor e poder investir eles devem migrar para um Framework e acredito que devem existir muitas nesse mesmo perfil.

jquery.com/

Concordo plenamente, aos poucos os legados vão se arrastando, tomando recursos dispendiosos para migração. Acredito que a sua abordagem seja a mais sustentável no longo prazo, ter um próprio modelo de trabalho e se adaptar as mudanças sem depender inteiramente delas.

Amplify não é a melhor opção de longe. Recomendo dar uma olhada no Open Next (open-next.js.org/) ou usar a Cloudflare caso não queira ir pra Vercel.

O Material UI usa o Emotion por baixo dos panos então vale acompanhar a evolução da biblioteca pra se adaptar a esse novo formato: github.com/emotion-js/emotion/issues/2928