DETRÁS DEL FEED - ¿Sacan las redes sociales lo peor de los adolescentes?

[Música] HipsterSpot.deck [Música] O podcast de tecnologia e outras modigas! [Música] Olá, Carismo Vídeo! Seja muito bem-vinda mais um episódio do seu podcast favorito. Meu nome é Paulo Subeira, esse é o HipsterSpot.deck. E hoje a gente vai falar de desenvolvimento react, né? Se mundo moderno e também nesse espaço agêntico. A gente tem hoje em dia. Então vamos lá, podcast, ver com quem a gente vai conversar. [Música] Para esse papo de hoje eu estou aqui com o António Valdu. E ele que é Frontender, Frontender de Developers. Aqui na Lura, tudo bom, António? Tudo bem, Paulo, se, como está? Tudo bom, também. Junto com António, eu estou com um dev full stack, que é o Caio Cabral, que trabalha na knife call. Tudo bem com você, Caio? Tudo ótimo, Paulo, um prazer tá aqui. Oi, vocês? Oi, resolvem-te. E o nosso corroosti, que teve uma palestra recém-provada na Alemanha, sobre o evento de react, hein? Vine, neve, isso fala, vine. É, Paulo, tudo bem, olha, eu estou meio pra falar que o react não morreu. Não vai morrer dessa vez, a Paulo não vai ser, o react está morrendo. É, eu acho que o desafio da gente conversar de react no. Quase de 2027, todo espaço mesmo que o Frontend foi capturado pela IA, correto. Acho que isso é, pra todo mundo, então, tarefas muito específicas, bem contextualizadas, bem definidas, com bastante constraints. É, prato cheio pra IA, né? Então, a partir do momento que você fala, olha, eu quero um pixel aqui, pra lá que, quando a rasta clica, acessa lá e chama esse, coisa aqui no back end, é, realmente, não tem muito onde inventar, né? Então, é uma sequência de chamadas e de callbacks e triggers que você tem que amarrar. Bastante, eu não vou chamar de óbvias, mas, assim, normalmente, está dentro de um padrão, bem claro. Então, hoje, obviamente, estou tropecendo em react no tempo inteiro, porque você está criando alguma coisa, a decisão da IA, pra te apresentar um UIWX, minimamente, interativa, vai ser com o react, até porque ela foi treinada em zilhões de projetos react. Tem todo problema de versão, que eu imagino que vocês vão cair nisso também. Então, eu queria entender, hoje, quando o pessoal vai mexer num sistema, ou criar um sistema que tem muito UIWX, muito botão, muita coisa que responde, onde que aparece o dev que manja de react. A IA já não esconde você no seu trabalho, qual que esse trabalho em conjunto? Eu acho que é um bom ponto pra gente começar, Paulo, porque eu acho que existem cenários e cenários, né? Existem produtos e software que a experiência da pessoa que está usando precisa ser alguma coisa mais, seja porque vai engajar ela no produto ou pra diferenciar ela de outros produtos iguais. Então, a experiência do usuário é algo que importa muito, seja porque se eu demorar muito nessa operação aqui, talvez eu vai desistir, então tem vários cenários. E aí que ainda precisa ter alguém que sabe o que está fazendo. Por quê? Se eu estou fazendo um vibe code aqui, pra gerar um app, pra padaria do seu manual, que tem 30 pessoas comprando pão, tá tudo bem se ele fica um pouco mais lento e dá um gargalo aqui de renderização. E chamar aqui, de repente eu chamar o meu bequente de dois vezes, a vez de uma. Mas se estou falando de alguma coisa, que eu tenho milhões de usuários, se eu chamar duas vezes, a vez eu chamar um milhão, vou chamar dois milhões, então a gente tá falando aqui de custo de infra. E é uma coisa que facilmente pode acontecer em react. Então, eu acho que existem cenários onde essa pessoa que manja muito de react vai fazer diferença. E eu acho que o ponto, o balanço pra isso, é o qual rica é a experiência. Porque se a gente tá falando de um crude, de um formulário, "Next Next Finish", que eu uso de vez em quando, vai, talvez não vai fazer tanta diferença. Mas, dependendo do que for, vai, sim, nesse sentido de performance, de scalabilidade, como é que isso vai escalar, como é que eu vou continuar adicionando as novas funcionalidades aqui, como é que eu vou garantir que a experiência vai ser sempre a mesma, e eu consigo adicionar aqui vídeos com velocidade, mantendo a mesma experiência, ou seja, alguém que é uma coisa que é fácil de acontecer, em alguns cenários, dependendo muito, tá bem melhor, tá melhorando, mas dependendo muito do modelo e da ferramenta. Às vezes, reaprovei também nos códigos e criar outro componente, aí você gera aquela máxima de, eu tenho dois lugares diferentes, fazendo a mesma coisa, aí seu "Mundo I" no mundo na outra, e a experiência fica diferente, então, eu acho que a grande premissa é essa. Quanto mais rica precisa ser a experiência da pessoa que tá usando, mas, importante, é a presença dos pesadistas aqui. Sim, a gente, nesse momento, o desenvolvimento a gente copur mais triviás, que algumas tarefas possam ser, possam parecer, a gente precisa do requerimento, quais são as especificações que a gente tá trazendo ali. Então, a gente simplesmente tem um design, a gente tem ali um arquivo do Figma, que você pega, vai conectar com a MCP, vai mandar, construir aquilo, no momento ali de revisão, o que você tá passando, qual é a arquitetura que você vai fazer. Você precisa conhecer, para saber se você, onde você vai colocar ali a fronteira entre clientes, servidor, onde aquela requisa está acontecendo, e essas são algumas decisões que, se você, simplesmente deixar para a gente tomar, você vai perdendo um pouco ali o desenho e a arquitetura do seu sistema e do projeto que você trabalha. E exicionando isso, acho que tem dois pontos. Se a gente for falar de decisão, hoje, uma das coisas que eu acho que é uma das decisões mais caras de não reacte e não tem a ver com escrita de código. Então, por exemplo, uma das coisas que hoje aqui vai dictar para onde, e como essa aplicação vai evoluir, esse estado vai ficar, por exemplo, do lado do cliente, do lado servidor. Aqui a gente não tá falando sobre escrita de código, que é o que a gente faz, mas é uma decisão muito importante. Principalmente a gente se vão mudar depois, questiones de infraestrutura. Então, tem várias coisas ao redor aqui, dessa decisão de deixar do lado do cliente, um lado do servidor. E uma outra que ela é mais genérica, mais aguinoscue de backend de frontend, é que, normalmente, o que a gente gera é a média do código que existe na internet, certo? Então, se é a média, ele não vai ser o melhor, vai ser o pior, você tem que ter alguém ali para quando faz sentido fazer que, olha, vai por aqui preferir a esse. Então, acho que esse é o estado da arte hoje. E sem se der um passo para trás, vale falar também de porque a gente tá falando muito de react e ainda de react. Tal como lá, o pessoal mais antigo que nem eu vai lembrar do JQuery, o react pomou conta, né? Então, você tem os alelems hoje, cuspindo o react, justamente porque, verá que ele ouve a galinha, porque muitas aplicações eram estritas em react. Hoje, o modelo, ele sabe escrever o melhor react por causa disso. Nosso não quer dizer que não vai, de repente, aparecer uma outra forma de fazer front end, mas é meio que a língua comum, né, do front end. Então, isso faz muita diferença. E aí, já dentro do nicho, né? Uma coisa também que é muito legal. Tem uma forma de escrever componentes e não escrever do zero, mas usando coisas prontas que foi a metodordia que o Shade CN meio que criou entre aspas, né? Eu aduto que, olha, eu vou te dar aqui uma forma de você trabalhar com design system, só que os componentes não são meus. Eles não são uma caixa preta fechada. Estou te dando aqui uma forma de usar. E o código desse de sutil aqui vai ficar do seu lado, é seu. E quando ele fez isso há um tempo atrás, ele foi feito pra pessoa, né? Pra galera que deve que gostava de ter essa ownership, ou seja, eu sou dono mesmo do que eu estou fazendo, quero ser dono do código. Que é mais ou menos, né? E eu acho que é por isso que é muito. Sai muito o Shade CN hoje em dia. Que é o que a gente gosta, né? Ele sabe, é fácil de prever. Ele tem ali a ownership daquilo. É muito diferente. Deve ter que interagir com uma brilha até que é pronta, que dá um monte de componentes de caixa preta que está amarrado na versão. Na versão tal, existe uma propriedade, não. Outra não tem. É aí uma propriedade foi depreciada e favou da outra. Então, quando você traz isso pra dentro do código, o agente, ele edita e sabe tudo o que está ali. Então, eu acho que é meio que é assim que a gente tá hoje, né? O agente coste de react, porque é o que ele sabe mais fazer, baseado no que era mais utilizado, nem isso vai ser perpetuando. É, eu concordo, inclusive. Eu não usei o Shade CN aqui na lura, a gente tá usando, é, mais é o Radix. Aí tem essas questões que você falou que eu me identificei, que é quando a gente tá usando uma brilha até que é pronta, tem esse problema de. Quero mexer algumas coisas ali no código interno, mas tem essa limitação de ver a brilha até que é pronta, né? Então, imagina que usando o Shade CN vai ter essa parte que é muito legal de você pegar o código que é pronta e adaptar as suas necessidades. E, inclusive, entra muito uma coisa que. E eu já ajude a bastante. Por que não finaliza? das contas AIA, ela é sobre produtividade. Então, tem muitas coisas que a gente talvez não faria antes, porque demaderei muito tempo, demaderei muito recurso, então usando AIA, a gente pode inclusive pegar ali um código pronto e dizer "Ah, adapta aqui pro nosso repositório de uma forma que faz sentido para a gente e vai ficar uma coisa otimizada também". Então, essa é, por exemplo, uma das muitas utilidades que a gente consegue desbloquear com AIA e ter esse ganho aí de produtividade, e o tempo todo, a gente precisa ter a consciência de que só a gente tem o verdadeiro contexto do nosso projeto, da nossa empresa, do nosso negócio. Então, e a nenhuma vai ter tanto contexto enquanto a gente tem. Então, a gente sempre precisa ter isso do nosso lado e orientar bem a AIA, porque faz sentido o nosso negócio. Alguns desses pontos que vocês levantaram, né, em relação a isso de "fica componente diferente, sentos deixa solteir, e ninguém nem revisar nem código, nem experiência, e vai indo", acho que hoje em dia ela é boso, senti para entregar algo funcional e que não está tão simples de quebrar. Acho que é esse o estágio, especialmente fronte, mas vocês colocaram aqui exemplos de problemas que vão aparecendo. Mas eu queria entender que frequência e velocidade isso aparece. O que eu quero dizer com isso? Se você deixar solto o uso do React pela AIA, rapidamente vai dar esses problemas de dois componentes que deveriam ser o mesmo não é, versões diferentes, problemas que vocês citaram, vai cair logo nisso, ou ele ter um mecanismo de compound que aparece um depois de um tempo aparece outro, e aí fica complicado só para entender como que essas redes. Porque eu, por exemplo, tenho, é como todo mundo que não está mais direto, a programação se é acabar se envolvendo mais, porque agora está mais fácil. E eu vejo que o código vai ficando um lixo, dado a demora, para pedir algumas modificações se você fala "putz, mas isso aqui devia ser simples", aí você vai ver que está um macarrão no men.tsx que tem configuração misturada com código, com chamada interna. E às vezes só você fala "por favor, organiza isso de uma maneira não tão estúpida", sabe? É tão grave, às vezes quando fica um macarrão ali, que é curioso hoje em dia, ele ainda começar com o macarrão assim. Então eu queria entender essa velocidade que ela vai perdendo sensibilidade e degenerando. A gente está falando de React, o primeiro momento falei, mais de problemas de performance, ali de Boundary Client Cermutor. Acho que a gente pode falando de o uso de ar no desenvolvimento do fronte, como um todo, a qualidade do código de saída, do código gerado, ele vai depender da maturidade do projeto, enfim, de uma série de elementos quando a gente está falando sobre o desenvolvimento agente, o que vai ser o projeto em que está, o nível de maturidade do código, os harnesses, enfim, skills que você está usando quando você está ali fazendo seu prompt. O tipo de problema que eu vejo acontecendo e que acaba escalando isso surge já no, no primeiro TR aberto, se você confiar demais no agente que vai estar em diferentes níveis, né? A gente pode ter problemas de design system, ou seja, você está introduzindo alguma coisa, uma pequena variação dentro do design system que você tinha e aquilo depois, vai se pode ser um problema, enfim, você está crependo o design system, ou você está introduzindo alguma coisa que depois vai ser de mais difícil manutenção, e essa questão de mais difícil manutenção é uma outra coisa que a gente precisa trazer em que medida isso importa ou não, eu acredito bastante que importa, porque, ao fim, ao cabo, agente ainda, a gente tem o human in the loop aceitando as coisas e lendo, então, se a gente confia que só os agentes de entre a gente artificial vão dar manutenção no código, sem que a gente teja lendo e aceitando, a gente ainda está, eu acredito que a gente ainda está ali no fluxo para poder aprovar um PR e para poder entender o que está sendo enviado, se aquilo não está legível, eu acho que dificulta muito essa nossa atuação e a tendência é que do código e da base de código acontecer, então eu vejo muito questões de design system, essa mudança de onde está acontecendo ali o boundary e algumas questões de performance e acho que eles aparecem bem rápido, Paul. E uma coisa também que eu percebo muito, é que antes de aparecer o problema, vem a inconsistença, e porque eu quero dizer isso, né? Se você vai deixando ele no modo vai filhão, que a gente está falando aqui para fazer o nosso bingo aí que o Kai estava falando dos baixidores, o código ele não vai ficar ruim de uma vez, muito provavelmente, não vai ficar ruim de uma vez, não sei se você seja usando um rádio muito ruim com o modelo muito barato, então ele fica inconsistente, se ele está inconsistente, eu passo a ter dois componentes para que tem o mesmo comportamento, então dois componentes botão, dois componentes cards, e aí o mudo acorim no mudo no outro, ou eu corrido o bug não corri no outro, e aí entra o que o Paul estava falando de uma coisa que parece simples, começa a demorar muito, não porque o código não está necessariamente ruim, mas é muito mais pela inconsistença, se você vai deixando a amigo trabalhar sozinha, a inconsistença vai gerando aqui, você foi tabola de neve, de coisas que ficaram cada vez mais lentas, e enfim, ele vai degradar o sistema, que eu acho que é o grande ponto, que a gente vê essa máxima de isso daqui, é uma teração que me parece muito simples, e tem 30 arquivos sendo modificados, sei lá, porque, justamente por causa da inconsistença que gerou isso, se está inconsistente, não existe aquele padrão, não foi nada definido, que é o que o Paul trouxe ali de "olho organiza isso", por exemplo, uma coisa que eu faço quando eu estou nesse "vai decodando alguma coisa", a primeira coisa que eu faço é falar assim "olha, usa a tomic design", que já é um padrão, isso vai ajudar ele a duplicar menos, ou há errar menos, hoje é uma receitinha para separar a componência, isso ajuda a demorar com a consistência chegar. Inclusive, eu tenho uma pesquisa que eu não vou conseguir dar a fonte agora, mas eu posso ir atrás para dar para vocês depois, que foi feito com várias empresas, que retrata exatamente isso que vocês estão falando, que boa parte das empresas pesquisadas, quando começaram a usar aí no seus processos, tiveram seus bugs reduzidos pela metade, mas outra poção das mesmas empresas pesquisadas tiveram os bugs duplicados, então, eu acho que isso diz muito que aí a sozinha não é o que está aumentando de meninos dos bugs, fica bem óbvio, então, trazendo todos esses pontos aqui o venho e o carro trouxeram, é justamente como a gente consegue conduzir aí para se adaptar ao nosso código, inclusive é impossível não falar sobre skills, quando a gente está falando isso, mas a gente pode falar sobre isso já já. Acho que um outro ponto, eu acho que com o boom que a gente teve de ter visto artificial e nos últimos anos, mas assim, o carro muito mais acelerado na minha visão, e esse ano, principalmente, ele desde janeiro, dezembro, talvez já, a gente tem outros stakeholders, enfim, clientes que estão usando e trazendo a quantidade de demanda e de alterações de produto, enfim, isso vai depender de cada empresa como é o modelo de negócio, então você recebe, muitas vezes, já tem ali um design system todo pronto, você já tem ali diversos componentes e o cliente te manda um HTML, olha, eu fiz isso daqui, eu queria isso no meu site, amanhã, pode, e aí você precisa pegar aquilo, e meu senhor, acho que o contexto de agência, isso vai depender de empresa para empresas, mas você está muito mais próximo, esse tipo de demanda, e você precisa transformar aquilo sem passar por todo o processo que a gente tinha antes, eu acho de um time de design, uma equipe ali de produto, que vai pensar se aquilo faz sentido ou não, a gente vai refinar, acho que esse processo está muito mais rápido e muitas vezes, me parece que está com o desenvolvedor front-end, ali que está com o monocólico mesmo, tomando essas decisões, aí a gente já sai um pouco do universo de decisão problema do React, sem um problema mesmo, de cipro-desenvolvimento de software, que as coisas estão embaralhando um pouco mais, não sei se vocês têm essa percepção também. Eu acho que faz bastante sentido, que é um pouco com esses números que o António lembrou, que vai depender tanto de situação, então se a pessoa trouxer assim de qualquer forma, caindo o fluxo de trabalho diferente, acho que tem tanta variável acontecendo hoje, e pensando um pouco que o António colocou logo antes do caio, disso de que algumas empresas estão usando de um jeito, de outro, tem resultados diferentes, então obviamente tem a ver com o ciclo do software, com expertise das pessoas, com a ferramenta de a que está usando, etc. mostra que dá pra usar de um jeito bom, pro React e tal, se você tiver essa consciência de reutilização de código, componentização, chamadas N+1 loopes, acessos, pro backend, de performance, se você tiver essas coisas que você só ganha casca, depois que você trabalha muito tempo de coisas pequeninhas, que você vai entender essas coisas mais que eu vou chamar de arquiteturais, de design e padrões, então a minha pergunta seria, se vocês que usam muito reais, eu estou com três pessoas aqui conhecem bastante direct. Se vocês hoje tivessem que trabalhar com o View ou com a Angular, dado com a A seria muito fácil de evitar todos esses problemas, entende porque vocês tenham o conhecimento de componentização, pode não ter na hora que olhar ali vai ficar num, não sei se isso aqui é comum, não sei se isso aqui é boa prática, mas você vai saber avaliar, se aquilo vai trazer algo muito prejudicial ao projeto, isso vocês vão conseguir dizer com alguma facilidade, ou até se tirar alguma dúvida ali, então logo ficou mais fácil isso de transpor o conhecimento de vocês de um pra outro, dado que a arquitetura geral de front pra back, de chamada de wax, de componentização, de estilo e biblioteca e etc, dado que isso é meio que não é igual, mas os fundamentos anguais, os fundamentos anguais, você trabalhar com fronte, com JavaScript, com navegador ouro, com chamadas remotas, esse fundamento é igual, dado que os detalhes técnicos, a A aponta pra gente copicola e a certa quase que de primeira, é mais fácil? Com certeza, ficaria mais fácil você, por exemplo, migrar pra um projeto que usa uma outra tecnologia aqui e você ainda não tá familiarizado, mas que faz parte do fronte chende, né, porque uma das coisas que a A é muito boa, é com sim passe, e quando você vai se lavar de react pra vio, o que tu não tá sabendo ali, eu acho que 90% ali vai ser sim passe, né, ou então talvez alguns padrões que seja utilizados no vio, que não sejam tão comuns, um react, que aí também pode, já entender ali do código médio que o Vinny falou que existe na web, com certeza vai te ajudar, aí vai te ajudar a aprender e se integrar em um projeto nessa stack que tu não conhece, mas com ressaltas, né, sempre vai ser ser muito importante, eu acho que em um cenário como esse, você tem uma revisão humana de alguém que já trabalha com o vio, por exemplo, há um tempo, né, então acho que os meninos podem dizer esse concordo comigo. Eu concordo mais ou menos, porque assim, na minha experiência, os agentes de código, eles são melhores em react do que eles são em ângulo de vio, justamente fazendo qual beque pro nosso começo, existe mais código em react do que em ângulo de vio. Então, dito isso, existem peculiaridades de cada um deles, né, então por exemplo, do vio, você pode escolher entre composição na API ou aquela outra hora que eu me esqueci o nome, enfim tem duas, duas formas de você escrever componentes em vio, antiga e a nova. - É a opção da API. - A opção da API, que é a gente. - É isso. A composição é mais parecida com o react e a opção não é o jeito antígula. E aí a sua API vai te apresentar uma das duas, mas como é que você vai saber, você vai ter que pesquisar ou vai ter que argumentar, então vai depender do qual o curioso a pessoa que está lhe operando é. Já o ângulo, você tem hoje signos, né, que a alguns anos, sei lá, um, dois anos, sei lá, três anos atrás, não tinha. E aí, ou seja, ele tem mais treinamento, pré-signos do que consignos. E aí, como é que você vai entrar nessas nuances? Então, eu acho que o que fica fácil é igual você sair, por exemplo, do Java, do Gol, né, você vai trazer a sua bagagem, a sua bagagem, vai ser útil, porque você pode argumentar, mas se fosse Java eu faria isso, se fosse react eu faria isso, existe algum jeito de fazer isso de ângulo. Então, acho que isso pode te dar vocabular para você argumentar, mas não necessariamente vai tornar alguma coisa mais fácil ou não, porque a gente ainda está nessa de, de, o código gerado, é, ser não, necessariamente não ser um código ocueio, dependendo da aplicação do produto, né, de novo. Você está falando quantos pessoas vão usar isso, né, a família vai usar isso para sortear ao amigo secreto no Natal. Por que importa, né, mas né, quando a gente está falando de coisa de, de produtos grandes, com muito uso, tudo faz a diferença. Então, eu acho que facilita, sim, com aquele risco de sair ângulo com o sotaque de react, ouviu com o sotaque de react. Eu acho que essa é mais ou menos o que eu tenho visto, pelo menos até agora. Eu não fiz, não cheguei a fazer uma tentativa dessas de migração, mas me parece que seria a barreira inicial que a gente tinha antes que seria você precisar fazer um projeto em um menor envio e vai crescendo aquele, eu acho que você tendo um repositório, tendo um projeto que está bem estruturado com o react, você, talvez, indo em alguns pontos chaves da documentação, fazendo alguma pesquisa, onde assisti dois, frameworks vão, de verdade, frango, bibliotecas, enfim, eu não vou entrar aqui nesse ponto. E trazendo isso, eu acho que seria possível fazer uma migração muito mais rápido do que a gente faria antigamente, uma pessoa sem o conhecimento de viu. Mas, de novo, eu acho que não vi nenhum artigo sobre isso, que eu estou trazendo é coisas que eu tenho lido sobre um projeto grande que migrou de TypeScript para russ usando, ou então, o pessoal que deixou de usar React Native para poder fazer a migração para linguagem nativa, no desenvolvimento mobile, essas coisas todas, que antes elas iam precisar, seria um projeto com algumas sprintes para você conseguir fazer esse tipo de coisa, hoje em dia estão sendo feitos mais rápido, e fora desse mundo do React, que a gente sabe que a alienação tem nada melhor com o React, o ponto que me faz pensar que isso poderia ser relativamente sem maiores problemas é que muitos das bibliotecas de componente elas já têm dentro da documentação de elas, uma binha ali para vir, uma binha para ângulo, uma binha para astro, então talvez bebendo dessas fontes, se você trouxe isso ali para o seu comando, para quando você tiver planejando essa migração, acho que seria fácil. Eu acho que seria mais difícil pensando esse ponto que você trouxe de a alienação de serem mais especialistas em React, se você for começar um projeto do nardo zero com ângulo, e você não tem conhecimento, eu acho que você vai ter, vai estar em maus lançais. Talvez vou agradecer mais a pena você fazer em React depois me criar, enfim, dependendo do seu estoque. E assim, o que estaria em comum entre independentes se a gente está falando aqui de ângulo, viu, não é React, Batman de S, não importa, eu vou pedir para o maco deixar um link aqui embaixo também, que tem uma um que chama Web em que eles faz um relatório sobre erros de acessibilidade. E se você olha para lá, o relatório é muito completo, é muita informação legal. Só que ele traz, por exemplo, acho que 12 informações muito relevantes para quem é frontende. A primeira delas é que a gente estava vindo de 24 para 25, estava caindo os erros de acessibilidade, e agora a gente voltou a subir, porque que estava caindo, porque tem principalmente aqui na Europa, tem reforços legais de aplicação de precisância acessíveis, e porque voltou a subir, porque, de novo, vou fazer o callback. Aí, a média do que está escrito, e porque isso é uma gente se preocupa com a acessibilidade? Essa é a verdade. Então, porque eu estou dizendo isso, porque se você sabe acessibilidade, não importa o que que você vai usar, e isso você vai ter no rau de dizer, porque a gente está falando de HTML. Então, seja o template do ângulo, o Jtrcx do react, o view, você vai ver o HTML ali, e você vai saber dizer, olha, isso aqui deveria ser um outro elemento mais semântico, não usa esse oei-ara que está errado, e oei-ara errado a pior do que não ter. Então, isso a gente consegue portar facilmente entre primeiro óxido, não importa qual. Então, é muito importante ter conhecimento sobre isso. E uma outra, um outro dado interessante, que tem a ver com uma intesse de gigantão, Paulo, que você trouxe, é que a complexidade da página inicial está aumentando. Ou seja, a quantidade de elementos que aparecem na primeira página, está aumentando e quem acessar ali vai ver que o gráfico está mesmo assim, você vê muito, muito a inclinação disso daí. Está fácil de colocar, exato. E os testes de acessibilidade, mesmo o sentido da o Cloud hoje, ele tem que você consegue dar um acesso para ele usar o teu Chrome, usando uma extensão, e tal. Mesmo assim, os testes de acessibilidade, eles não são tão fáceis de inserir em feitos, porque está envolvendo o nitro de tela. Algumas coisas, sim, do tipo, esse contraste de cor aqui está funcionando, isso é uma compra até mais. Agora, a tabulação, foco, interações mais complexas, acessibilidade no geral não é tão simples de testar, principalmente a aplicação grande negada. Então, acho que é um ponto tão muito importante sobre ser especialista em front-end. E aí não vou falar, ser especialista em react, saber como o front-end funciona vai te ajudar nisso, quando apareceriam esses problemas. A questão de acessibilidade, eu trabalhei recentemente numa auditoria de acessibilidade para um site, e você tinha, às vezes, conflito entre os agentes sobre qual padrão era acessível e qual não era, porque, então, a gente precisou dar um passo pro lado, pesquisar e tomar uma decisão não. A gente precisou, esse aqui é o padrão e eu padrão que a gente. a gente entende que é o melhor conta disso disso disso e muitas vezes a sugestão de como consertar, convergia mais um enquadramento dentro da WCAG, que é 2.2, que a gente segue quando está falando de acessibilidade, que eu me surpreendina nas reuniões, a gente falava "Ugur Kage", "Ugur Kage", "Ugur Kage", "Ugur Kage", "Ah, tá, ok, agora eu entendi o que a gente está falando". Então, muitas vezes o enquadramento mudava, então, não existe um consenso, muitas vezes, sobre quais são os padrões mais acessíveis. Então, você precisa de teste com usuário quando possível, o seu público alvo mesmo. Então, acho que isso realmente é um lugar em que as evidentes podem levar a gente numa direção errada dele. E uma outra parada também, porque a gente já falou, tem uma episódio que a gente estava com o soltinho, que a gente falou, um pouquinho disso, que é o Figue 1, né? Porque hoje a gente já tem falado muito de escrever código de uma forma que funciona para o agente, e o agente vai performar bem em semana que ele é código. E agora, quem está tendo que se preocupar com isso também é a galera de design, porque o Figue 1 é meio que o padrão, a grande maioria das empresas hoje, usam o Figue 1 para lealtar, uma ou outra, por motivos colheres ali, usam outros ferramentos, só que não necessariamente você conseguir ver no Figue 1, e parecer agradável ao que você está vendo. Mas você vai ver as camadas ali, um conjunto de prints, não é necessariamente a pessoa não usou a componentização que existe no Figue 1. Então, para a gente conseguir ler o Figue 1 direitinho, o Figue 1 tem que ser pensado já para a gente. Então, a toda parte de Tolkien, e quando eu tô falando Tolkien, são, olha, esses aqui são os espaçamentos que a gente vai usar. Essas aqui são as cores, essa daqui é a tipografia. Então você cria todos esses tokens bem direitinhos e cria os componentes usando esses tokens, e configura o MCP para usar isso, porque tem umas configurações que você tem que fazer, senão ele ignora isso e pode não usar. Então, tem tudo aí uma outra parada, porque uma coisa igual pensava antigamente, senti quando a gente falava de front end, normalmente, você tinha uma pessoa de desenvolvimento que gostava um pouco de UX-Y ou alguém de design que gostava um pouquinho de Web, normalmente, era normalmente isso. E aí agora você me não, juntando tudo isso. Porque essa galera que hoje faz interfaz, mas tem esse pezinho na Web, já consegue gerar um protótipo funcional na velocidade, assim, absurdo, e dar um integrável. Eu já vi casos de uma galera que vai e era o protótipo em React Native usando o Expo, e dar um QR code para a pessoa que abriu um pouco a cartinha de Pandora. Expo é uma forma de você escrever React Native. E aí, o que é que esse Expo faz? Você está a um aplicativo, leu o QR code e através desse QR code, o app que a pessoa prototipola vai aparecer funcionando no seu celular, basicamente, simplificadamente, é isso que faz. E aí você tem essas pessoas criando esses protótipos de alta fidelidade. E aí tomando esse cuidado com o FIG, porque o FIG é bem direitinho, os componentes bem organizados, meio que o trabalho, hoje é muito isso, vamos ser guardiando o design system, porque se ele estiver bem definido, bem especificado, bem tokenizado, muito provavelmente a gente vai estar bem próximo lado Pixel Perfect, que é difícil. O Pixel Perfect usando a gente ainda é difícil. Dele entender as proporções, se está direitinho, que precisava, os passamentos, se estava por algum motivo, lá tem que ser 24 pixels, ele está colocando mais ou menos, porque às vezes ele chuta de médio, depende da. várias coisas que podem influenciar nisso. Então, isso daí é bem legal, não é só a gente que escreve código que tem que se preocupar em fazer coisas pensando em facilitar a vida, a vida entre aspas do agente, a parte de o design também, um FIG uma bem feito, ajuda demais nisso. Uma coisa interessante, você falou, veniu, que tem isso, quando a gente era mais novo, tinha aquela brincadeira do telefone sem fio, né, que um fala uma coisa no vídeo de um, e vai passando o vídeo de outro, até chegar ao resultado final. É muita gente trabalhando no nestes processos de desenvolvimento de software, desde a criação, desde a concepção. Então, um design que está criando alguma coisa no FIG, e, bom, ele está criando 10 telas, e aí você tem ali um padrão sendo seguido, pode ser que, durante aquele. isso já aconteceu comigo, encançado, às vezes, quando a gente pega o firma, você prestando um pouco mais atenção, você vai voltar para o design e falou, olha, eu vi uma inconsistência aqui entre esse ponto e esse ponto, isso, a gente pode usar a gente de GIA para poder pegar esse tipo de coisa, mas a gente precisa apontar na direção certa, a gente precisa chamar atenção para esse tipo de coisa. Então, acho que muitas vezes o que acaba acontecendo é esse telefone sem fio de pequenas inconsistências, pegando esse, esse que você trouxe, vim, que acho que também é um dos pontos essenciais, as pequenas inconsistências que vão acontecendo desde, a cada um dos níveis do projeto, elas vão se somando, acho que aí você torna um problema de fato, né. Nossa, eu me dedifiquei demais quando vocês falaram da questão de que começa desde o FIG, uma ser bem estruturada para ter um bom trabalho com os agentes, né. Falei pra esse demais, inclusive já fica aqui a dica, gente, conversa com o pessoal de design para deixar as vezes bem estruturadinhas, porque isso vai facilitar muito a nossa vida e a doa gente, principalmente, quando, porque eu já trabalhei com FIG mas bem estruturado e os não tão bem estruturados, e quando não é bem estruturado, a gente, o tamanho ali do prompt que a gente manda para aí fica um pouquinho maior. É tipo, olha, tem esse nojo aqui do FIG, uma esse elemento, ele tá aqui, ele interage dessa forma com esse outro, porque, pela estrutura que foi montada no FIG, mandou dar pra perceber exatamente que ele que um tá dentro do outro, na verdade, tá lá como se fosse se lá irmãos, ou então lugares muito distantes, e aí foi isso lá, eu não mando tanto de FIG, mas a gente nunca fez assim um design do zero, mas a gente sabe quanta é estruturado ou não, e aí também sabe disso, quando não está bem estruturado. - Aqueles nomes, né? - O nome da componente frame, frame, frame, frame, e aí enfim, aí é meu Deus, o que é um frame? - É terrível, tipo, o componente que tá dentro do outro, mas tu vai ver a estrutura, não tá? E aí, aí a CP é exatamente nesse ponto de inconsistência, que aí a viagem, ela bota no lugar errado, por exemplo, então a gente percebe isso. [Música] Eu queria chamar atenção de novo que a discussão que a gente acaba tendo, do que que aí vai fazer bem ou mal, ficou realmente no plano de arquitetura boas práticas, performance, design, reaproveitamento. E não se ela consegue, ou se a linha é boa, ou se o componente deveria ser daquele jeito, não é? É realmente um nível acima de uma discussão que costumava mostrar dois anos atrás, e é muito interessante, porque isso dá uma musculatura para a gente desenvolver rápido ou algo assim, né? De desenvolver rápido é codificar rápido para ser, usar melhor os termos. E gera uma barreira para quem tá começando, porque para cair nessa discussão que a gente teve aqui, que a gente não falou um, a gente não falou de um componente, a gente não falou de uma propriedade, a gente não falou de nada, né? Solido, a gente não falou de código. A gente não falou sobre código, né? A gente não se tom código, que costumava aparecer nessas discussões que a gente tinha. Ah, porque se você usar isso e usar aquilo, aí você faz isso, que isso chama aquilo. Isso diminui um pouco, esse tipo de discussão, porque assim isso é bom, ela já sabe, ela faz esse padrão. Só que agora fica difícil porque quem tá começando, como que uma pessoa que tá começando vai poder fazer esses julgamentos que vocês estão fazendo aqui, sobre alguns problemas, que aparecendo se ela nunca teve experiência, descrever um código ruim, um bom, e ver a diferença. É difícil dela julgar o que é bom, o que é ruim de performance, de design, de componentização, de reutilização, se nunca reutilizou, né? É que nem encapsulamento colocar numa função, colocar numa variável com o nome bonito ou feio. Se você nunca fez, fica difícil de você explicar pra uma pessoa, não olha esse nome de variável tá difícil, mas seu amigo ler, se você nunca deu pra um amigo ler, então tem um estágio aí, que é a pergunta de um milhão, das pessoas juniores dos estagiários, que fica esquisito, se a gente deu pra ele escrever react na unha, no JavaScript na unha, ele vai parecer um australupiteco, codificando. Ao mesmo tempo, a gente fala, "Ah, usa aí, aí, nem abre o arquivo, ele nunca vai gerar esse espírito crítico." Como que fica essas pessoas que estão entrando aí na empresa e caindo num gigante arquivo e componentes de sistemas de react? Você fala, "Não, calma, primeiro leio, primeiro escreve na unha, como fica essa dualidade?" Eu acho que esse ponto, Paulo, não mudou muito no sentido de que, se eu tô começando no mundo frontende, eu tenho que saber o fundamento, certo? A primeira coisa que vocês precisam entender é como que a web funciona, entre eu abrir um navegador, digitar o endereço, ter alguma coisa carregada ali e interagir com aquilo. O que que tá acontecendo por debaixo do esponso, o que que chama o que, qualquer ordem? Não precisa ir conversar, mas entender o que está funcionando, ou seja, eu sei que tem um cliente que faz uma requisição para um servidor que faz alguma coisa e me devolga HTML, CSS, JavaScript, beleza, acho que é o primeiro passo, que leva para a trinca que a gente sempre falou no front-end. Não tem como a gente falar de qualquer fremur que seja, sem a gente saber HTML, CSS e saber de verdade, no sentido de, eu preciso saber se eu estou usando o CSS de forma correta, atual, porque muita gente está preso no CSS antigo, e o CSS hoje faz muita de coisa de forma mais performática, consolidores melhores, com propriedades melhores, então tem que saber mesmo o CSS, o HTML tem que saber por que, a sensibilidade, se você sabe o HTML bem direitinho, sem mântico, qual tag vai a onde, as propriedades dessas tags, principalmente no sentido de, aqui eu coloco uma tag que representa um botão, porque isso vai ser clicável, se eu tenho um link que tem cara de botão, mas ele não é um botão, ele é um link que vai me levar para outro lugar, ele deveria ser um link, então eu preciso de alguma forma indicar isso para o navegador, então tem que saber o HTML direitinho, e por último, para fechar trinco, o JavaScript tem que saber o JavaScript do tempo onde correr, o JavaScript, ele que vai fazer tudo isso funcionando, todo o dinamismo acontecer, as coisas que acontecem ali, de forma ali que a gente chama de UI rica, acho que a gente ainda usa esse termo, então todas essas interações legais que a pessoa pode ter com a aplicação, é o JavaScript que vai fazer, e tem que saber, e por que tem que saber, você vai estar fazendo, você vai tomar um erro, e é a primeira habilidade que você precisa pensar, é o seguinte, eu preciso saber a onde é esse erro, ele é um erro, esse erro é o que, é um elemento errado que está fechado errado, é uma tag errada, então ele está mais perto do HTML, ou esse erro de estilo, eu apliqui um selector, ou use uma coisa CSS que não deveria, ou é um erro de JavaScript, porque a gente ainda passa pelaquela premissa de quem está começando, rucha para o React, aí toma um erro, e a pessoa fica tentando lutar contra aquele erro, e aí React é difícil, e na verdade o erro é porque ela usou um operador, JavaScript em válido, ou é uma parte que não é uma coisa que acontece muito, que é você descruturar um objeto, uma forma de trabalhar com propriedade, que é o que vai para lá para cá, que é JavaScript puro, e fica aquela sensação de, não sou React é muito complicado, você tem que entrar a ver com o React de quanto que está faltando na verdade é a base, então acho que talvez mais do que antes, a base é essencial, como que a Web funciona, HTML, CSS, JavaScript, e aí assim, eu sei aqui como é que isso aqui funciona, eu sei que identificar um erro no console do navegador, aí legal, acho que isso daí independente se vai ser você, como os mais e os aspectos faziam, você vai escrever código porque seus tokens acabaram, ou se você vai ter lá baixa de token, vai maximizar o uso, e vai ser ia, que vai gerar o código, você ainda precisa entender os erros de devagar, ter esse senso crítico de isso aqui, é ok, isso aqui não é ok, então essa base, esse fundamento, ainda precisa estar lá, eu óbvio, usando aí ali um pouco de mais como tutura, talvez ali, não necessariamente como fonte de verdade, talvez a forma de aprender vai ter um pouquinho diferente, mas a base ainda é necessário, nesse lente vem, acho que é bem cura aí, Paulo falou sobre o que a gente faz com essa pessoa que está iniciando, manda escrever, eu acho que, de fato, o ato de digitar, ele não é necessariamente o mais importante, o que eu poderia dizer pra alguém que está começando e que está entrando no mercado, está estudando, é pegar essa base toda que vem e falou isso, realmente você não tem como ter autoria do código, você não tem como ter responsabilização sobre o que está sendo gerado, se você não soubestos fundamentos, claro que você pode ali na hora tentar aprender, se você for um gênio, mas eu recomendo que você vai construindo esses bloquinhos pra você ter uma base sólida pra conseguir entender outros graus de a distração, mas o que eu acho essencial pra alguém que está aprendendo é ali o código, então a forma como você não vai, de fato, digitar ali em unhos textos, effects, talvez não vai cometer os milhares, dizer os que eu, o António, vim e a gente cometeu quando estava aprendendo, vão ser os novos, agora a nova forma de desenvolver, está todo mundo fazendo a esquecer um pouco o estado do nosso mercado, do nosso ilustro agora, mas o que eu acho essencial é que você não aceite só tudo o que está sendo gerado pela IA e sim, leia e você tentar entender o porquê ele código está estruturado assim, como a gente falou aqui durante esse episódio, o código gerado por IA, ali é a média de todo o código gerado, então você vai ter coisas boas e coisas ruins e você pode descordar mesmo você estudando, você pode pensar, olha isso aqui não está tão fácil de ler pra mim, por que isso é feito assim, e você pode ter algum feedback, um feedback loop ali com a IA, pra entender o porquê daquele motivo, talvez valeu em carcorros artigos, valeu artigos, valeu seres humanos falando sobre essas coisas, acho que esses são alguns pontos que pra quem está aprendendo podem ser bastante valiosos, e se vocês puderem quem tiver aprendendo e pra não ficar só nessa conexão com a sua idéia ou com o seu agente favorito, o nome que você gostaria de dar, a coisa de aprender em público ela é muito interessante, então talvez você tirar ali daquela interação e pronto, fiz uma coisa, está entregue, está pronto ali o pastel e acabou, você tentar produzir alguma coisa do que você tirou daquela, daquele projeto que você fez, tentar estrair alguma coisa e escrever para que outros humanos leiam, acho que isso pode ser bastante rico esse topo que eu me faz é frutir muitos sobre como que estava aprendizado dessa área da tecnologia pra quem está entrando agora, porque queiro não, nenhum de nós aqui passou por esse momento de aprender do zero tendo a IA disponível, quando a gente começou a aprender do zero não tinha IA, então a gente aprendeu de uma forma e eu fico me perguntando como é que realmente vai ser para as pessoas que estão aprendendo agora, é uma coisa que a gente não vai ter exatamente como saber, mas tem uma coisa que eu fiquei que eu lembrei quando vocês falavam é que várias professores, de pregnantção, eles diziam para a gente escrever o código no papel, né? e então eu acho que hoje em dia isso talvez seja ainda mais ultrapassado, mas e aí pode ter gente que vai concordar comigo ou não, mas até quando você vai aprender uma tecnologia nova, uma linguagem nova, um fundamento novo, talvez pelo menos uma única vez escrevia aquele código você mesmo, não precisa ser no papel, pode ser digita no mesmo mas eu acho que aí você pode atrasar a gente tudo sobre como, uma mente, se relacionar com esses atos, né tipo, escrever é mais demorado, muito mais demorado do que gerar o código com IA e queiro não vai fixar melhor na sua cabeça, você vai escrever todo o código na mão? não, porque a gente sabe que hoje em dia o desenvolvimento não está mais assim, mas se você vai aprender uma coisa pela primeira vez, eu acho que seria assim uma recomendação minha, escrava pelo menos uma vez, esse código aqui na mão, para você sentir ele, sabe? vai sentindo ele, vai pegando aqui a vibe dele, e aí conforme você vai se acostumando, eu acho que aí você pode já ir testando também as IAs que queiro não, né? e você em dispensar vai ter para os junios, né? pessoal, tem muita, muita lição aqui em de aprendizado, eu até tinha quecionado o Vinif, a gente vai fazer um episódio de react, a gente vai falar o que? então é interessante, né? porque eu que estou mais por fora, é interessante ver como esse espaço é vivo, e gostei das, das respostas de vocês em relação às pessoas não, não junios, né? as pessoas antes dos junios, que ainda fica na dúvida, porque ela fala "puxa, mas eu estou fazendo meu projeto em react aqui, com a IA" e não tem a menor ideia já é difícil de entender react naquele melecão que é JavaScript, com o componente, com HTML, com uma linguagem que não é JavaScript, eu vou, já é complicado sem IA, com IA, então fica tudo mais misterioso então fica a minha agradecimento a vocês, agradecimento a você ouvinte pelo download, por compartilhar esse episódio, e por responder se você está lendo código produzido no seu front-end, do react, para ver se faz sentido a essa Gororoba ou não e queria lembrar que a gente tem um compromisso na próxima terça-feira, a hipsteres abraços, tchau pessoal, olha só, a gente está quase em novembro, o que significa que está muito pertinho da Black November, da Lura, e também está pertinho de você perder o prazo com as que você não tenha se inscrito ainda, na lista VIP da Lura você pode entrar agora, na lista VIP, passando aqui na descrição do episódio, clicando pra cá e direto, já na página da oferta, porque quem entra na lista VIP, já sai na frente todo mundo vai esperar pela Black November pra abrir, e você vai estar dentro, já, se agora é também oportunidade única de dar o seu próximo passo em tecnologia com uma oferta antecipada, com acesso maior de os contos do ano, antes de todo mundo, com bonos que esgotam bem rápido, inclusive, com bonos, também são benefícios que só vão acontecer uma vez nesse ano, pra que quem está na lista VIP sem segunda chance e também tem um sorteio exclusivo a um MacBook Air. Se você se matricular na lura durante a Black November, então passa aqui na descrição do episódio, entra agora na lista VIP não esquece porque já já acaba o prazo e aí perder né, então a gente tá esperando por você.