Latest / Entre Chaves / #265 Como o novo JavaScript simplifica o desenvolvimento web

Transcript

#265 Como o novo JavaScript simplifica o desenvolvimento web · Entre Chaves

0:02
Está começando mais um episódio de entre chaves, o seu podcast
0:06
de desenvolvimento de software? Eu sou o Luiz Fernando, estou
0:10
aqui mais uma vez com vocês e junto de mim como host também
0:13
temos aqui o Dudu. E aí, pessoal, tudo bom?
0:15
Beleza, seu Luiz? E hoje temos aqui 2 ilustres
0:18
convidados e vou pedir para eles aqui se apresentarem
0:21
rapidamente, começando pelo Lucas.
0:23
Oi gente, tudo bem? Eu sou o Lucas, todo mundo
0:26
conhece como o Lucão. Arquiteto na hackers?
0:28
E aqui temos com a nossa. Eu sou Elaine, eu sou da Gaia
0:32
Atlas. Aqui o pessoal me conhece como
0:34
Lana dentro do projeto matswitt. E hoje, pessoal, a gente vai
0:38
trazer aqui um assunto interessante.
0:40
Eu confesso que ao longo do meu tempo de desenvolvimento, eu
0:44
sempre imaginei se essa seria uma discussão que um dia
0:47
chegaria. Nós vamos abordar, né?
0:50
Essa essa minha curiosidade ao longo da conversa.
0:53
Mas eu queria começar aqui, puxando com vocês.
0:56
Né? Que nós vamos falar agora sobre
0:58
a Nova Era do JavaScript? Isso foi muito puxado pelo ES
1:02
2026. Então eu queria, antes da gente
1:05
entrar propriamente no que que é essa Nova Era, no que que é
1:09
realmente de mudança No No JavaScript, que vocês falassem
1:13
com nossos ouvintes que as vezes não estão acostumados, não, não
1:15
sabem muito bem o que que é esse conceito do ES, né?
1:18
O que que é OESEO? Que que isso importa na nossa
1:21
conversa? E aí a gente entra realmente no
1:23
que que são as definições de 2026?
1:25
OES. Ele faz parte do TC 39, que é o
1:29
grupo que assim, super simplificado a história toda que
1:33
define os padrões e em que pé está AO JavaScript e de forma
1:39
estruturada ali desde 2015 para 2016, foi quando eles começaram
1:43
a ter essas cadências anuais de novas features.
1:47
E nós estamos chegando agora na versão 2026 disso.
1:50
E essa versão 2026, Ela Foi meio que finalizada agora recente,
1:54
né? Agora, e nós estamos agora
1:56
gravando esse episódio em março, né?
1:58
Então foi agora recente nesse mês.
2:01
E aí eu queria então Elaine, traz pra gente aqui.
2:04
Por que que está se falando numa Nova Era do JavaScript?
2:08
Que guinada foi essa no S2 1026 que começou esse burburinho?
2:14
Então o JavaScript, ele vem amadurecendo hoje com o maior
2:18
impacto, ele vem resolvendo alguns problemas.
2:21
É pelo menos pra mim é uma dor muito grande sobre Datas, vamos
2:25
vamos parar de sofrer um pouco aí contemporar OE, AI e pelo
2:30
menos pra mim também o importes. Há formas de importar pra parar
2:34
de pesar ali pro cliente rodar o JavaScript no navegador de uma
2:39
forma muito pesada. Então assim, eu acho que pelo
2:41
menos pra mim, pro pro projeto, onde que eu estou é uma grande
2:45
novidade e que vai trazer pra gente muitos benefícios.
2:48
É graças. Falaram, agora a gente vai
2:49
resolver os problemas de Datas. Eu já escuto isso há uns 20
2:52
anos, com toda a linguagem de programação que eu tenho.
2:54
Não é agora esse prêmio que vai resolver aí vai olhar, ainda tem
2:57
uns buracos e vai indo e vai evoluindo.
2:59
Então, mas realmente parece que agora essa mudança no ES 2026,
3:04
parece que ela é bem interessante, porque o.
3:07
Objeto date nativo mesmo realmente não não estava dando
3:10
mais, né? Oo que que foi que mudou No No
3:12
S2 1026 pra essa parte de de, de, de Datas e de importes que
3:16
você falou que vai ajudar o que que isso aí vai efetivamente
3:19
trazer de ganho pra pra quem tá desenvolvendo.
3:21
Conflitente é que hoje ele vai conseguir tratar melhor Datas,
3:25
então pra somar Datas, diminuir Datas, time zone, que sempre foi
3:31
um problema de rodar em servidores diferentes,
3:32
navegadores diferentes, então agora ele vem trazer uma forma.
3:37
Mais única de tratar essas Datas, então deve reduzir aí um
3:40
pouco nos 80% de bugs que a gente tinha sobre Datas.
3:45
E é uma API nova, né? Não é uma refaturação do que já
3:49
existe. Vai mudar ou forma de código?
3:51
Vai mudar a forma de código e vai deixar também um pouco mais
3:54
leve também, porque antes ter que importar algumas bibliotecas
3:57
igual a momentos, era gigante. Dependendo do projeto, era
4:00
difícil incorporar. Então, texto nativo vai diminuir
4:04
também um pouco da complexidade de código.
4:07
Hoje a gente tem uma biblioteca própria do projeto para tratar
4:11
trocentas coisas de data. Então a gente acredita sim, que
4:15
com o tempo vai melhorar um pouco.
4:18
Essa quantidade de código que a gente faz em cima de data.
4:21
EEA provocação que agora, né? Eu queria fazer, que eu fiz no
4:23
começo, né, que eu nunca imaginei que eu fosse, né?
4:27
Que fosse um assunto que eu IA trazer à tona quando falasse em
4:31
JavaScript. É que uma das coisas que tem se
4:33
falado é que a era do JavaScript, do a era do
4:37
framework por semana acabou. Então o que que aconteceu?
4:41
O contador foi overflow atingir o máximo possível de, né?
4:44
Estourou o número de do contador de.
4:46
De. De frameur de lá não cabe mais o
4:49
npm. Nunca mais é tipo assim AA web
4:51
saturou, né? Porque é isso é uma coisa que eu
4:53
sempre assim achei bizarro, né? No mundo de do JavaScript, era
4:59
AA quantidade de frameurs existentes e muitas vezes assim
5:04
a pessoas. Sou especialista JavaScript, mas
5:07
a pessoa eu sou especialista JavaScript, eu conheço muito o
5:09
JavaScript. Aí eu jogo no projeto angula, aí
5:12
a pessoa tem uma curva de aprendizado de angula, aí eu
5:14
tiro a pessoa do projeto angular e ela cai num de react.
5:17
Aí a pessoa tem um curva de aprendizado de react, aí sai do
5:21
react. E agora assim, não, beleza,
5:23
agora nós vou te colocar num projeto de react native.
5:25
É uma outra curva de aprendizado.
5:27
É o que assim, minha nossa senhora.
5:29
Então, assim, não é? Tudo já o script não, não é?
5:31
Então vamos, vamos discutir um pouquinho sobre esse assunto que
5:34
eu acho que e esse pra mim é é um ponto que eu acho que que que
5:38
né? Começou a ser trazido à tona.
5:40
E isso pode é uma faca de 2 gumes, né?
5:43
Porque isso muda um pouco o paradigma do que o pessoal está
5:46
acostumado com JavaScript. Uma coisa que acho que vale para
5:50
iniciar essa conversa é que no back end a gente tem diversas
5:53
linguagens no front end. Esse não é o caso, né?
5:55
A gente tem apenas JavaScript. Vamos deixar o webs camble de
5:59
lado um pouquinho. Mas basicamente a gente tem o
6:03
JavaScript quando você precisa lidar com web.
6:06
Aí quando a gente lembra que o JavaScript foi construído em 3
6:09
semanas lá em 95, não vou lembrar a história certinho, mas
6:13
foi construído lá por netscape ainda.
6:15
Ele não foi por uma pessoa só, não foi nem por time, foi por
6:19
uma pessoa só fazendo isso. Então ele é extremamente
6:22
opinionado, né? Ele é muito enviesado pelo que o
6:26
criador considerou justo, considerou.
6:28
Aplicava naquela época e meio que cresceu descontrolado.
6:32
É lá no início da internet com os navegadores.
6:35
Sem padronização nenhuma. Cada um fazia da forma o que
6:38
queria, cada um puxava e desenvolver ele pra atender ao
6:41
que precisava. Tanto que só recentemente que a
6:44
gente tem essa igual a gente tava falando TC 39, que a gente
6:47
tem uma organização que ajuda a manter o JavaScript.
6:50
Né? Isso numa época que existiu.
6:51
O vb script é exatamente o antigo internet do do falecido
6:55
internet Explorer, né? Quem?
6:56
Quem, quem não lembra, quem, quem.
6:58
Na verdade, quem lembra do vb script.
7:01
É boa sorte. Hora de tomar aquele remédio
7:03
para dor na. Coluna, então a gente tem essa
7:05
linguagem que ela não é a mais assim.
7:09
É uma linguagem muito robusta, mas ao mesmo tempo é muito
7:12
frágil de que ela tenta cobrir coisa demais, sendo que não
7:16
existe pandronização. Não existe um core central para
7:19
manter a consistência, né? Aí com isso, esses premiworks
7:23
vem para abstrair, essas complexidades, essas esses
7:26
problemas da linguagem. E por isso a gente vem viu aí 11
7:33
framework Java script novo por semana, basicamente ao longo de
7:35
vários. Anos, né?
7:37
Exatamente. E é engraçado, porque realmente
7:39
a gente passou num por por momentos onde cara, toda hora
7:42
tinha um negócio diferente. Eu tentava resolver um problema
7:45
lá e IA pesquisar, não usar esse frame que aqui, aí você vai,
7:48
você pega, você tenta usar aquilo.
7:49
Aí cada hora IA surgindo alguma coisa, IA mudando the Carey,
7:52
depois foi pro ângulo JS. Aí virou o angula 2, aí tudo e
7:58
veio o react, veio o view, né? O view JS então foi seguindo,
8:03
mas realmente parece que de uns tempos para cá, morreu.
8:06
Tipo, é, é esses 3 aí que todo mundo fala, react vie EE angula
8:11
e vamos embora. Tem alguns outros players velhot
8:14
que que tem ganhado um pouco de tração, mas parece que
8:17
estabilizou, né? Não quer dizer que essas
8:19
linguagens também ficaram paradas no tempo, né?
8:21
Tipo assim, elas foram. Evoluindo, né?
8:23
Elas têm ganhado mais funcionalidades, mais coisas.
8:26
Não sei como é que vocês têm visto isso, vocês têm usado ou
8:29
algumas evoluções delas, né? Da na ultimamente, por exemplo,
8:33
react action, hoje tem a questão do server componentes que tem
8:36
evoluído bastante até nesse outro paradigma também legal de
8:39
se de se conversar, né? Sobre desenvolvimento.
8:42
Que é um paradigma complexo, né? Porque o pessoal lá atrás vão
8:48
colocar aí. Década de 2000.
8:50
Tinha a gente tinha basicamente PHP como opção pra web, era
8:54
opção defor pra web, né? Ou asppuro que?
8:56
Era meu caso. Meu caso era asppuro.
9:00
EPHP, eu eu vejo PHP muito próximo de JavaScript, por ter
9:06
essa origem mais aberta, por não ter tipagem forte, por ser é
9:12
dinamicamente e ainda assim de forma fraca na maioria, na maior
9:15
parte das vezes, né? E era tudo misturado, então você
9:19
tinha front back no mesmo lugar. Aí começaram anão, gente, vamos,
9:23
vamos separar o que que é cliente, o que que é server.
9:26
Aí a gente começou a ter, por exemplo, react, que era apenas
9:29
client, outras linguagens que eram apenas é botnet, outras
9:33
linguagens que focavam ali mais Na Na parte do back e agora o
9:38
server componentes começam a misturar de novo isso um
9:40
pouquinho, né? Então existem linhas de
9:43
raciocínio por aí que acham muito bom.
9:46
Simplifica muito código, acho que fica bem mais legível, mais
9:48
fácil para dizer deploy, etcétera e tal, mas que também
9:51
outras argumentos podem ser feitos contrários a isso, de que
9:54
você tá misturando 2 responsabilidades diferentes,
9:57
né? Na verdade, teve 11 artigo que
10:00
eu tava vendo AOA pessoa. Do ponto de vista dela, há uma
10:04
tendência da gente retroceder. E alguns dos dos conceitos, né?
10:09
Da gente sair dessa questão. Do por exemplo, eles não se
10:13
coloca. Claro, nesse artigo, essa pessoa
10:14
se coloca claramente contra o react server.
10:16
Componentes voltando mais a questão da da da EOI mais
10:20
granular. A gente até brincou aqui um dia
10:22
que a gente teve o outro episódio que a gente gravou, eu
10:24
estava lembrando da época que começou o Ajax, né?
10:28
Com o update Painel, aquelas coisas todas, tipo assim, então
10:31
eu tenho. Um bloco ali que tem alguma tem
10:34
algum evento daquele bloco, então eu vou só recarregar
10:36
aquele pequeno bloco. A gente conversou sobre isso
10:38
exatamente no episódio de react server components da questão da
10:41
do carregamento de de uma página inteira de estruturas inteiras,
10:45
né? E uma das tendências que eu vi
10:47
isso pra 2026 é o retorno. Alguns padrões mais
10:52
simplificados antigos foram abandonados.
10:54
Não foi o que eu cheguei a comentar um pouco ali sobre
10:57
alguns importes que vão mudar também, né?
10:59
Hoje você não precisa carregar toda a funcionalidade de um
11:02
botão se você não vai clicar mais naquele botão.
11:04
Então isso pra um usuário que só quer visualizar a tela ali antes
11:07
de aprovar qualquer coisa ou ver como está ali.
11:10
Um relatório vai deixar mais rápido?
11:13
Vai deixar mais intuitivo. É uma das coisas que a gente
11:16
está voltando mesmo, aguardando ansiosamente.
11:18
O processamento da página vai ficar lá no servidor e aí só um
11:21
pedacinho dela que vem pra pra pro browser, pro browser
11:25
terminar de de de fazer, de renderizar.
11:29
Né, só a partir da interatividade, né?
11:31
Onde houve um motivo pelo qual foi criado o Ajax, o David
11:34
penion, né? Porque era uma época que a
11:36
internet era mais lenta e aí o carregamento de tudo ficava
11:39
muito lento, ficava aqueles loading infinito.
11:42
Todo evento que você tinha ficava loading infinito, lá
11:44
morava horror, então criou se esse conceito, e aí nós saímos
11:48
desse conceito e hoje nós estamos voltando a ter o load
11:50
infinito, né? Estamos voltando a ter coisas
11:52
extremamente pesadas o tempo inteiro indo, voltando.
11:54
Então uma das promessas que eu vi.
11:56
É justamente assim, o pessoal quer voltar a essas ideias mais
11:59
simples pra acabar com esse loading infinito, né?
12:02
Eu, eu entendi certo. Isso mesmo.
12:03
Isso aí eu acho que entra muito Na Na questão.
12:06
Voltando a questão do client versus server, né, que é um
12:08
espectro, você pode ter numa ponta tudo client.
12:12
Então você a hora que você acessar o site ou aplicação,
12:15
você vai baixar. 1 t absurda de ave script ele vai processar ali
12:20
no seu browser, talvez pesado ou não, mas vamos pensar assim no
12:22
cenário onde a aplicação está bem feita, então vai ter uma
12:26
performance ok, aceitável ali, mas vai ser tudo clientside.
12:29
Qual que é o problema disso? Tem esses impactos, por exemplo,
12:33
de so que o so vai demorar muito mais tempo para conseguir
12:38
entender aquele site, aquela aplicação, e é indexar fazer o
12:42
que precisa. Então vamos pro outro ponta,
12:45
tudo se é versite. Qual que é a vantagem disso?
12:48
Muito rápido, o CEO bate lá, já entende tudo que sua aplicação
12:52
tem, só que ela não tem interatividade nenhuma.
12:54
Aí começam as as abordagens ali intermediárias, como por
13:00
exemplo, o resumability que o quick tem feito, que é uma
13:05
abordagem que ele só vai buscar o que precisa para fazer a high
13:09
dration daquele JavaScript no front.
13:12
Quando precisa então quando você clica no botão, aí sim que ele
13:15
vai lá buscar tudo que aquele botão precisa para ser
13:18
interativo. Tem os é parshow hydration, que
13:22
O Astro tem feito exatamente para ser mais granular, ao invés
13:27
do que ser como até então é o react, por exemplo, que é uma
13:29
hydration completa, né? Ele adiciona a hydration para
13:33
tudo na sua aplicação, não só ali, de forma como você define
13:37
alguma política de priorização. Esse tipo de coisa, né?
13:40
Então, voltando à pergunta, nenhum dos 2 extremos funciona
13:43
bem? É uma bala de prata que cobre
13:45
tudo, então o pessoal vai tentando encontrar formas ali de
13:50
de encontrar um meio termo, né? Para conseguir você manter
13:54
performance aliada a interatividade.
13:57
E eu acho que isso é interessante porque parece que
14:00
traz uma responsabilidade para o desenvolvedor de saber
14:04
exatamente o que que está acontecendo em cada lugar para
14:07
não fazer. Coisas às vezes desnecessárias,
14:11
igual você vai falar na hora que Oo do quick lá que clicou no
14:14
botão aí que ele vai trazer tudo que o botão precisa.
14:16
Eu não conheço o quick, então posso estar falando alguma
14:18
bobagem em relação a ele. Mas conceitualmente, se você vai
14:21
trazer tudo o que o botão precisa, se você desenvolver de
14:23
uma forma onde você onde o botão vai precisar de muita coisa,
14:27
isso pode trazer um impacto na aplicação, pode trazer uma
14:29
problema de performance. É alguma coisa de problemas de
14:32
de concorrência. Então, tipo assim, saber o que
14:34
que é client, o que que é server, essa separação assim e
14:37
quando usar. Acho que passa a ser uma
14:39
habilidade muito forte pra quem está desenvolvendo o front end
14:42
ali, né? E?
14:43
Isso eu acho que é uma coisa que o next há.
14:46
Há controvérsias, mas que eles fizeram bem, que eles forçaram o
14:50
desenvolvedor a pensar onde que vai rodar a sua aplicação
14:53
através do uso do Youse client e use server, né?
14:57
O desenvolvedor tem tem que saber os impactos e as
14:59
consequências do que o run time e do código dele.
15:03
Vai estar inserido ali para executar da melhor forma, né?
15:07
Então, mas com certeza isso é uma habilidade que os
15:11
envolvedores agora precisam ter. Parar de pensar só apenas em
15:14
client ou parar de pensar em serve e conseguir pensar no mix
15:18
ali dos dos run times e eu acho. Até que no surgimento desses
15:22
surgimento não, mas no fortalecimento desses
15:24
metaframeworks, né? Isso tem se tornado igual.
15:27
Você falou do javascrip ser opinionado.
15:28
Cada um desses metafrêmicos também tem AA forma de lidar e
15:31
como. Trazer o desenvolvimento do do,
15:34
do, do, do frontenne, né? Oo neths com com com O Astro,
15:39
né? O nethex muito amarrado ao
15:41
react, né? O Astro, acho que é mais
15:42
agnótico, né? Aparece de de qual tecnologia
15:45
que você vai usar de para brilhar componentes, né?
15:48
Então eu acho que isso acaba puxando um pouco mais para esse
15:51
lado também, né? Tipo de de, de de de utilizar
15:54
essas ferramentas, desses metafremos.
15:57
Desses metaframeworks, né? Não sei se algum de vocês já
16:00
usou desses assim, tipo, já sabe comparar alguma coisa?
16:04
99% dos projetos de Frontier que eu já atuei aqui e foram com
16:07
react, metade deles ali com next.
16:10
Então eu consigo falar bem sobre a experiência de quem é que
16:12
desenvolver com esses metafremocs, com o próprio react
16:16
e com o next, né? O desenvolvimento em react é, eu
16:20
acho que ele é aquele famoso clichê de que é um
16:23
desenvolvimento muito fácil. A curva de aprendizado é mínima.
16:27
E o que te permite fazer muita besteira também, né?
16:30
Aí vem vários conceitos em cima falando do next, né?
16:35
Que te tentam te direcionar, fazer de uma certa forma.
16:39
Ainda assim, fica muito aberto. Não é tão estrito quanto o
16:44
Anglo, por exemplo, mas já te força a fazer as coisas de uma
16:47
certa maneira. Eu nunca trabalhei num projeto
16:50
em solid. Aqui na dti, mas eu já fiz
16:53
projetos até na época da faculdade, quando ele estava
16:56
muito embrionário ainda, e alguns projetinhos pessoais aqui
16:59
ali ao longo dos últimos anos que o solid ele tem uma, ele tem
17:04
11 conceito completamente diferente do react, que o react
17:07
é todo baseado naquela formulazinha lá do react que o
17:10
seu. A suyuai é uma função do seu
17:13
estado, então você define um estado, aquilo vai direcionar o
17:17
que que o seu yuai está apresentando.
17:20
O solid, ele já não usa esse paradigma, ele segue.
17:24
Ele é completamente baseado em signos, que inclusive é outra
17:28
proposta que eu estou doido para se tornar parte do padrão.
17:32
Mas ele funciona com signos que elimina diversos problemas que o
17:36
react traz, como aquelas renderizações infinitas, toda
17:39
aquela conversa. Acho que tem a própria discussão
17:42
por esse caminho, mas essas 2 abordagens te forçam a pensar.
17:49
Muito especificamente, além da linguagem, porque no fundo, todo
17:53
mundo, os 2 são JavaScript. Os 2 quando eu estou falando de
17:57
react, solid, né? Mas no react você tem que
17:59
preocupar no seu, no seu Reed dependências, quando você está
18:02
usando o Muse effect, que a gente usa demais e muitos
18:05
lugares usam muito mais do que deveria, né?
18:08
Ter o conceito de cojo, ele que ele usa para.
18:10
Isso e enquanto com signos não signos, ele é muito pontual.
18:15
Ele consegue, por trás dos panos, fazer toda a criabilidade
18:18
daquela das mutações que você está sofrendo ali.
18:21
E você não precisa preocupar mais com isso, o que também pode
18:24
esconder problemas, né? Você pode estar fazendo uma
18:26
coisa mal feita e não tem uma renderização 50000 vezes na sua
18:30
tela depois de um clico de botão.
18:32
Te falando isso, né? Agora?
18:33
Uma coisa que você mencionou aí que é é interessante é a questão
18:36
do do do react, né, que ele? Amplamente utilizado.
18:40
E também você mencionou várias, várias pegadinhas, vários pontos
18:45
fracos do do react, né? Uma das coisas que eu já vi
18:48
bastante comentaram a respeito é a questão hoje do
18:52
desenvolvimento assistido por IA, né?
18:54
Porque que que acontece? Todo mundo sabe amplamente que
18:57
AIA é é treinada com o que está disponível por aí na internet.
19:02
Reaction está mais disponível, só está disponível as coisas
19:06
boas e está disponível majoritariamente as coisas
19:11
duvidosas, né? Duvidosas assim, artifícios
19:14
técnicos não estão recomendados sem muitas boas práticas.
19:17
EAA, ela é treinada em cima disso.
19:19
E aí o que que acaba acontecendo?
19:21
Você acaba sendo uma média de tudo que você foi treinado ali e
19:25
muitas vezes a impressão que a gente tem é que tem mais código
19:28
disponível abertamente de qualidade duvidosa.
19:32
Do que realmente os aqueles top códigos?
19:34
Como vocês acham que isso influencia nesse mundo
19:37
JavaScript, no desenvolvimento de frontes?
19:40
Isso fortalece, isso enfraquece. Como é que vocês acham que isso
19:44
impacta OOOO desenvolvimento com JavaScript?
19:47
Eu acho que hoje o deve, ele passa a precisar ter mais
19:52
conhecimentos para conseguir entender o que caia.
19:54
Tá entregando? Para ver se de fato é de
19:57
qualidade ou se atende ali no seu ambiente.
19:59
Eu não trabalho tanto com frameworks, trabalho com
20:01
JavaScript poro. Então eu passo um pouco de
20:04
sufoco com AIA trazendo códigos e trazendo coisas em JavaScript
20:09
que não é aplicável pro meu, pro meu contexto.
20:13
E aí saber filtrar ou abstrair a ideia, melhorar prompts pra
20:19
pegar o melhor código possível hoje faz parte do deve, mas eu
20:24
acho que dá pra gente. Correlacionar AIA com tudo que
20:27
ela traz pra gente, mesmo sendo alguns códigos duvidosos e a
20:31
gente trabalhando, ela, ela traz uma base da internet, mas eu
20:35
consigo treinar ela melhor dentro do meu contexto e aí ela
20:38
fica quase excelente. Mas vocês acham parte do do
20:44
parte do que tem se ampliado nessas, nessas pegadinhas igual
20:48
você mencionou a renderização infinita, questão de baixa
20:51
performance, que são esses problemas com o estado?
20:54
Muito disso que a gente tá vivenciando hoje, isso tem se
20:58
perpetuado por causa do desenvolvimento assistido por
21:00
IA. Ou vocês acham que não,
21:02
independente dele existir ou não é já já é 11 padrão antigo.
21:06
E o pessoal assim, o pessoal não tá muito, tava muito preocupado
21:09
mesmo. Como fazer?
21:11
A gente precisa fazer uma instituição entre Vibe coding e
21:14
desenvolvimento assistido por IA, né?
21:15
Quando a gente tem 11 desenvolvedor de software
21:19
utilizando da IA pra. Acelerar ou enriquecer o
21:23
desenvolvimento dele? É uma situação, outra situação,
21:25
alguém que não está nem aí pro que está sendo cuspido pela EAE
21:29
tá só querendo que faça funcionar, né?
21:32
Esse segundo caso do vib code, com certeza vai alimentar muito
21:36
mais coisas não desejáveis pra os futuros modelos treinarem em
21:41
cima. E a gente tem visto aí diversos
21:45
casos todo dia no LinkedIn, tem algum post diferente sobre?
21:48
Algum Vibe coder que aplicou alguma coisa que apagou?
21:51
11 banco em produção. Mas quando a gente tem um
21:55
engenheiro assistido por IA e ele está utilizando a IA ali na
21:59
forma de uma forma saudável, ele consegue juntar a capacidade
22:04
praticamente infinita da IA de tanto lê código ruim quanto lê
22:08
código bom e principalmente lê documentação, a experiência e o
22:11
conhecimento do desenvolvedor. Então, eu acho que o resultado
22:15
disso aí podem ser códigos que vão evoluir a qualidade média do
22:19
que a gente tem de código hoje. Uhum é muito do que a Elaine
22:22
falou, né? Tipo assim, de saber filtrar
22:24
aquilo ali, de olhar para o que a Oya está fazendo e falar,
22:26
cara, isso aqui se aplica, isso aqui não se aplica.
22:28
E aí o por mais que o JavaScript esteja evoluindo, aí é como é
22:32
que o web a senb entra nisso, né?
22:34
Porque o web, a senb também tenta resolver alguns problemas
22:36
ali do do próprio tipo reformance, algumas coisas que a
22:39
gente tenta executar ali No No. No browser, de forma um pouco um
22:43
pouco melhor do que o JavaScript, mas o JavaScript
22:46
evoluindo assim, essa, essa estabilização dos prêmios, quer
22:49
dizer, essa essa questão do JavaScript está num num num
22:52
local mais Maduro. O que que isso causa para o
22:54
habeas semily? Então o habeas semily ele vem ao
22:58
longo dos últimos anos, aí começando a ganhar uma
23:00
importância maior. Mas eu eu entendo que menor do
23:04
que era todo o hype que tinha em cima de que tudo ficar muito
23:08
mais fácil, rodar mais nível web com o habeas semily.
23:11
Mas com Oo advento da IA acontecendo mundo afora e as
23:16
aplicações, a gente querendo que Ah, eu quero ter um site onde eu
23:20
entro lá, falo 3 palavras Pra Ele, ele cria um vídeo pra mim,
23:23
tem muita coisa ali que pra eu ter essa boa experiência como
23:26
usuário precisa acontecer de forma mais nativa possível.
23:31
Então nem tudo JavaScript consegue dar conta sozinho.
23:34
O próprio figma, eu não sei os detalhes, mas ele utiliza muito
23:37
de orbas semble. Para a parte, toda de
23:39
renderização ali das telas, aquilo ali, se for tudo feito
23:43
apenas via JavaScript, não IA ter a qualidade, a velocidade, a
23:47
performance que tem. É?
23:50
Pois é exatamente. Então com o JavaScript
23:54
evoluindo, eu acho que isso abre, vai diminuir menos a
23:59
distância para utilização de OEA.
24:01
Gente tem falado muito de browser também, mas a gente não
24:03
pode esquecer da importância do JavaScript no back end.
24:06
Ali, no contexto de node, de Bang, do deno e tal, e que esses
24:11
benefícios são independentes do browser ou do Beck, então tem
24:16
muito a se ganhar em muitas facetas diferentes da da
24:20
programação, né? Essas mudanças, essas melhorias
24:23
que a gente tá vendo no S26, elas têm um impacto maior no
24:28
front, no back, ou tanto faz? Eu trabalho muito com JavaScript
24:32
no back, então tá a mim um impacto.
24:35
Back end vai ser muito maior, vai ser mais simples de codar
24:39
algumas coisas de forma nativa, algumas alguns importes de
24:43
bibliotecas EE livres gigantes. Vamos diminuir isso vai me
24:47
deixar o meu projeto mais leve, mais conciso, mais fácil de usar
24:51
pros deves programarem, mas estava e rápido pro cliente.
24:56
Então eu vejo mais vantagem pro back end, que é onde que eu
25:00
estou um pouco mais inserida. Fazendo um pouco do Advogado do
25:04
Diabo, talvez até difícil da gente mensurar, né?
25:06
Você vai ser melhor pra bex, você vai ser melhor pra fronte.
25:09
A partir do momento em que a gente percebe muito o uso dessa
25:12
dessa Fronteira estar se misturando, né?
25:14
Tipo assim, dela da gente fazer muita coisa rodando no servidor,
25:18
né, fazer a página do servidor com o César sajendrin, essas
25:22
coisas todas. O próprio que a gente já falou
25:24
de react server components, né, e tudo essa ideia, né?
25:27
Então acaba que vira quase que uma coisa.
25:29
Só né, digamos assim. Front end, back end, sabe de
25:32
ficar sem ficar separando isso. Às vezes fica fica complicado
25:36
usando essa arquitetura, seja ela boa, seja.
25:38
Ela ruim? E assim, a parte da de Datas do
25:41
jovascript é uma unanimidade, óbvio, todo mundo feliz, tão
25:45
satisfeito. Se cada um de vocês tivesse que
25:47
fazer uma aposta em qual seria a próxima função, a próxima
25:54
funcionalidade do JavaScript. A ser atacada no próximo ES que
25:59
que vocês apostariam? Eu sei que eu vou perder, mas
26:02
não é o que eu apostaria que vai acontecer, mas é o que eu mais
26:05
torço para acontecer, que é assim como o deno e o Ban, tem
26:09
feito, ter suporte no ativo, a tibe script você para escrever
26:13
JavaScript. Para do tirar?
26:15
OTSC da julgada. É o type script se tornar código
26:18
nativo uhum. Nossa, mas aí seria um sonho.
26:21
Seria um sonho, né? Exatamente.
26:22
O node já está, já tem. Experimenta o flag lá que ele
26:25
aceita type notations. Não só não é o type script
26:28
inteiro que ele aceita, mas já é sim uma indicação de que há o
26:32
interesse, né? Nossa, meu sonho.
26:34
Eu vou com a com a proposta ali do colega, viu?
26:36
Sei. Vai com o relator.
26:38
Eu. Vou porque nossa Tape script
26:40
seria o meu sonho. Sair do vanilo lá e ter todo o
26:42
suporte que eu Tape. Script a gente começou a
26:45
trabalhar com Tape script. É lindo poder declarar muitas
26:49
coisas. E 111 coisa.
26:51
Acho que é importante mencionar também o tanto que é importante
26:53
que mesmo havendo o Tape script, como é importante o bom senso na
26:57
hora de você configurar o Tape script?
26:59
Ah, claro, porque há uns há um tempo atrás, há um bom tempo
27:03
atrás. A gente recebeu um código legado
27:05
de um projeto. O projeto era novo para gente,
27:07
mas OOO produto já existia. A gente recebeu o código legado
27:11
em typescrip, já ficamos feliz. Aí lá no começo a gente tava
27:16
fazendo umas implementações e tem uma coisa lá que eu tava
27:19
refaturando especificamente que era para ter dado erro e não deu
27:22
erro de sintaxe. Aí.
27:25
Eu, por que que não deu erro? Eu fui procurar lá no depois de
27:28
uma investigação. Lá no teste config, a
27:31
propriedade strict no checks estava como false no que eu?
27:36
Troquei ela para trum, eu tive que adicionar 1700, que é essa
27:40
expect aro na aplicação, então o type script por si só não faz
27:44
Milagres. A gente tem que saber o que que
27:47
a gente tá fazendo ali com ele, né?
27:49
Configurar qual que é a versão certinho, botar lá OS next.
27:54
Né? Sim, é.
27:55
Você tem que ter saber ali o básico, pelo menos de como
27:59
exatamente ele se aplicar ao seu contexto.
28:01
Exatamente. Se você está fazendo um site ou
28:03
uma coisa, se você está fazendo 11 pacote NPM, outra coisa você
28:06
está fazendo servidor ou outra coisa, então aham, é importante
28:08
ter essa, essa, esse discernismo.
28:10
Exatamente. Então pessoal, muito bacana o
28:12
papo, acho que é muito produtivo.
28:14
Agradeço vocês. Agradeço.
28:15
Elaine, muito obrigado, Lucas. Imagina, bom, tá com o dia de
28:20
novo, Dudu. É isso aí, cara, um abração e
28:22
um. Abraço a todos vocês, nossos
28:23
ouvintes e vocês pessoal, o que que mais chamou atenção em vocês
28:27
no ES 2026? O que que vocês mais aguardam
28:30
para o próximo? Comenta aí, deixa seus
28:32
comentários, deixa suas ideias e sugestões para a gente abração.
28:36
Até a próxima.