Mas nessa sua lógica, a gente poderia só usar nodejs pra responder html nas requisições, desse modo a gente teria todo o html do lado do servidor e os eventos seriam tratados pelo browser. É isso que o PHP faz. A única diferença é que com React vc tem uma estrutura pra isso, sem precisar tratar no lado do cliente .
@@joaovitormachadororato não entendi seu ponto, se for tratar do lado do cliente, vai usar ter javascript no cliente, se não for rodar no cliente, vai rodar no servidor, ou seja, vai fazer o que o PHP faz desde sempre... Server componentes é só os modernets do javascript fazendo o mesmo que criticavam os dinossauros do PHP
@@felipenogueira253 Sim. Foi o que eu disse. O PHP já faz isso, só que sem nenhuma estrutura, é extramemtne feio e ruim pro desenvolvimento. Responder HTML do lado do servidor pode ser feito apenas usando o nodejs também. Vai fazer a mesma coisa que o PHP. Mas vai ficar feio e sem estrutura, não apenas com PHP, mas com javascript no lado do servidor também. O que muda é que o React te oferece uma estrutura de fácil desenvolvimento e manutenção.
Acho massa ter essa funcionalidade agora, porém não acho válido para aplicações em que o formulário precisa de uma validação em tempo real antes de enviar ao servidor, maioria das aplicações que construo usa dessas validações e interações que usam javascript no client, pra uma aplicação interna ou formulários bem simplistas pode ser que seja uma escolha essa abordagem já usada pelo PHP e demais linguagens/frameworks web que constroem aplicativos MVC
@@viniciusgondim6295 só depois que envia ao backend, pense na experiência do usuário com feedbacks mais rápidos e identificação de possíveis erros e problemas antes mesmo de tentar gravar algum dado
@@brandonnunes6322tem como você validar no frontend tbm, basicamente você cria o form como cliente side, e passa a função da actions por props para dentro do form.
A grande maioria dos sites hoje contem js client side. Qual seria o sentido de um usuario desabilitar essa opção no navegador? Se for esse o principal motivo de migrar para server side, na minha opinião nao faz sentido
mas nao faz mesmo. O diego so quis mostrar o seguinte: a aplicação funciona completamente sem precisar carregar javascript no lado do cliente, o que é ótimo. Um grande volume de javascript no lado do cliente pode encarretar em uma aplicação lenta pra renderização, mesmo com internet boa. Então se tudo é respondido pelo servidor e a gente tem a opção das server actions, a gente não precisa mais lidar com eventos em javascript no lado do cliente, pois o próprio html se encarrega de fazer as requisições para as funções listadas no onSubmit, deste modo a gente remove grande parte dos eventos tratados no lado do cliente.
O sentido é vc fazer em aplicações que nao dependem tanto de gestao de state no client. Por exemplo o imasters que é um forum e lá nao tem gestao de dados/state no client . entao da pra fazer mta coisa pelo server side sem deixar de ter o react para funcionalidade. Aqui tbm tem o peso do SEO. Ja para sistemas isso ai mais atrapalha que ajuda.
Que legal que o pessoal tá descobrindo 30 anos depois o que o PHP faz desde sempre 😅
Tenta usar a mesma componentização, reatividade no php, você vai ter uma surpresinha... Nextjs é o melhor dos dois mundos, não é bala de prata claro
Mas nessa sua lógica, a gente poderia só usar nodejs pra responder html nas requisições, desse modo a gente teria todo o html do lado do servidor e os eventos seriam tratados pelo browser. É isso que o PHP faz. A única diferença é que com React vc tem uma estrutura pra isso, sem precisar tratar no lado do cliente .
@@joaovitormachadororato não entendi seu ponto, se for tratar do lado do cliente, vai usar ter javascript no cliente, se não for rodar no cliente, vai rodar no servidor, ou seja, vai fazer o que o PHP faz desde sempre... Server componentes é só os modernets do javascript fazendo o mesmo que criticavam os dinossauros do PHP
@@felipenogueira253 Sim. Foi o que eu disse. O PHP já faz isso, só que sem nenhuma estrutura, é extramemtne feio e ruim pro desenvolvimento. Responder HTML do lado do servidor pode ser feito apenas usando o nodejs também. Vai fazer a mesma coisa que o PHP. Mas vai ficar feio e sem estrutura, não apenas com PHP, mas com javascript no lado do servidor também. O que muda é que o React te oferece uma estrutura de fácil desenvolvimento e manutenção.
@@joaovitormachadororato se o problema é a estrutura "feia" aí o problema não é o PHP, é o programador
Como vou desabilitar os botões, inputs com isloading?
Acho massa ter essa funcionalidade agora, porém não acho válido para aplicações em que o formulário precisa de uma validação em tempo real antes de enviar ao servidor, maioria das aplicações que construo usa dessas validações e interações que usam javascript no client, pra uma aplicação interna ou formulários bem simplistas pode ser que seja uma escolha essa abordagem já usada pelo PHP e demais linguagens/frameworks web que constroem aplicativos MVC
mas continua tendo validações
@@viniciusgondim6295 só depois que envia ao backend, pense na experiência do usuário com feedbacks mais rápidos e identificação de possíveis erros e problemas antes mesmo de tentar gravar algum dado
@@brandonnunes6322 Dá uma pesquisada, tem como sim.
@@brandonnunes6322tem como você validar no frontend tbm, basicamente você cria o form como cliente side, e passa a função da actions por props para dentro do form.
A validação em tempo real ainda continua. É só usar react-hook-form.
E assim quem ganha mesmo é a Vercel. Não sei pq tanta agonia pra mandar o React para server side.
sobe na sua propria vps e pronto uai kk n tem relação nenhuma com a vercel
A grande maioria dos sites hoje contem js client side. Qual seria o sentido de um usuario desabilitar essa opção no navegador? Se for esse o principal motivo de migrar para server side, na minha opinião nao faz sentido
mas nao faz mesmo. O diego so quis mostrar o seguinte: a aplicação funciona completamente sem precisar carregar javascript no lado do cliente, o que é ótimo. Um grande volume de javascript no lado do cliente pode encarretar em uma aplicação lenta pra renderização, mesmo com internet boa. Então se tudo é respondido pelo servidor e a gente tem a opção das server actions, a gente não precisa mais lidar com eventos em javascript no lado do cliente, pois o próprio html se encarrega de fazer as requisições para as funções listadas no onSubmit, deste modo a gente remove grande parte dos eventos tratados no lado do cliente.
@@joaovitormachadororatonão faz sentido nenhum esse exemplo.
@@yuri4dev pq?
O sentido é vc fazer em aplicações que nao dependem tanto de gestao de state no client. Por exemplo o imasters que é um forum e lá nao tem gestao de dados/state no client . entao da pra fazer mta coisa pelo server side sem deixar de ter o react para funcionalidade. Aqui tbm tem o peso do SEO. Ja para sistemas isso ai mais atrapalha que ajuda.
performance. o browser não vai precisar de carregar tanto JS. não será necessário fazer a hidratação do componentes também
Voltando para o PHP kKkKkKkK
Vai ter que por algum javascript no cliente side até pra performance ou UX.
Olha o rollback chegando ai, phpzudo ja fazia isso a decadas e ate aquele Jsp humilde tambem. kk
Legal que agora o pessoal usa Javascript por escolha e não por falta de opção kkkkkk
Eu prefiro usar no client side com as verificações em tempo real
Se o cliente desabilitou o javascript no browser dele foda-se, problema dele não meu.
👏👏👏
Ensinamento fraco, no mercado é diferente