É o novo "PHP dos anos 90”?
ฝัง
- เผยแพร่เมื่อ 10 ก.ย. 2024
- O novo Next.js 14 trouxe muitas melhorias legais mas o que chamou mais a atenção foi um código utilizado em uma demonstração... Esse código fez a comunidade de devs no MUNDO INTEIRO se questionar se era aquilo mesmo que eles estavam vendo... INCLUSIVE NÓS!
📝 𝗟𝗶𝗻𝗸𝘀 𝗖𝗶𝘁𝗮𝗱𝗼𝘀
→ Next.js no Dicionário do Programador: • Next.js (Renderização ...
→ JavaScript no Dicionário do Programador: • JavaScript (A linguage...
🎙️ Compilado Podcast
→ TH-cam: codft.me/canal...
→ Spotify: codft.me/compi...
→ Newsletter: compilado.codi...
🔗 Mais links do Código Fonte TV
→ codigofonte.tv
#NextJS #React #SQL
O código segue o Princípio da Responsabilidade Única . Tem a única responsabilidade de fazer tudo😂.
🤣🤣🤣🤣
😂😂😂😂😂 Pois é
kkkkkkkkkk
Lembrando na epoca que meu html era assim no back end
Cara, é impressionante quanto marketing bem feito da o hype.
puro marketing!
Lembrando na epoca que meu html era assim no back end
Acho que eles colocaram o SQL ali de propósito só pra engajar e gerar treta 😂
Provavelmente! 😂
Isso é a cara da vercel
Só pode
Treta gera muito engajamento 🤣
Amém! Foi nojostálgico! 🤣
Pois é independente da linguagem se o cara não tiver a noção ferra com a nossa vida, eu mesmo ferrei com muita coisa quando tava iniciando no php, sql no html, html salvo no banco e por ai a fundo kkk. Graças a deus me converti a palavra do Clean e SOLID e nunca mais pequei
Ri junto nesse momento do "kkk" kkkkkkkkkkkkkkk
🤣🤣@@rmauto6273
E não tanquei o "Graças a deus me converti" KKKKKKKKKKKK
html salvo no banco de dados? caramba.
@@thomasthemazzerrunner3615 tinha um site que eu mexia que tinha umas listas ul li que eram salvas no banco e quando chamava pelo parâmetro carregava, foi minha experiência, quando vi a primeira vez achei que era normal e taquei-lhe pau a fazer mais algumas assim, até que descobri como seria a melhor forma heuehe muito orgulho disso sqn hahah
Esse vídeo me ativou lembranças de algo terrivelmente engenhoso: Oracle forms. Dados, Regras de negócio e Renderização de formulários debaixo do capô do SGBD (server-side). Na minha opinião e experiência, colocar tantas disciplinas num mesmo código implica em impactos na manutenibilidade do sistema. Talvez isso faça sentido para statups num contexto de entregas mais rápidas e com um time fullstack focado no NextJs. Contudo, sabemos onde esse tipo de abordagem pode dar: sistemas crescem e ficam complexos; e sem os devidos cuidados, a erosão arquitetural e o alto endividamento técnicos são certos. #vemcamisa #vembone #sunguinhacaibemnoveraosim
right tothe point!
Acho que o exemplo está certíssimo.
Deviam subir em produção sexta a tarde também pra mostrar confiança
Kkkkk
como vcs falaram, fiquei chocado com esse exemplo. E o que me incomodou desde a primeira vez que vi foi justamente a questão de separação de responsabilidade, modularização de código e boas práticas. É claro que deu aquele friozinho na barriga da possibilidade de sql injection mas isso era algo que ja imaginei como contornar e também acho que eles não teriam mostrado esse exemplo se fosse um problema real. Porém separar responsabilidades mesmo dentro do front em si já era uma preocupação minha. Desde que trabalho com React (6 anos) soube que era só uma lib para lidar com Renderização/manipulação do DOM. Enquanto que uma aplicação web vai muito além disso. Então eu via que galera trazia muita responsabilidade para os próprios components (chamada de API, regra de negocio sobre entrada e saída de dados, escovação de bit, muita manipulação de estados globais, interações com APIs do browser) e isso tudo gerava uns componentes monstrinhos que eram difícil dar manutenção e quase impossível fazer testes unitários.. E isso feria uma premissa básica do React: "componentes com código mais declarativos e menos imperativo". Por isso mesmo antes de SSR e next, quando só tinhamos o CSR, eu já gostava de separar as coisas no front, criar camadas. Entendo os ganhos do SSR mas acho que devemos aderir esse tipo de mudança com bastante parcimônia e nunca abrir mão da qualidade de código em detrimento de "fazer de forma simples". Convivendo com programadores por anos vejo muito uma tendência a não preocupar tanto com qualidade de código no front e exemplos como esse, ainda mais vindo de uma conferência, pode reforçar essa tendência principalmente para devs em formação, que ainda não tem muita experiência e podem assumir exemplos como esse como uma "boa prática"
ps. sigo vcs a um tempo mas esse é meu primeiro comentário. Gostaria de aproveitar para parabenizar pelo canal e agradecer por trazerem conteúdos muito relevantes e conceitos que as vezes deixamos de lado por querer ir direto pra parte de escrever código.
Reclame também os canais youtube "apaixonados" por React que não param de ensinar essa tecnologia......
Passei anos separando php, html, js e css e aí veio o react misturando tudo... ok ficou mais rápido desenvolver mas o dreamweaver era rapidinho também 😂
kkkk. Verdade
Finalmente alguém falou a verdade
oh Deus, um homem lucido foi encontrado, como aceitaram aquela mistureba de javascript + css + html ??
Se vocês estudarem bem, vão entender como funciona o SPA e as vantagens de usar, não é sobre codar, mas sobre fazer o melhor…
@@felipebaptista3338SPA não está diretamente ligado a um código todo misturado como o do react, isso foi uma escolha deles
O objetivo da Vercel foi sempre criar um framework full-stack (por motivo óbvios de negócios). Esse vai ser o caminho do Nextjs. Cabe ao dev usar a arquitetura que quiser (MVC por exemplo)
se a ideia é essa, que façam direito então, algo como o Rails, com camadas para controllers, models, views, services, etc, separados. E que na hora de criar o projeto, o usuário possa escolher a versão que quer, tipo npx create-next-app nome_do_seu_projeto --full-stack (para tudo) e npx create-next-app nome_do_seu_projeto --front-stack (só para front-end), tornaria a coisa bem mais simplificada
@@reinaldodevisso
@@reinaldodev Concordo plenamente, hoje parece que não tem padrão nenhum, poderia até ter embutido no CLI a criação destas camadas, assim como outros frameworks fazem.
@@_boraprogramar exatamente
pois é, em minhas aplicações não tenho necessidade de cache, vou continuar usando o react com vite e tendo meu backend bonitinho em nestjs
Poderiam trazer alguns exemplos onde se aplicaria isso. Pois pra mim isso é motivo direto pra descartar completamente esse framework.
Estamos em 2023 e me trazem algo que viável a 10 anos atrás.
👏
Gosto da ideia do framework te forçando a fazer certo!
Entendo a necessidade de ser flexível para o business, mas no dia a dia, não tem jeito, se poder fazer, vai ser feito errado!
Sim dependendo do local de trabalho fazem muita merda mesmo depois são sabem porque o custo de desenvolvimento ficou tão alto isto quanto não se abandona o projeto na metade ......
Mas aí a culpa é do desenvolvedor, não do framework. Acho q o framework tem q ser flexível sim, é obrigação do desenvolvedor aplicar as boas práticas.
Separação de responsabilidade. Só vc pensar um pouquinho, será que a responsabilidade de escrever um código direito é do framework ou do dev?
@@kakashihatake8243 Com absoluta certeza, a responsabilidade recai sobre o desenvolvedor. No entanto, é importante mantermos a humildade e reconhecer que ninguém possui conhecimento absoluto. Por vezes, é necessário tempo para lidar com circunstâncias específicas; no entanto, a "empresa/cliente" nem sempre está disposta a esperar. Sob pressão, alguém pode cometer equívocos, o que, embora não justificável, pode ocorrer. Concordo plenamente contigo. Há uma ampla variedade de ferramentas disponíveis para realizar tarefas diversificadas. Contudo, é importante ressaltar que nem todas podem ser aplicadas indiscriminadamente em qualquer situação. Portanto, considero que isso se torna mais uma questão relacionada à gestão empresarial e ao estudo aprofundado de projetos. Em outras palavras a EMPRESA também tem culpa.
Sinceramente, há coisa de uns 15 anos um amigo me sugeriu q eu aprendesse a programar pq eu sempre fui muito curioso e tal. Na época, estudei PHP (acho q era o 4 ou 5) e eu já sabia um pouco de SQL então não demorou muito pra eu fazer umas coisinhas integrando bando de dados e formulários. Mas eu não curtia muito programação - e eu era muito jovem também pra entender q aquilo poderia ser uma carreira, q as coisas q eu curtia fazer necessariamente não teriam futuro, etc - e acabei trabalhando com manutenção, infra e abandonei o barco da programação. De lá pra cá, dei várias voltas e há coisa de uns 2 anos voltei a estudar programação e "reaprendi" tudo já com o padrão MVC (não em PHP, mas em JS), tudo componentizado e em camadas e me parece, sim, que é um retrocesso o que a Vercel está fazendo. No primeiro post que vi sobre esse troço, postei um print de um código dessa minha época "das antigas" (de um crudzinho tosco) e é bizarra a semelhança na "sintaxe" do código (tudo misturado, sem uma estrutura clara e com uma óbvia confusão de responsabilidades.) Não sei qual vai ser o uso dessa tosquice, ou se a desculpa é pra podermos dar um folga pro processamento client side (o q, na minha opinião, não faz sentido, haja visto o poder d processamento q qualquer smartphone tem hj em dia) só sei q eu olho a apresentação desse negócio e me parece uma piada de mal gosto com o tanto que se progrediu em engenharia de software pra se voltar a fazer as coisas d um modo tão amador e q sabidamente tem baixíssima manutenibilidade...
Eu tenho é muita, muita saudade desse tempo!! E do tempo das aplicações delphi, e do ASP. Tudo bem que esse exemplo é extremo, mas inventaram milhões de camadas e historinhas... e coisas que a gente fazia em uma tarde, hoje leva semanas pra fazer! 😢 Mtas vezes sem ver o ganho dessa enorme complexidade. E o tempo pra ficar com a família, e viver, é sequestrado!
Faço de suas palavras as minhas.... Mesmo a mais de 10 anos, eu já separava algumas coisas para facilitar minha vida na hora de uma manutenção, mas nada comparado a tanta "frescura" que nem tem hoje. O que eu gastava 1 semana para desenvolver, hoje eu gasto no mínimo 3 semanas, de tanta "frescura".
No final das contas entendo que as ditas "frescuras" por mim, são apenas para aumentar a segurança, porém no final a segurança vai depender exclusivamente de quem esta codificando...
Em resumo... Saudades dos velhos tempos.
Tá igual quando eu comecei a programar com foco total no PHP pra trazer as tags e Scripts com o SQL injection... Agora que estou focando no React e Node, misericórdia, não. Deixa tudo separado que é mais seguro e mais organizado.
Sobre o separation of concerns eu concordo. View e lógica pra mim deveriam viver em lugares diferentes. A Linguagem Elm tem a arquitetura TEA excelente de separar as ideias de View, Update e Model no front-end, uma pena não ser tão utilizada. (Inclusive talvez seja um tema interessante pro dicionário do programador, quem sabe)
Até hoje eu não entendo pq uma pessoa usa esses framework, complexos, limitados, carrega um mundo nas costas pra fazer as vezes coisas simples... Acho que fiquei velho mesmo, eu uso apenas JS, Node, HTML, CSS ... Isso é suficiente pra conseguir fazer algo rapido, seguro e produtivo.
Projeto minúsculo da pra fazer com Js puro, agora, qualquer coisa q envolva várias partes e uma lógica mais complexa, é basicamente impossível fazer com JS puro sem demorar 5x mais doq demoraria doq se usasse um react, vue ou svelte da vida.
Essas coisas existem pra um propósito, não pq alguem tava entediado e criou um framework/biblioteca
Rápido, seguro e produtivo...humm tem muitos "depende" aí nessas suas afirmações, se o seu projeto for minúsculo realmente não faz sentido mas não tem a menor chance de vc ser produtivo num projeto de médio/grande porte fazendo tudo na mão
@@marcola47até concordo para o uso de um react, vue, angular.
Agr quando se tem framework de framework e a glr passa a adotar por pretexto de "velocidade" sem enxergar outros problemas é complicado
Cara eu faço meus projeto de aprendizagem com java script puro dom. Vou fazer no React puta complicação! Javascript puro vanilla querrySelector nos projetinhos já atende.
Eu imagino que o melhor funcionamento - se for para levar SQL para dentro do NextJS, é usando as routes da pasta app.
Dá para criar uma lib separando a camada de banco com ORM (repositórios), os serviços criados, e o que em tese seriam os controllers, dá para usar a própria camada das routes.
Obs: Isso claro, se não quiser usar um backend separado, afinal o próprio NextJS cria essa camada de servidor que pode ser usado desta forma.
Alias, não é só o pacote do NextJS que está funcionando assim. Se pegar os pacotes do Supabase, por mais que exista uma abstração para leitura e gravação no postgres deles, o funcionamento também pode ser aplicado dessa mesma forma, a diferença é que lá eles estão usando a sdk própria deles ao invés de injetar um sql gigante na página, mas equivale ao uso de um ORM direto no cliente (também com uma camada que tenta impedir sql injection partindo de xss).
Concordo plenamente com as opiniões de vocês. Tivemos coisas muito boas no Next14, mas, vou esperar amadurecer um pouco mais antes de mudar para ele. Vamos ver onde isso vai chegar.
Estava brincando hoje com PHP e os servidores atuais já detectam PHP inserido em HTML, já dão erro e nem aceitam!! Achei interessante!
Tbm peguei o PHP esses dias para dar uma brincada, usando um framework (descente) é praticamente impossível.
Em Java dá pra colocar SQL misturado com HTML também, usando a tecnologia JSP. Não é nada recomendado, apenas para testes ou demonstrações, coisas mais simples.
PHP é melhor que qualquer outra linguagem backend para web. Baixo custo, mais rápido e usa muito menos dependências.
Tive uma idéia que vai resolver esses problemas...
...vou criar um framework Js, vai ficar top...
Kkkkkkk...
como está indo?
saladera de frutas, boa prática misturar tudo kkkk
Eu acho que isso ta mais pra um inicio de uma tendencia de frameworks fullstack, o que sempre existiu, mas agora com uma cara mais de Javascript
Pode ser. Mas geralmente a iniciativa começava do backend ao front, com aquelas linguagens de templates. Parece que next.js está querendo trazer essa possibilidade de um backend não apenas para SSR. Sei lá, meio que parece um retrocesso. Parece a volta do monolitão
@@RobertoMartinsInfosimmmmmm vdd demais isso, e eu acho bem daora na verdade porque a gente consegue dar uma cara mais de front ne!
Parabéns pelo belíssimo conteúdo, o pouco quem sem de programação aprendendo com vcs e outros canais deu perfeitamente pra entender a parte técnica do vídeo. show demais assim fica bem maias fácil o entendimento de um leigo como eu. ❤
Um problema é alguém esquecer alguma configuração de renderização no servidor e por algum tempo o código ficar exposto com as SQLs. Melhor estruturar separado e deixar as requisições num lugar que o servidor Web não publica, ou sem permissões de leitura por outros.
Acabo de lembrar de uma tabela quando iniciei na programação, tinha tudo nela. Kkkkkkkkkkkkkkkk
Uma coisa que o PHP não faz é ficar inventando a roda o tempo todo. Vem os "front-enders" cagarem regras o tempo todo, para daqui pouco tempo voltarem para o que era simples e rodava bem, é tudo um grande hype sem um real benefício.
Depende muito do que você quer fazer, parece que eles querem fazer um framework fullstack, mas escolheram uma forma meio confusa de fazer isso.
A separação entre backend e frontend existe por um motivo, separar o backend em camadas também.
A questão é, devemos estruturar melhor os frameworks ou as técnicas de desenvolvimento devem mudar?
Creio que um MR para uma pessoa experiente já seria o suficiente pra não deixar algo assim passar e só usar se for extremamente necessário.
SQL na interface é imperdoável mesmo... Nem em projeto pequeno. ORMs depende muito. A imensa maioria são bem ruins em termo de custo computacional.
Muito engraçado que a galera cita o PHP nessas coisas (como se fosse o mesmo de 20 anos atrás, onde também era opção do dev fazer isso ou não, nunca foi uma regra. Mesma coisa era com JSP e ASP), só que o Livewire do Laravel está aí para dar um tapa na cara do NextJS e da galera de JS que não sabe o que fala, provando que dá para fazer um framework full-stack e de forma correta, não essa bizarrice apresentada pela Vercel.
O exemplo atendeu ao que foi projetado: criou o hype desejado para essa versão e abriu novas perspectivas para sua potencialidade usando-se tanto de boas e/ou de más práticas de código. Na média, servirá para separar quem programa sistemas complexos de forma eficiente dos que ainda não conseguem além de causar um novo nível de dor-de-cabeça quando se depararem com essa nova geração de gambiarras.
O grande problem desse caso de uso é validação de dados no react? pois existem várias validações ao clicar um botão, checar login, validar se esse insert não vai gerar outros bugs, ou update, ou delete. Criaram uma funcionalidade pra corrigir um problema que não existe porque no desenvolvimento vai gerar varios problemas, ai dentro da funcção tu vai instaciar a arvore de classes inteira para obter objetos dessa alteração?, mesmo em aplicações pequenas misturar front, backend vai gerar um grande monolito componentizado. Se tudo isso está do lado do servidor, de certa forma vai ser apenas juntar o front no back e colocar o programador pra trabalhar EXH.
Creio que para fins didáticos não vem a ser um problema. O problema é mandar isso pra produção. Ai volta o cheque bonito. Mais pra apresentar e colocar em um slide não vejo problema é até bem pratico.
não existe fim didático
Mas não disse que era fã do Php... Antigos espíritos da treta, possibilite a este humilde servo ver o caos gerado por está lacuna, xablau!
😂😂😂ficou bacana, fazia isso no Clipper TB.
era como se fazia na época, o JS começou a pegar força no fim dos anos 90, ja no finalzinho começou e no inicio de 2000 decolou e ai começou os Ajax, XML e ai a possibilidade de separar tudo. Acompanhei todas estas mudanças nos ultimos 25 anos
11:33 hmn... mongoose ganhando mais um tempim de sobrevida kkkkk
Então o next virou um framework que faz tudo? estão forçando a volta do monolito? Tenho uma aplicação front em react com vite e o back em nestjs e funciona muito bem. Só me preocupa o vite parar de suportar o react no futuro.
Já fiz isso no JSP 😂
o pior de tudo é saber e ver que tem muitas empresas gigantesca e milionárias com códigos dai para pior, não vou falar nomes, mas tem muito produto/serviço por ai que é o caos dos códigos e é o amadinho de muitos
podiam fazer um video falando um pouco como voces ganham dinheiro hoje em dai, nao em porcetagem mas seria legal saber se estao empreenendo fora do youtube se tem algum saas por exemplo, se fazem freeela. Tenho interesse
2011 sobreviventes do bananal! HAHAHAHAHAH Somos nós que viemos de antes de 2000
Dei o like por causa do comentário do maninho, muito bom.
next e muito maneiro. amor a primeira vista. porem esse lance de fazer o deploy so na vercel e complicado. moh role para fazer o deploy manual direto na amazon por exemplo.
React sempre foi uma zona, novidade era se organizassem as coisas como no Angular.
kkkkkkkkkkkkkkk esse sql liso no meio do código
eita PHP, você nunca morre ! kkkkk
Acho que o ponto que não foi tocado e que a maioria das pessoas não perceberam é que, tudo bem o exemplo foi ruim, mas que de agora em diante facilita muito mais, a chamada de api’s via server side, trazendo ainda mais segurança, pro sistema de modo geral
Eu também, bati o olho e vi injeção SQL rs
Esse exemplo só mostra o quanto um dev precisa ser experiente para não fazer merda. Existem padrões, siga-os.
Sim queremos vingança zueiras kkkkk !!!!!
anos 90 é sacanagem hein, eu conheci o ajax por volta de 2005 +/- , acho que sem o ajax era diificil separar o código.
A maior solução é, não usar. PHP e ASP sempre puderam, nem por isso os devs usam.
😊 Gostei desse casal da Web TV Brasileira com as fofocas mais quentes do mundo da programação
E como seria o código ideal para este proposto?
Como sou leigo seria legal ver a diferença! ;)
O ideal seria não ter SQL no next.js. Usar ele para front end com SSR. E deixar para outra aplicação uma API.
Por isso que eu amo Svelte
Vi muitas e muitas JSPs com isso... E acredito que ainda tenham várias em produção por aí. kkk Resumindo, acho melhor não.😅
"muita gente não entendeu" entendemos sim kkk
Tudo muda sempre, vai e volta. Na tecnologia não será diferente né....
Livros de ASP e Servlets sempre indicaram fazer códigos assim kkkkkkkkk
SE é possível fazer exatamente como no exemplo, SERÁ feito em grande escala!
Não subestime o "poder" do sobrinho por trás dos home-offices freelances da vida.
--- Um fenda no tecido do DEV foi aberta! 🤣
--- E eles mesmos mostraram como - OMG!!
Eu gosto de abrir o codigo e ver a query logo
4:35 por isso que eu uso shampoo para cabelos cacheados, assim ele já fica hidratado na medida certa! =D~
Discordo de algumas coisas do vídeo.
Primeiro que, o que foi usada não foi uma chamada comum de função, eles usaram template strings que é a forma que eu recomendo se tu for usar pra realizar uma consulta a um banco de dados em uma aplicação, justamente por sua versatilidade e segurança.
Quando você chama a função sem usar os (), o que vai ser passado vai ser uma array de strings como primeiro argumento e as variaveis que tu usou como demais argumentos, ex: console.log`O canal ${channelName} tem ${likeCount} likes nesse vídeo.` seria como usasse console.log(["O canal ", " tem ", " likes nesse vídeo"], chanelName, likeCount);
Assim, basta concatenar os valores com o caráter que o banco de dados aceita como variável (? ou :algo) e fica bem mais fácil de gerenciar.
Essa forma também é usada na orm prisma, que eu acho que seria bem melhor eles terem usado um exemplo usando uma função dessa orm do que um sql direto, contudo, pra mim a intenção foi apenas explicar o que poderia ser feito e obviamente essa função deve ficar em um lugar separado
Então cada vez mais eu me pergunto o que os caminhos do next se difere do “antigo” mvc, ainda mais agora vindo este esquema de server e client component.
CADE A LOJA??, quero comprar o suéter do código fonte!
uso o nextjs mais prefiro o back end rodando separado do front ou seja em uma API externa
No mundo desportivo quem tem o supremo poder de remover a popularidade de um atleta é a mídia, e por mais incriveis forem os outros jogadores não serão conhecidos por que a mídia tem os seus favoritos. (e o quê que isso tem haver com programação ?). No mundo da programação também acontece a mesma coisa, o PHP já esteve no colo da mídia por bastante tempo, mas com o passar dos anos surgiram novas soluções e outras antigas que se atualizaram e a mídia simplesmente tirou o PHP do colo e colocou elas no lugar, tanto que tem gente alegando que o PHP vai morrer mas começou a programar nem faz 2 meses, tudo isso é apenas as prefências da mídia e nada mais. Sou apaixonado pelo PHP mas nunca deixei de abrir mãe para aprender outras soluções do back como Django do Python e o Node do JS.
"Essa parte cacheada pode também ser hidratada" (Cabeleireiros Café, 2023)
🤣🤣🤣🤣🤣🤣
Eu lembro muito de usar PHP e ASP assim, mas a idéia fdoi boa deles.
Em breve a gente já vai poder salvar os nossos server components em .php e o framework já vai vir com o sqlmap instalado nas dependências por padrão.
Isso para mim é um sintoma de um problema maior:
Uma empresa vendendo comodidade sob capacidade de manutenção para devs inexperientes.
Consigo ver um monte de "full-stack" utilizando essas funcionalidades e tornando um sistema que deveria ser simples em uma macarronada.
Bingo!
Caso parecido com o Angular 17, em que, na apresentação desta semana, eles falam várias vezes sobre o objetivo de facilitar o aprendizado do framework por novos devs, etc.
Ai depende, pois acho mais macarronada tem 27 api com 10 camada cada uma e 14 frontend eu acho mais macarronada ainda, um software assim 1 só não mantem, eu ja tive que mecher em microservisos e sei que é um parto, vc configura uma coisa em em tem que replicar pra outros, e ainda adicionar uma mensageria cara para passar os dados de um para outro, o que não ajuda nem no desenvolvimento nem no custo e muito menos no desempenho, ao menos se a empresa tivesse os responsáveis por cada MS sim, mas no meu caso, todos mexiam em todos ai é um parto, o pessoal deixou de pensar simples, criam um infra cheia de lero lero, que custa o olho da cara pra depois tentarem "Otimisar" o software e culpando os devs pq esta cara demais
@@leonardo.martins Acredito que seja mais para ganhar popularidade, bem difícil um app angular virar uma macarronada, isso porque ele tem style guide muito bem definido e já adota alguns design patterns por padrão como Singleton, Decorator, Observable, Provider etc..., e não necessariamente facilitar o aprendizado implique diretamente em quebra de padrões de desenvolvimento. Já o React/Next parecem encorajar má práticas de desenvolvimento, parece ser até proposital!
Fullstasck, não. Full esterco
O importante é funcionar.
Bomba. É bom para um pedacinho simples para apresentar. Quero ver um sistema de muitos módulos, com muitas regras de negócio.
React já me dá uns treco, agora colocar javascript, html e fucking sql numa mesma função é insanidade.
Na real javascript HTML css é tudo frontend. Agora SQL é foda.
É como ver tudo voltar ao que faziam "nossos pais" porém, no contexto, nossos pais são nós mesmos há 10 anos atrás kkkkkkkk
Eu vejo como "o frontend virou zona e precisamos arrumar", aí volta ao que era antes. Agora.... Basta saber usar também, pois fazer c*gada no código dá em qqr linguagem rsrs
Maldade. Trabalho a anos com JAVA, e já vi gente fazer isso no Java tbm. E trabalhei anos com Zend e Laravel PHP e é muito profissional as aplicações.
pra mim isso ainda é melhor que o PHP. Pq o PHP mesmo tu tinha que fazer um POST usando XMLHttpRequest / Form / Ajax pra fazer uma requisição em um outro script (ou no mesmo, depende de como vc estruturou). A diferença é que vc só poem a chamada direto e JA FUNCIONA? Incrível essa nova feature.
Não confio não. Vi um pessoal até colocar C junto nesses códigos aí. Nada contra C, pois é uma das minhas favoritas, mas não imagino as gambiarras que vai sair disso kkk
cada vez q eu vejo essa imagem fico grato pelo claudio do passado ter ido para o backend
Até o pessoal do nocode achou isso bem esquisito.
Fico imaginando os megazords que podem sair disso KKKKKK. Sou backend e me deu calafrios ao ver esse código
Vcs estariam fazendo um vídeo se não tivesse sido esse código cagado? esse foi o objetivo
5:16 ja vi vários sites dividindo os scripts em multiplos pedaço pq ele puro é absurdamente pesado.
Se brincar as pessoas que usavam isso no PHP evoluíram mas ai vieram outras que não acompanharam o caos e fizeram a mesma coisa hahaha
js não é vercel, vercel [nao] é js. jsx nem funciona nativamente no navegador.
Eu amo o React mas é fato que isto foi um passo para traz........
Quando eles mostraram RSC no Next pela primers vez eles fizeram a mesma coisa só que era uma query trazendo dados e deu bafafá, agora foi um “post”.
Será que não foi um código escrito propositalmente para gerar polêmica?
Ou até um exemplo de código do "que não fazer"?
isso ai é a molekada abrindo o bico por não conseguir desenvolver um backend da forma correta ;)
1:28 Saudades php era muito booom. Usei bastante
Pra mim tá de boas, comecei a estudar agora.. hehe
Esse pessoal não se decide, a ideia do SPA era jogar o processamento pro cliente, agora, parece que voltaram nos primórdios da internet e estão refazendo tudo o que ja havia sido feito e pensado kkkkkkkkkkkkkkkkkkkkkk não faz sentido pra mim usar SPA se vai ficar usando o server pra tudo, enfim, esse pessoal precisa voltar e estudar a eviolução do PHP do Asp pra entender que o que eles estao fazendo já era feito antigamente, pra mim estão reinventando a roda. Quando vi aquele SQL no meio do js com html la fiquei tipo "AAAAAAAAHHHHHHHHHGGGGGGRRRR"
Aquele Sql no meio do js com html parece os código que eu faço na faculdade kkkkkkkkkkkk
me assusta menos que uma imagem de codigo java kkkkk
Tem cheiro de gambiarra, cara de gambiarra... mas não é gambiarra Kkkkkk a manutenção disso vai ser um pesadelo. if( )
"Exagerar" para fortalecer uma argumentação ou facilitar o entendimento é uma "figura" de linguagem muito comum.
Trabalho com JSP(sou obrigado) e ele é muito parecido.
Por tanto tempo as empresas vem procurando meios de evitar que os funcionários façam uma colcha de retalhos nos produtos e agora me aparece um recurso contra maré desses.
Dava para abstrair: o que estava sendo mostrado são os recursos para fazer aquilo. Mas só foram usados daquela forma, tudo comprimido, para caber no slide, nada mais.