00:00:00- Então a versão pública final do V+ provavelmente será,
00:00:03vai parecer algo divertido.
00:00:06- Este é Evan Yu.
00:00:07- Evan Yu.
00:00:09- Evan Yu.
00:00:10- Evan Yu!
00:00:10- Eu criei o Vue, criei o Vite.
00:00:14Agora dirijo uma empresa chamada VoidZero.
00:00:16- Qual a diferença entre o Vite e o Vite+?
00:00:19- Sua experiência de desenvolvimento será exatamente
00:00:21como é o Vite hoje.
00:00:22Mas se você quiser ir além,
00:00:24ele estará lá para te apoiar em tudo.
00:00:26- Como a equipe e você estão usando IA?
00:00:28- Começamos a fazer experimentos malucos,
00:00:30como portar o compilador do Angular para Rust.
00:00:32- O que você acha dos React Server Components?
00:00:34- Eu sou cético desde o primeiro dia.
00:00:36- Geralmente, quando apresento um podcast,
00:00:39peço aos convidados que se apresentem.
00:00:40Mas acho que se alguém estiver assistindo
00:00:42e não souber quem você é, eu ficaria surpreso.
00:00:44Acho que você é muito conhecido.
00:00:46Mas todos deveriam saber,
00:00:48ou a maioria deveria saber quem você é.
00:00:49- Com certeza já ouviram falar do Vite ou do Vue.
00:00:53- Sim, eu criei o Vue, criei o Vite.
00:00:57Agora comando uma empresa chamada VoidZero,
00:00:59onde trabalhamos em ainda mais projetos de código aberto.
00:01:03Tem o Rolldown, o Vitest, o OXC.
00:01:07O Vue e o Vite são provavelmente mais populares,
00:01:11mas as coisas em que trabalhamos na VoidZero
00:01:14também são bem legais.
00:01:15O Rolldown é um bundler baseado em Rust.
00:01:18O OXC é uma toolchain completa em Rust que inclui
00:01:22desde o parser até o resolver, transformer,
00:01:25minifier e etc.
00:01:28E sobre o OXC, temos o OX Lint e o OX Format,
00:01:32que é um linter compatível com ESLint
00:01:35e um formatador compatível com Prettier.
00:01:37E há mais coisas em que estamos trabalhando, mas enfim.
00:01:41Queremos falar principalmente sobre o open source por enquanto.
00:01:45- Com certeza.
00:01:45Já que você trabalha em tantas coisas,
00:01:47como divide o seu tempo?
00:01:50- Bem, eu pessoalmente não escrevo código
00:01:52para todos esses projetos.
00:01:53Na verdade, escrevo bem menos código hoje em dia
00:01:56desde que fundei a empresa.
00:01:58Na empresa, temos muitos engenheiros
00:02:01que são muito melhores do que eu em Rust
00:02:03e agora todos estão obcecados por IA.
00:02:05Então é metade eles e metade Claude ou Codex
00:02:10gerando um monte de código Rust.
00:02:12E eu tenho que decidir o que fazer
00:02:17em muitas das decisões de DX,
00:02:22decidir em que focar a seguir.
00:02:25E obviamente também há os produtos,
00:02:28tipo, como transformamos isso em um produto
00:02:31que gere receita,
00:02:32no qual ainda estamos trabalhando.
00:02:34É tudo o que você precisa fazer
00:02:39para gerir uma empresa hoje em dia.
00:02:41- De onde surgem as ideias
00:02:43para os novos projetos de open source?
00:02:45Vêm de necessidades internas
00:02:48que vocês percebem que poderiam ajudar
00:02:49a resolver problemas de outras pessoas também?
00:02:53- Na verdade, tudo começa com o Vite, certo?
00:02:56Quando criei o Vite, estava apenas mexendo nele.
00:03:01Começou como um protótipo
00:03:03e então pensei: precisamos de um bundler.
00:03:07Começamos com este servidor de dev
00:03:10ESM nativo e totalmente sem bundling, certo?
00:03:13A ideia funcionou bem para códigos simples,
00:03:16mas aí começamos a usar dependências grandes
00:03:18e percebemos: ok, isso não vai escalar bem
00:03:21se carregarmos todas as dependências sem bundling.
00:03:24Por exemplo, se você carregar o lodash-es,
00:03:26que tem uns 700 arquivos.
00:03:28Então pensamos: ok,
00:03:30precisamos de algo para fazer o bundle das dependências.
00:03:34Na época, havia Rollup, esbuild e Webpack.
00:03:41O Webpack não gera ESM, então não servia.
00:03:47Olhei para o Rollup e ele é bem lento.
00:03:50Muito lento comparado ao esbuild, né?
00:03:53É mais rápido que o Webpack, mas lento comparado ao esbuild.
00:03:56Usamos o esbuild para fazer o pré-bundle das dependências,
00:03:59o que é incrivelmente rápido.
00:04:00E servimos todo o código-fonte como ESM sem bundling,
00:04:02e isso funcionou perfeitamente.
00:04:04Aí, na hora da produção,
00:04:06originalmente pensamos: ok,
00:04:08vamos usar o esbuild para o bundle completo
00:04:10em produção.
00:04:11Mas percebemos que o esbuild tem controle limitado
00:04:14sobre a divisão de blocos (chunk splitting).
00:04:17Que é uma necessidade comum em aplicações maiores,
00:04:19porque você quer ter o controle,
00:04:21tipo: quero colocar essas dependências
00:04:24em um vendor chunk, para que o cache seja melhor.
00:04:26Não quero que este chunk mude nunca, entende?
00:04:28Para manter o hash consistente.
00:04:32Assim, mesmo se eu mudar meu código-fonte,
00:04:33o hash daquele chunk deve continuar o mesmo.
00:04:35Para que os usuários sempre o tenham em cache
00:04:38quando visitarem o site.
00:04:39Há várias dessas otimizações
00:04:41que o esbuild simplesmente não permite.
00:04:44Ele tem um comportamento padrão de chunk splitting
00:04:47e é isso.
00:04:49Seu sistema de plugins também é menos flexível.
00:04:53Se um plugin decide
00:04:56que vai processar esse arquivo, ponto final.
00:04:59Nenhum outro plugin pode tocá-lo mais.
00:05:02Já que vínhamos usando muito o Rollup,
00:05:05estávamos familiarizados com seu sistema de plugins.
00:05:08Então o que fizemos foi: ok,
00:05:10usaremos Rollup para produção,
00:05:13mas o esbuild para o pré-bundle de dev.
00:05:15Foi como se cada um fizesse
00:05:20o que faz de melhor nessa combinação.
00:05:23E, de fato, até o Vite 7 ainda é baseado
00:05:26nessa combinação.
00:05:27E isso funciona bem para muita gente, certo?
00:05:31Mas obviamente há problemas, porque o esbuild
00:05:35é escrito em Go e o Rollup em JavaScript,
00:05:40o que significa que o build de produção
00:05:41ainda é bem lento comparado, por exemplo,
00:05:43a bundlers feitos totalmente em Rust, como o Rspack.
00:05:47E no servidor de dev, como o esbuild
00:05:52e o Rollup têm sistemas de plugins diferentes,
00:05:55não podemos aplicar os mesmos plugins
00:05:57às dependências durante o desenvolvimento,
00:05:59mas eles são aplicados a elas
00:06:01durante o build de produção.
00:06:03Aí surgem comportamentos sutis de interoperabilidade.
00:06:07Quando você tem um grafo misto de ESM e CJS,
00:06:10o esbuild e o Rollup lidam de forma um pouco diferente.
00:06:13Há diferenças no comportamento do tree shaking.
00:06:15Embora ambos façam um bom trabalho,
00:06:18nós também corrigimos todas as inconsistências
00:06:22e tudo mais.
00:06:22Fizemos as coisas funcionarem, mas no fundo sabemos:
00:06:25são duas coisas diferentes que estamos
00:06:29tentando manter unidas de algum jeito, sabe?
00:06:31Para tornar o build de produção mais rápido
00:06:35e os builds de dev e produção mais consistentes,
00:06:40o melhor é ter um bundler único
00:06:42que faça os dois, certo?
00:06:44Mas o problema é que o esbuild é rápido,
00:06:47mas não é super extensível.
00:06:50A base de código é toda em Go.
00:06:54O Evan Wallace, autor do esbuild,
00:06:57é obviamente um cientista maluco, um gênio,
00:06:59e fez o esbuild ser extremamente rápido,
00:07:02mas não é fácil para outras pessoas
00:07:05estendê-lo, fazer um fork
00:07:07ou manter uma camada por cima dele.
00:07:10Não é simples fazer isso.
00:07:12Também é muito difícil convencer o Evan Wallace
00:07:15a fazer coisas que ele não quer,
00:07:17porque ele não precisa de dinheiro e não se importa.
00:07:21Então pensamos: ok, e quanto ao Rollup?
00:07:27Podemos torná-lo mais rápido?
00:07:28Houve alguns experimentos,
00:07:30mas fundamentalmente o Rollup é escrito em JavaScript,
00:07:33o que significa que ele roda em uma única thread.
00:07:36Tentamos coisas como worker pools e plugins em workers.
00:07:41O mantenedor do Rollup tentou colocar um parser em Rust,
00:07:47o parser SWC, no Rollup.
00:07:50Isso não melhorou o desempenho de forma perceptível,
00:07:54porque em um sistema misto de Rust e JS,
00:07:57sempre há o custo da transferência de dados.
00:07:59Você fica passando grandes strings para lá e para cá.
00:08:02Se precisar clonar a memória, fica ainda mais lento.
00:08:05O ganho bruto de performance do Rust,
00:08:09tendo apenas o parser em Rust
00:08:12com o resto em JavaScript,
00:08:13é anulado pelo custo da transferência de dados.
00:08:16No fim, a performance era quase a mesma, entende?
00:08:19Vimos que acelerar drasticamente o Rollup
00:08:23não é tecnicamente possível.
00:08:26A única opção era reescrever,
00:08:30criar um bundler projetado
00:08:33essencialmente para o Vite, e que fosse incrivelmente rápido.
00:08:37Isso deu início à jornada de pensar: ok,
00:08:40o que devemos fazer?
00:08:42Decidimos, basicamente,
00:08:44originalmente a ideia era fazer um fork do Rollup em Rust.
00:08:48Não um fork, um port, né?
00:08:49Queríamos portar o Rollup para Rust.
00:08:51Por isso o projeto se chama Rolldown.
00:08:53É um trocadilho com Rollup, Rolldown.
00:08:54Começou como um port direto,
00:08:58mas percebemos que código escrito em JavaScript
00:09:02não é nada fácil de portar diretamente para Rust
00:09:06porque o JavaScript é muito dinâmico.
00:09:08É uma linguagem dinâmica, certo?
00:09:11Mesmo se você usar TypeScript,
00:09:13ainda pode mutar as coisas o quanto quiser.
00:09:16E o Rust é muito rigoroso com a memória.
00:09:19É rígido com ciclos de vida, propriedades e afins.
00:09:23Então você precisa estruturar as coisas de forma bem diferente
00:09:25em comparação ao JavaScript.
00:09:27Nunca seria algo simples
00:09:29apenas portar o código JavaScript existente
00:09:31para uma linguagem como Rust.
00:09:33É praticamente uma reescrita.
00:09:35E acabamos decidindo,
00:09:37também queríamos o melhor dos dois mundos.
00:09:42O Rollup em si tem um núcleo bem enxuto.
00:09:45Se você quiser transformar o Rollup
00:09:47em um pacote pronto para produção,
00:09:49dá bastante trabalho
00:09:51porque você precisa de plugins como o node-resolver,
00:09:54já que resolver node modules não é nativo.
00:09:56Isso precisa ser adicionado via plugin.
00:09:58Você precisa do plugin CommonJS para dar suporte a esses módulos,
00:10:03porque o núcleo do Rollup é apenas ESM.
00:10:06E aí você tem que adicionar vários plugins,
00:10:10como define, inject, replace.
00:10:14Muitas dessas funções já vêm no esbuild,
00:10:17mas exigem plugins no Rollup.
00:10:20O pior é que a maioria desses plugins no mundo JS
00:10:25é implementada como uma etapa extra de parse AST e transform.
00:10:30Cada plugin faz todo o processo:
00:10:33pega o código do plugin anterior,
00:10:36analisa de novo, transforma,
00:10:38gera novo código e novo source map.
00:10:41E depois você tem que mesclar todos os source maps.
00:10:43É por isso que sistemas de build em JS ficam cada vez mais lentos,
00:10:46porque cada plugin repete isso sem parar.
00:10:49Então pensamos: precisamos ter isso integrado.
00:10:53Acabamos criando algo com o escopo do esbuild,
00:10:56mas com o formato de API do Rollup, que é o Rolldown.
00:11:01Mas para construir o Rolldown, pensamos:
00:11:03precisamos de um parser, de todos os transforms, né?
00:11:07Precisamos de minifier, de resolver.
00:11:10Como conseguimos isso?
00:11:12E aí entra o OXC.
00:11:14O OXC é o conjunto de ferramentas de baixo nível
00:11:17que fornece tudo isso.
00:11:20O autor do OXC trabalhava na ByteDance na época
00:11:25e eu estava de olho no projeto há muito tempo.
00:11:28O Boshen, autor do OXC,
00:11:30agora é nosso VP de Engenharia na VoidZero.
00:11:33Ele não entrou na empresa logo que a fundei.
00:11:36Eu tentava convencê-lo, mas ele estava tipo:
00:11:38não sei, sabe?
00:11:39Mas começamos a construir o Rolldown sobre o OXC de qualquer jeito.
00:11:44Pensamos: isso aqui é coisa boa.
00:11:45Eu acreditava nisso
00:11:47porque olhei todas as opções disponíveis.
00:11:51Eu queria algo que fosse composável.
00:11:54Queria que cada parte da toolchain
00:11:57fosse usável individualmente como crates.
00:12:00E queria que fosse extremamente rápido, sabe?
00:12:03Comparamos o OXC com o SWC.
00:12:06O parser do OXC é umas três vezes mais rápido
00:12:09que o do SWC, embora ambos sejam em Rust,
00:12:12por causa de decisões de design
00:12:15e detalhes técnicos de baixo nível
00:12:18que levaram a essa diferença de performance.
00:12:20O Boshen é obcecado
00:12:24pela performance de parsing e linting
00:12:27desde muito antes de entrar na empresa.
00:12:30Por exemplo,
00:12:32o OXC usa algo chamado arena allocator,
00:12:34que coloca toda a alocação de memória para a AST
00:12:39em um bloco de memória consecutivo.
00:12:41Ele aloca um grande bloco
00:12:43e coloca a AST lá diretamente.
00:12:45Assim, o tempo para liberar a memória é menor.
00:12:50Isso também permitiu coisas interessantes que fizemos
00:12:53e que habilitaram plugins JS rápidos no OX Lint,
00:12:57porque essa memória consistente nos permite
00:12:59passar todo o bloco para o JavaScript
00:13:01sem cloná-lo, para depois desserializar no lado do JS.
00:13:05Há muitos benefícios,
00:13:06mas naquela época eu olhava para o projeto,
00:13:10estava muito impressionado,
00:13:10decidimos construir o Rolldown sobre ele
00:13:13e acabamos convencendo o Boshen a vir conosco.
00:13:16Agora o escopo da empresa é basicamente
00:13:21ter essa stack vertical em Rust
00:13:24que começa no parser.
00:13:26Abrange desde o bundling até o Vite,
00:13:29e temos Linter, Formatter, Test Runner, entende?
00:13:33Temos uma toolchain completa.
00:13:34E o nosso próximo passo,
00:13:37no qual já estamos trabalhando há um tempo,
00:13:40é juntar tudo isso em um pacote coerente
00:13:43para que você não precise instalar cinco coisas separadas
00:13:47só para fazer o básico do app funcionar.
00:13:50Você também não precisará
00:13:51de seis ou sete arquivos de configuração diferentes.
00:13:55Vamos colocar tudo em um único arquivo,
00:13:57com a garantia de que tudo funcionará em conjunto
00:13:59porque usam o mesmo parser,
00:14:02o mesmo pipeline de transform e o mesmo resolver.
00:14:05Assim não haverá surpresas.
00:14:07Por exemplo, se você usa Webpack e Jest,
00:14:10precisa configurar a lógica de resolução separadamente
00:14:14porque eles simplesmente não usam a mesma coisa.
00:14:16A visão é realmente esta:
00:14:19vamos construir uma stack vertical
00:14:22que funcione de forma consistente em todo lugar.
00:14:25Tornar o fluxo de desenvolvimento o mais simples
00:14:29e rápido possível, entende?
00:14:30A performance é um ponto fundamental.
00:14:32Eu já considero isso um fato,
00:14:34mas você deve ter visto posts dizendo que o Rolldown
00:14:39é umas 20 vezes mais rápido que o Rollup.
00:14:43O OX Lint é de 50 a 100 vezes mais rápido que o ESLint.
00:14:47O OX Format é umas 30 ou 40 vezes mais rápido que o Prettier.
00:14:51Nosso objetivo é torná-los compatíveis
00:14:57para que você possa migrar sem grandes refatorações,
00:15:00mas ganhando esses saltos gigantes de performance.
00:15:04Agora o seu ciclo de testes, a checagem do linter
00:15:08e tudo mais será muito mais rápido e fluido.
00:15:12E isso permitirá que as pessoas
00:15:15criem mais aplicativos em menos tempo.
00:15:17- É incrível como isso escala rápido,
00:15:20de "precisamos de uma ferramenta para o Vue" para
00:15:22"ah, agora quero melhorar aquela outra peça ali".
00:15:24"E agora quero melhorar aquela parte também".
00:15:25Como você disse, vocês realmente dominam
00:15:27toda a stack vertical.
00:15:29É impressionante e muito veloz.
00:15:32Eu estava contando ao pessoal antes de começarmos
00:15:33que, em um dos meus empregos antigos,
00:15:35trabalhei em um projeto legado
00:15:37que usava Webpack e levava uns 50 minutos para o build.
00:15:40Não faço ideia do que acontecia,
00:15:42mas a primeira coisa que eu disse foi:
00:15:43precisamos mudar isso para Vue agora mesmo.
00:15:46Porque ao alterar um CSS,
00:15:47tínhamos que esperar uns dois minutos
00:15:49pelo rebuild e tudo mais.
00:15:49Eu pensava: isso não está certo.
00:15:52Precisamos usar Hot Module Replacement.
00:15:54Ao salvar o arquivo, a mudança deveria aparecer.
00:15:57Então o Vue definitivamente ajudou com isso.
00:15:59E o progresso e a velocidade
00:16:02com que o Vue decolou são sensacionais.
00:16:05Vi que já passou de 200 milhões de downloads no NPM,
00:16:07mensais ou algo absurdo assim.
00:16:09É...
00:16:10- Sim, passamos de 50 milhões por semana recentemente.
00:16:13- Nossa, é de explodir a cabeça.
00:16:15- Eu estava pensando nesses 50 milhões.
00:16:19Deve haver um pouco de inflação
00:16:21desses apps gerados por IA.
00:16:23Que são apenas apps descartáveis.
00:16:26Ainda assim, mostra que muita gente
00:16:29ou provavelmente muitos agentes de IA o utilizam.
00:16:33- Eu ia dizer que o time de engenharia
00:16:34da BetterStack é muito fã do Vue.
00:16:36Eles usam Rails no backend e Vue no frontend.
00:16:40Eles enviaram algumas perguntas que farei
00:16:42ao longo do podcast conforme o papo fluir.
00:16:46Mas você mencionou algo sobre bundling,
00:16:48e uma das perguntas deles foi:
00:16:49já que eles usam import maps no Rails,
00:16:52qual você acha que é o futuro do bundling?
00:16:54Pois não é preciso fazer muito bundle
00:16:56usando import maps.
00:16:57Para onde você acha que isso vai?
00:17:00- Na verdade, eu tenho uma página dedicada
00:17:02na documentação do Rolldown,
00:17:04onde o título é:
00:17:07"Por que ainda precisamos de Bundlers?"
00:17:10- Você tem sido muito questionado sobre isso?
00:17:13- Sim, e o DHH é um grande defensor
00:17:16do "no bundle, no build".
00:17:18Então temos que prestar atenção nisso.
00:17:20Os import maps funcionam até certo ponto,
00:17:24mas o conceito de "unbundled" em geral
00:17:29só funciona até certa escala.
00:17:35Se seu app tem menos de mil módulos,
00:17:39seu grafo de módulos provavelmente carrega
00:17:41em algumas centenas de milissegundos,"
00:17:43o que é totalmente aceitável.
00:17:45Se você sabe que está dentro desse limite,
00:17:48isso é ótimo, na verdade.
00:17:50É lazy por padrão,
00:17:53o que significa que se você tem um app grande
00:17:56com páginas isoladas,
00:17:58você tem esse subgrafo de módulos,
00:18:00e funciona razoavelmente bem.
00:18:01É por isso que o Vite funciona tão bem em desenvolvimento.
00:18:05Mas não é uma solução mágica,
00:18:07porque o que notamos com o próprio Vite
00:18:09e a razão de estarmos trabalhando em algo
00:18:12chamado "full bundle mode" no Rolldown
00:18:15é que o modo sem bundle tem limitações,
00:18:18onde o gargalo é o número de módulos.
00:18:21Existem muitos apps que
00:18:25carregam milhares e milhares de módulos
00:18:29durante o desenvolvimento, sabe?
00:18:32Você pode estar carregando 3.000 módulos,
00:18:33e isso vai sobrecarregar o navegador.
00:18:36O gargalo está no nível da rede,
00:18:38porque com ESM nativo,
00:18:40você envia uma requisição HTTP para buscar cada módulo.
00:18:44E se houver um grafo de importação profundo,
00:18:46ele precisa buscar o primeiro módulo,
00:18:49perceber que precisa de outros módulos
00:18:52e então ir buscá-los.
00:18:53E depois buscar outros mais,
00:18:54você precisa percorrer o grafo todo avidamente
00:18:57antes de avaliar o primeiro módulo importador.
00:19:00Em uma conexão ruim,
00:19:04há o risco de várias viagens de rede
00:19:06antes de conseguir renderizar a primeira coisa.
00:19:09Com milhares de módulos,
00:19:13a situação é amplificada pela rede.
00:19:17Mesmo no desenvolvimento local, no servidor do Vite,
00:19:20se tiver mais de 3.000 módulos,
00:19:23pode levar um ou dois segundos para carregar localmente.
00:19:27Imagine o que isso faria em produção
00:19:29através da internet, né?
00:19:31Você não quer isso, porque se fizer o bundle,
00:19:35provavelmente levará uns 100 milissegundos.
00:19:38É uma otimização gratuita que está na mesa
00:19:40e que você deve aproveitar
00:19:41quando ultrapassa certo limite.
00:19:45Acho que o maior argumento contra o bundling
00:19:47e ferramentas de build é que as pessoas cansaram
00:19:52de configurar essas ferramentas, né?
00:19:55Provavelmente encontraram bugs,
00:19:56problemas de configuração que não sabiam resolver.
00:20:01Como o Webpack tornou tudo tão complexo,
00:20:04todo mundo acabou,
00:20:06quando pensa em configurar um bundler,
00:20:08achando que não é trabalho para elas e que não querem fazer.
00:20:11Acho que as pessoas criaram esse ressentimento,
00:20:14quando ouvem falar em etapa de build,
00:20:16já pensam: "isso é ruim, quero evitar", entende?
00:20:19De certa forma, o que queremos fazer com isso
00:20:22e com as ferramentas que estamos criando é:
00:20:24tornar esses conceitos muito diretos.
00:20:28Nunca será 100% simples
00:20:32para aplicativos grandes e complexos, né?
00:20:34Mas queremos que seja simples o bastante para um app novo,
00:20:37para que você não precise pensar demais nisso
00:20:41se seu app não for super complicado.
00:20:45Você deve conseguir apenas subir o app,
00:20:48usar o Vite e saber que tudo ficará bem.
00:20:50Sei que existe uma iniciativa da comunidade
00:20:55chamada Vite Ruby ou Vite Rails
00:20:59que faz o Vite funcionar muito bem no Rails.
00:21:05O setup sem build tem suas vantagens, né?
00:21:12Dá uma sensação de segurança porque você sabe
00:21:14que pode evitar muitas dependências
00:21:17e incertezas que poderiam quebrar as coisas.
00:21:20Acho que também há uma perda de confiança
00:21:23no sistema de build, no tipo:
00:21:26"sempre vai ter alguma coisa que vai dar errado".
00:21:29"O build vai quebrar quando eu atualizar uma dependência".
00:21:33Eles podem evitar tudo isso, o que é tentador.
00:21:36Mas, no fim das contas,
00:21:37se a tecnologia for boa e estável o suficiente,
00:21:41você sempre vai querer a melhor experiência para o usuário.
00:21:45E usar o modelo totalmente sem bundle impõe
00:21:48limites severos ao tamanho da aplicação.
00:21:52Você também precisa se preocupar com otimização,
00:21:54porque tem que pensar:
00:21:57"será que não estou importando coisas demais
00:22:01em uma determinada página?"
00:22:03"Como faço o cache dos módulos de forma inteligente?"
00:22:06Acredito que mesmo no Rails sem bundle,
00:22:08ainda é preciso uma etapa de pré-processamento
00:22:11para carimbar os módulos e garantir o cache correto.
00:22:15Inevitavelmente, você ainda precisará focar
00:22:18na otimização para que as coisas funcionem.
00:22:21Eu diria que funciona para um
00:22:24bom número de casos, mas não é algo
00:22:29que cobrirá todos os cenários.
00:22:31Algumas pessoas constroem apps realmente grandes,
00:22:35com muitas funcionalidades.
00:22:37Não dá para forçá-las a não usar bundle
00:22:39e deixá-las presas nessa situação
00:22:42de performance impossível de otimizar.
00:22:45- Para quem não conhece muito,
00:22:49qual a diferença entre o Vite e o Vite+?
00:22:54E o que as pessoas ganham com ele?
00:22:57- Com o Vite+, estamos passando por um
00:23:02pequeno ajuste de rota sobre o que ele deve ser agora.
00:23:06A ideia é: se você está começando
00:23:11no desenvolvimento JavaScript agora,
00:23:14totalmente do zero,
00:23:17em uma máquina nova que não tem nada instalado.
00:23:21Como você sai do zero para um app funcional
00:23:25com HMR, todas as melhores práticas,
00:23:28linting, formatação e testes já configurados?
00:23:33Hoje em dia, é muita coisa para aprender.
00:23:36A primeira coisa é:
00:23:38o que é Node.js?
00:23:39Como eu instalo?
00:23:40O que é um gerenciador de versões de Node?
00:23:42Qual gerenciador de pacotes usar?
00:23:44Qual ferramenta de build?
00:23:45Qual linter?
00:23:47Você tem que responder a todas essas perguntas.
00:23:49Queremos eliminar todas essas dúvidas.
00:23:50Damos a você um ponto de partida opinativo,
00:23:52onde, você sabe,
00:23:54não precisa nem instalar o Node.js.
00:23:57Estamos experimentando uma nova forma
00:23:59de trabalhar com o Vite+, que é via curl:
00:24:03tipo, curl -sS [https://vplus.dev/install](https://www.google.com/search?q=https://vplus.dev/install) | bash.
00:24:08Depois você faz vp new, e tem um novo projeto.
00:24:15Aí faz vp dev, e pronto,
00:24:17você tem toda a suíte de ferramentas configurada.
00:24:21O linter, o formatador,
00:24:25test runner, bundler... você também pode usar
00:24:28para estruturar um monorepo.
00:24:31Ele faz o bundle de bibliotecas.
00:24:32Planejamos adicionar recursos como lint-staged
00:24:39e gestão de changelog.
00:24:41Para grandes monorepos de bibliotecas,
00:24:44e também tem algo chamado vp run,
00:24:49que é um executor, parecido com o pnpm run,
00:24:52mas um pouco mais sofisticado,
00:24:57tipo o Nx, que consegue descobrir
00:24:59a ordem correta para rodar suas tarefas
00:25:03e faz o cache delas de forma inteligente.
00:25:04Mas isso é opcional.
00:25:07É um conjunto de coisas que,
00:25:11se você não precisar desse extra,
00:25:13ainda pode usar como se fosse o Vite básico, entende?
00:25:17Sua experiência de desenvolvimento será idêntica
00:25:18ao que o Vite é hoje.
00:25:20Mas se você quiser avançar,
00:25:24escalar para um monorepo de nível empresarial
00:25:27pronto para produção, ele te acompanha em tudo.
00:25:31E também porque ele é construído
00:25:33sobre tecnologias comprovadas
00:25:35que já são usadas em situações assim.
00:25:39É isso que esperamos trazer.
00:25:44Estamos convertendo muitos usuários
00:25:47para nossas ofertas de código aberto.
00:25:48Pessoas migrando de Webpack para Vite,
00:25:52ou de ESLint para OX Lint.
00:25:54O que esperamos que o Vite+ seja é
00:25:57a resposta para a pergunta:
00:26:00"O que eu faço se estou começando agora no JS?"
00:26:02"Qual a forma mais rápida e simples de começar?"
00:26:05Quero responder a isso
00:26:07e também fazer com que funcione muito bem com IA.
00:26:11- O objetivo da empresa é...
00:26:14acho que muita gente se assusta ao saber
00:26:15que há uma empresa por trás de projetos open source,
00:26:17pelo medo de começarem a cobrar por certas funções.
00:26:20Mas o objetivo é o que você sempre fez?
00:26:23Dá para fazer o que o Vite+ faz por conta própria.
00:26:25Mas exige muita configuração,
00:26:26e o Vite+ é apenas uma conveniência
00:26:29que pacota tudo em um só lugar, como você disse.
00:26:31Então vocês nunca cobrariam por uma funcionalidade?
00:26:34- Bem, nós sugerimos a ideia
00:26:37por trás do licenciamento do Vite+, né?
00:26:39Dissemos que, se a sua empresa
00:26:41estiver acima de certo limite, teria que pagar.
00:26:44Essa ideia vem evoluindo,
00:26:46porque conversamos com muitas empresas interessadas
00:26:50e estamos tentando achar um equilíbrio
00:26:53entre colocar a ferramenta na mão de mais pessoas
00:26:56e criar valor, permitindo que a gente capture valor
00:27:00e seja sustentável, certo?
00:27:02Acho que vamos subir muito esse limite.
00:27:07Para que apenas uma categoria bem pequena de empresas
00:27:11tenha que pagar.
00:27:14A maioria dos usuários deve poder aproveitá-lo
00:27:17de graça, até porque
00:27:20estamos trabalhando em ideias que são mais como serviços
00:27:25do que apenas cobrar por funções extras.
00:27:27Um serviço que acompanhe o Vite+
00:27:31que melhore a qualidade do seu código,
00:27:35monitore essa qualidade
00:27:37e te dê dicas ou sugestões de melhoria.
00:27:39Ajude a aprimorar certas coisas.
00:27:41Pois há muito conhecimento de domínio
00:27:44que agora podemos escalar através de agentes de IA.
00:27:48É essa a direção que estamos explorando.
00:27:51- Entendi. Eu me pergunto também,
00:27:53já que o Vite+ torna tudo mais prático,
00:27:56você acha que a IA consegue fazer isso com as soluções atuais?
00:28:00Qual sua experiência
00:28:02em pedir para a IA montar todo o formato
00:28:05do linter, do build e tudo mais?
00:28:07Você acha que ela vai depender de tecnologia antiga
00:28:09devido aos dados de treinamento e criar uma bagunça?
00:28:13- Vemos muitos apps gerados por IA
00:28:17que ainda usam o Vite 6, por exemplo.
00:28:20Porque, um detalhe importante: quando lançamos uma versão nova,
00:28:26com novas funcionalidades, leva tempo para os modelos
00:28:29serem treinados com esses dados.
00:28:31Os modelos sempre estarão atrasados em relação às novidades,
00:28:34e parte do que queremos fazer
00:28:37é, por exemplo: se lançarmos uma versão nova do Vite+,
00:28:41ele virá com seus próprios
00:28:44arquivos .md de agentes e habilidades.
00:28:47Ao atualizar o Vite+, ele atualiza,
00:28:50aplica o patch relevante no .md do seu agente
00:28:54e faz o link com as habilidades que foram atualizadas
00:28:58no seu pacote npm.
00:29:00E também,
00:29:05podemos fornecer um prompt que diga:
00:29:08"se quiser atualizar desta versão para aquela,
00:29:10este prompt ajudará seu agente a fazer isso sem problemas".
00:29:13Muito disso terá que vir
00:29:17dos próprios autores das ferramentas.
00:29:19Uma coisa que notamos
00:29:22é que o OX Lint, o OX Format e o Vitest
00:29:26estão sendo usados no OpenClaude.
00:29:29E o OpenClaude é uma base de código insana.
00:29:31São 54.000 linhas de JavaScript
00:29:34evoluindo em um ritmo alucinante.
00:29:36O autor está aceitando mudanças sem nem ler.
00:29:40É muita coisa,
00:29:43tem muita coisa lá
00:29:45que simplesmente não faz sentido.
00:29:46Estamos vendo alguns PRs que atualizam o OX Lint
00:29:51ou tentam adotá-lo.
00:29:54São opções alucinadas que nem existem.
00:29:57E nós ficamos: "espera, não temos essa opção",
00:29:59"temos que..."
00:30:00E quando ele faz o type checking,
00:30:04ele só tenta "corrigir" o erro.
00:30:06"Ok, vou desativar esta regra".
00:30:07"Assim o tipo vai passar".
00:30:09A IA vai pegar atalhos
00:30:12se você não colocar barreiras, entende?
00:30:15E o mais importante é que o Peter,
00:30:18autor do OpenClaude,
00:30:20não é um desenvolvedor TypeScript.
00:30:22Ele apenas escolheu o TypeScript para o projeto.
00:30:25Ele não é um especialista em ferramentas.
00:30:26Não tem experiência nessa área.
00:30:29A IA o ajudou a fazer.
00:30:30Mas, como autores das ferramentas usadas pela IA,
00:30:35notamos onde ela falha.
00:30:38E pensamos: "olha, se você continuar assim"
00:30:41"sem que a gente aponte esses erros,"
00:30:44"seu código vai desmoronar em três meses".
00:30:46Este é o valor
00:30:50que achamos que podemos oferecer na era da IA:
00:30:54como garantir que você está entregando rápido
00:30:58sem quebrar nada?
00:30:59Como continuar entregando rápido com a IA?
00:31:03A velocidade de entrega de código
00:31:06está aumentando massivamente por causa dos agentes.
00:31:11As pessoas entregam funções muito mais rápido agora.
00:31:14Mas essas funções são revisadas corretamente?
00:31:19Quando você aprova 20 PRs por dia,
00:31:22a base de código continua,
00:31:25bem mantida como deveria?
00:31:26A saúde do código fica muito volátil.
00:31:30Você precisa, de tempos em tempos,
00:31:33fazer como fazemos no desenvolvimento humano.
00:31:36Você entrega funcionalidades por um tempo,
00:31:37mas depois precisa parar e pensar:
00:31:38"ok, precisamos limpar as coisas".
00:31:40"Precisamos pagar a dívida técnica que acumulou".
00:31:42Com agentes de IA, entregamos muito mais rápido agora.
00:31:45Mas também acumulamos dívida técnica mais rápido, né?
00:31:49Então você precisa usar a IA para pagar essa dívida também.
00:31:53Acho que essa é a parte
00:31:56que as pessoas estão ignorando
00:31:57e que precisa de uma solução agora.
00:32:00- É, eu dei uma olhada no OpenClaude,
00:32:03e é meio caótico.
00:32:05É um ótimo exemplo do que acontece
00:32:07quando você deixa a IA solta
00:32:09fazendo o que quer
00:32:11sem qualquer supervisão.
00:32:13Tem sido divertido acompanhar isso na internet
00:32:16nas últimas semanas.
00:32:19Mas eu também queria saber se,
00:32:22vocês mudam a forma de criar um formatador
00:32:26e um linter para que agentes de IA os usem melhor?
00:32:29Isso molda o futuro,
00:32:31ou o fato de vocês criarem ferramentas velozes
00:32:34já ajuda naturalmente na era da IA?
00:32:38Com certeza a velocidade ajuda os agentes a usá-los.
00:32:40- Com certeza, é um bom raciocínio,
00:32:45pois estamos começando a pensar nesse problema.
00:32:48O escopo original desses linters
00:32:50e formatadores é imenso,
00:32:53porque estamos tentando ser compatíveis
00:32:54com o ESLint e o Prettier,
00:32:56que estão no mercado há uma década,
00:33:00onde as pessoas têm regras customizadas
00:33:03e casos de uso legados.
00:33:06E tentamos ser 100% compatíveis com isso.
00:33:09É uma quantidade enorme de trabalho,
00:33:13mas finalmente conseguimos, pois recentemente atingimos
00:33:17100% de compatibilidade com plugins do ESLint.
00:33:21Passamos em todos os testes de plugins do ESLint
00:33:23e também alcançamos 100% de conformidade
00:33:25com o Prettier no nosso formatador, certo?
00:33:28Esses dois marcos significam:
00:33:31"ok, agora podemos recomendar com confiança"
00:33:34"que as pessoas migrem para nossas ferramentas". E o que vem depois?
00:33:38Essa é a grande pergunta.
00:33:40Como o linting e a formatação devem
00:33:44se adaptar quando agentes os estão usando?
00:33:49É uma questão na qual estamos trabalhando ativamente.
00:33:53Sim.
00:33:54- Basicamente, aguardamos uma resposta para essa.
00:33:57Ainda está evoluindo, sim.
00:33:59A IA está mudando muita coisa
00:34:01no mundo do código, é interessante ver.
00:34:04- Voltando ao assunto do Vite+...
00:34:06você o apresentou na ViteConf 2025
00:34:10e mostrou um recurso chamado "vite install".
00:34:14Minha pergunta é: esse recurso ainda existe?
00:34:17E quanto de sobreposição o Vite+ terá
00:34:19com algo como o Bun?
00:34:21- Ótima pergunta.
00:34:23As coisas mudaram um pouco desde a ViteConf, né?
00:34:27Eu diria que a...
00:34:30a versão pública final do Vite+ provavelmente
00:34:33vai se parecer um pouco com o Bun nesse sentido, sabe?
00:34:38A experiência de onboarding, como eu disse:
00:34:41se você tem uma máquina limpa,
00:34:43e pensa: "quero começar a criar um web app"
00:34:45"o mais rápido possível".
00:34:46Você faz o curl do script
00:34:51e ganha um binário global chamado "vp".
00:34:56Quando você estiver dentro de um projeto,
00:35:02se houver um arquivo .node-version
00:35:04e um campo de gerenciador de pacotes no package.json,
00:35:06que são as formas comuns de especificar essas coisas,
00:35:11o ambiente JS em que você está trabalhando...
00:35:15Quando você fizer "vp run build",
00:35:20ele vai usar automaticamente,
00:35:22mesmo quando você fizer só "vp build" ou "vp lint",
00:35:26qualquer coisa que envolva rodar JavaScript,
00:35:28ele vai escolher a versão certa do Node
00:35:31e o gerenciador de pacotes correto para você.
00:35:36Então, em um projeto com Vite+ habilitado...
00:35:40na verdade, mesmo se não estiver usando o Vite+ no projeto,
00:35:44desde que você use
00:35:45essas fontes convencionais de ambiente,
00:35:48pode usar o Vite+ como substituto para o nvm.
00:35:52Pode usar como substituto para o corepack.
00:35:55Você para de pensar em versões.
00:35:59A ideia é que, ao executar seu fluxo de trabalho,
00:36:02você também para de fazer "npm run".
00:36:05Você usa "vp run".
00:36:06Então, quando você faz um "vp run",
00:36:10ele vai usar o Node correto,
00:36:14vai usar o gerenciador de pacotes correto
00:36:16e fazer a coisa certa.
00:36:19O "install" significa que ele vai apenas...
00:36:24nós não temos um gerenciador de pacotes próprio ainda, certo?
00:36:27É mais como um equivalente ao corepack.
00:36:30Não sei se você já usou o pacote "ni",
00:36:34do Anthony Fu.
00:36:36O "ni" basicamente detecta,
00:36:41quando você o executa, qual gerenciador de pacotes usar,
00:36:45seja para rodar, instalar ou desinstalar,
00:36:48tanto faz, né?
00:36:49O "vite install" é essencialmente isso,
00:36:51mais a parte do gerenciador de versões.
00:36:56Que é o que o corepack faz, certo?
00:36:58Mesmo que você não tenha nada instalado,
00:37:01ao entrar em um projeto onde o package.json
00:37:03indica o pnpm
00:37:07em uma certa versão.
00:37:08Você roda "vite install", e ele checa
00:37:12se aquela versão do pnpm está instalada.
00:37:14Se não estiver, ele instala
00:37:16e roda o processo de instalação com o pnpm.
00:37:20A ideia é que queremos,
00:37:25resolver mais do que apenas linting e formatação.
00:37:31É cobrir todas as tarefas comuns
00:37:34do seu fluxo de trabalho JavaScript, entende?
00:37:36Queremos eliminar esses problemas chatos para que,
00:37:40um iniciante nem precise pensar neles.
00:37:43Na primeira vez que você criar um projeto,
00:37:45usaremos a última LTS do Node e recomendamos o pnpm.
00:37:50E gravaremos essas informações no seu projeto.
00:37:53Assim, na próxima vez que você abrir o projeto,
00:37:55ele sempre usará a combinação correta de ferramentas.
00:37:59- Por que você recomenda o pnpm, por curiosidade?
00:38:02- Ele tem o equilíbrio ideal de funcionalidades,
00:38:06correção, eficiência de disco e velocidade,
00:38:10além de ótimo suporte a workspaces, como os catalogs.
00:38:15Sabe, quando...
00:38:19quando comparamos os recursos de workspace,
00:38:21vimos que o pnpm ainda oferece o melhor equilíbrio.
00:38:25Sabemos que o Bun é ridiculamente rápido,
00:38:29mas o pnpm tem sido rápido o suficiente para muitos de nós.
00:38:33E também não descartamos a possibilidade
00:38:35de suportarmos o Bun no nosso runtime
00:38:37e na gestão de versões de gerenciadores de pacotes.
00:38:40Você poderá dizer: "quero usar o Bun",
00:38:42e nós rodaremos as coisas com ele.
00:38:44- Sobre o Vite 8, você disse que o lançamento seria
00:38:49após o Ano Novo Lunar, certo?
00:38:52- Sim.
00:38:54- Quais são os pontos principais do beta
00:38:58em que você está focando antes do lançamento final?
00:39:00- É puramente estabilidade.
00:39:04Temos o Ecosystem CI,
00:39:06um sistema massivo de integração contínua
00:39:10onde rodamos o Vite 8 em projetos que dependem dele.
00:39:15Recentemente, conseguimos que
00:39:17todos os testes do SvelteKit passem no Vite 8.
00:39:21Isso é uma grande vitória para nós
00:39:24porque a estabilidade é a coisa mais importante.
00:39:27Pense bem:
00:39:28estamos trocando dois bundlers
00:39:30por um novo que construímos do zero.
00:39:33É como trocar os motores de um avião em pleno voo
00:39:36e esperar que ele continue voando suavemente.
00:39:40Todo cuidado é pouco.
00:39:43- Eu ia perguntar antes: a escolha pelo Rust,
00:39:46foi porque as pessoas do seu time
00:39:48já tinham conhecimento da linguagem?
00:39:49Pois vejo que muitos no mundo TypeScript
00:39:51preferem Go por ser uma transição mais próxima,
00:39:55e até o time do TypeScript está indo para o Go
00:39:57para o compilador.
00:39:58- Sim, acho que a escolha do time do TypeScript
00:40:02pelo Go é porque, como eu disse,
00:40:04é uma linguagem muito mais fácil para portar TypeScript.
00:40:09O modelo mental é muito mais parecido.
00:40:13Mas um dos grandes impeditivos para nós
00:40:17foi que o Go tem um suporte abaixo do ideal para WebAssembly.
00:40:21Ele gera binários WebAssembly gigantes
00:40:26e a performance em WebAssembly
00:40:29não é tão boa quanto a do Rust.
00:40:32Sobre o Rust,
00:40:35muito se deve ao talento disponível,
00:40:39pessoas que já são apaixonadas
00:40:41e investidas no ecossistema.
00:40:44Por exemplo, quando analisamos
00:40:46as fundações sobre as quais construir,
00:40:48não havia um conjunto de parser ou toolchain
00:40:54tão bem implementado e composável quanto o OXC.
00:40:59O OXC foi feito para ser a base de outras ferramentas.
00:41:04São utilitários de baixo nível.
00:41:08Não vemos um equivalente assim no mundo Go.
00:41:11O esbuild tem seu próprio parser e tudo mais,
00:41:14mas é um sistema monolítico.
00:41:18Não dá para simplesmente extrair o parser dele e usar.
00:41:23Além disso, as funções no esbuild,
00:41:25como define, inject, transforms... para
00:41:30obter a melhor performance,
00:41:33elas são implementadas em três passagens AST,
00:41:36o que significa que, em uma mesma passagem,
00:41:37você tem preocupações misturadas:
00:41:39fazendo transformação aqui,
00:41:41injetando um recurso ali,
00:41:42fazendo uma modificação acolá.
00:41:45Isso não é ideal para um sistema extensível
00:41:51onde, por exemplo,
00:41:54queremos permitir que as pessoas
00:41:57ativem ou desativem transforms específicos.
00:42:01Queremos que as pessoas escrevam seus próprios transforms.
00:42:03Queremos um sistema de linter
00:42:07camadado de forma limpa
00:42:09para que mais pessoas possam trabalhar nele simultaneamente.
00:42:13Muito teve a ver com o que tínhamos disponível.
00:42:16O Rust também é extremamente performante.
00:42:22De fato, é um pouco complicado escrever bons transforms em Rust.
00:42:26Tivemos que dedicar um bom tempo
00:42:28descobrindo uma boa arquitetura
00:42:31para os visitors e para o pipeline de transformers,
00:42:34devido às questões de posse de memória (memory ownership).
00:42:37Ao percorrer a árvore profundamente
00:42:39e precisar mudar algo no pai,
00:42:42a coisa fica bem complicada, entende?
00:42:44Mas achamos uma saída.
00:42:45É bem mais fácil em Go, mas quando pensamos
00:42:49que queremos que nossas ferramentas compilem
00:42:51para WebAssembly e rodem no navegador...
00:42:53O Rolldown consegue rodar no browser
00:42:57com uma velocidade muito decente.
00:42:59O esbuild também roda no browser,
00:43:01mas o WebAssembly do Rust é simplesmente superior.
00:43:05- Outra coisa que eu ia perguntar
00:43:07sobre o time construindo em Rust e tudo mais:
00:43:09como você e o time estão usando IA?
00:43:12Você mencionou antes que muita gente
00:43:14do time está usando IA.
00:43:16Você acha que a IA é boa para o tipo de trabalho que vocês fazem?
00:43:19Pois no desenvolvimento web comum,
00:43:21há muitos exemplos no GitHub para treinar a IA.
00:43:23Então a IA aprendeu bem.
00:43:25Mas o que vocês fazem é um nível mais baixo de tecnologia,
00:43:28ou pelo menos exige uma alta tecnicidade.
00:43:30A IA ajuda nesse cenário ou vocês ainda fazem
00:43:32muito código manual?
00:43:34- Ela ajuda, com certeza.
00:43:38O ponto é que a área está mudando muito rápido.
00:43:41No ano passado, nesta mesma época, eu era cético.
00:43:45Eu pensava: "tentei usar e não funciona para mim"
00:43:49"porque o que eu faço é muito baixo nível", sabe?
00:43:52Mas o Boshen, que lidera o OXC,
00:43:59é provavelmente a pessoa mais fã de IA
00:44:03na empresa agora.
00:44:04Ele começou a fazer experimentos malucos.
00:44:07Acho que no mês passado, em uma única semana,
00:44:11ele entregou uns 60 PRs com IA,
00:44:13rodando agentes em paralelo.
00:44:16E começamos a fazer experimentos ousados
00:44:19como portar o compilador do Angular para Rust,
00:44:24só para ver se ia funcionar.
00:44:27E, de alguma forma, está funcionando.
00:44:29Talvez tenhamos algo nessa linha no futuro.
00:44:33Nossa percepção sobre a
00:44:39capacidade da IA está sendo atualizada
00:44:43a cada poucos meses
00:44:46conforme novos modelos surgem,
00:44:48com melhores ferramentas de suporte sendo criadas
00:44:51e novas práticas, como o "plan mode"
00:44:55e os arquivos .md de agentes.
00:45:00São dicas e truques novos.
00:45:03Ao aplicar essas pequenas coisas, você percebe:
00:45:06"nossa, está ficando cada vez melhor".
00:45:08O nível de adoção varia de pessoa para pessoa, né?
00:45:13Nós incentivamos todos na empresa
00:45:18a usar na medida que acharem melhor.
00:45:22Damos um crédito mensal
00:45:24para que possam usar o Claude Max, se quiserem.
00:45:27Alguns estão muito felizes com isso
00:45:33e são bem vocais a respeito.
00:45:36E estão entregando PRs realmente bons.
00:45:40Depende muito de como você sabe usar.
00:45:45Parte é a capacidade bruta do modelo,
00:45:49parte é a ferramenta de suporte que você usa,
00:45:52mas essa camada de suporte
00:45:54me lembra os frameworks JS de antigamente.
00:45:57Todo mundo está criando a sua própria versão.
00:46:00E todos fazem mais ou menos a mesma coisa.
00:46:03Talvez um tenha um truque diferente na manga,
00:46:08mas meses depois, todos já estão fazendo igual, né?
00:46:11Será um campo muito competitivo,
00:46:13e com os modelos é a mesma coisa.
00:46:17A cada poucos meses...
00:46:18o Sonnet 3.5 acabou de sair.
00:46:21A DeepSeek deve lançar um modelo novo logo.
00:46:23Só vai melhorar.
00:46:26Está claro que a IA é extremamente capaz
00:46:32com o direcionamento certo,
00:46:34mas o direcionamento ainda é crucial.
00:46:37Você não pode esperar que alguém com zero conhecimento de Rust
00:46:41consiga trabalhar na base de código do OXC, nem com IA.
00:46:45A pessoa provavelmente nem saberia como dar o prompt.
00:46:50Mas alguém que já é eficiente no OXC,
00:46:54um engenheiro de Rust, ao usar IA,
00:46:58torna-se muito mais produtivo
00:47:00e consegue entregar mais funções em menos tempo.
00:47:03Essa é a minha visão geral.
00:47:08Eu sou provavelmente o que...
00:47:13a quantidade de código que produzo com IA é mínima,
00:47:16quase nada comparado aos outros engenheiros.
00:47:20Uso mais para pesquisa e para validar ideias.
00:47:25- É um mundo estranho em que
00:47:27a programação está entrando.
00:47:29E acho difícil acompanhar
00:47:32quantos subagentes devem ser usados,
00:47:34agentes paralelos, qual arquivo markdown ter
00:47:37no repositório agora.
00:47:38Está mudando o tempo todo.
00:47:40É curioso ver onde vamos parar
00:47:43no futuro.
00:47:43- Voltando ao Vite por um instante...
00:47:47No Vite 7, vocês lançaram suporte a React Server Components.
00:47:52Na minha opinião, os React Server Components
00:47:54não foram o sucesso estrondoso que o time esperava.
00:47:57Alguns frameworks não os adotaram,
00:48:00como o TanStack.
00:48:01E acho que o Remix seguiu uma direção própria.
00:48:04O que você acha dos React Server Components
00:48:07e por que acha que eles não decolaram como deveriam?
00:48:10- Eu sempre fui muito conservador a respeito,"
00:48:14sou cético desde o primeiro dia.
00:48:17Por isso nunca cogitamos implementar
00:48:20algo parecido no Vue.
00:48:23A questão fundamental é: qual problema exato
00:48:28eles tentam resolver?
00:48:30Acho que houve muita pressão, sabe?
00:48:35Para empolgar as pessoas,
00:48:38foi vendido como a solução definitiva.
00:48:40Que seria a melhor coisa do mundo.
00:48:42Que deixaria todos os sites mais rápidos.
00:48:44Quando chegou, as pessoas viram que,
00:48:48talvez não devessem usar em todos os casos.
00:48:51Só beneficia certos tipos de cenários.
00:48:54Em outros casos, é apenas uma troca de problemas.
00:48:56Pois as partes que ficam no servidor
00:48:59exigem que todas as interações façam
00:49:04uma viagem de rede (round trip).
00:49:06E isso é muito bom...
00:49:08ou melhor, muito ruim para experiências offline-first.
00:49:10E você não consegue escapar totalmente do custo de hidratação,
00:49:14na minha opinião.
00:49:20Você está apenas deslocando o custo de hidratação do cliente.
00:49:21Está jogando isso para o servidor, certo?
00:49:26Agora, em cada requisição,
00:49:29você faz mais trabalho no servidor.
00:49:31Existem teorias da conspiração dizendo que
00:49:33a Vercel está empurrando isso para vender processamento.
00:49:38Não acho que seja isso, sabe?
00:49:44Mas é verdade que usar RSC
00:49:47significa mais carga no servidor.
00:49:51Você roda mais coisas lá,
00:49:52usa mais minutos de computação.
00:49:54No fim, há outros benefícios, como:
00:49:56se você coloca parte das coisas no servidor,
00:49:59economiza no tamanho do bundle.
00:50:01Mas há várias formas de resolver esse problema
00:50:02que não envolvem necessariamente
00:50:06ter que rodar um servidor Node.js, certo?
00:50:07Isso é só a minha opinião pessoal.
00:50:10No frontend, costumamos dizer:
00:50:14"a arquitetura realmente importa".
00:50:17Você quer usar uma SPA?
00:50:19Precisa de server-side rendering?
00:50:21O RSC é ainda mais específico.
00:50:24Saber se você precisa de RSC é uma pergunta importante
00:50:27e muito difícil de responder.
00:50:31E quando você diz sim,
00:50:33também precisa estar ciente do preço que vai pagar.
00:50:35Acho que um dos motivos para não ter tido
00:50:37uma adoção em massa é que, primeiro,
00:50:39é extremamente complicado.
00:50:43O conceito em si é difícil de explicar.
00:50:46Como funciona é difícil de explicar.
00:50:48Tivemos que ir muito fundo
00:50:50porque exige uma orquestração no nível da ferramenta de build
00:50:52para que todo o sistema funcione, entende?
00:50:56Muito poucas pessoas realmente entendem
00:50:58como o RSC puro funciona.
00:51:02A maioria conhece através da implementação
00:51:04do Next.js, porque o RSC puro é algo que um desenvolvedor comum
00:51:07não conseguiria configurar sozinho, sabe?
00:51:11É preciso entender como as peças se encaixam
00:51:14para conseguir montar algo do zero
00:51:17apenas com React e Vite ou Webpack.
00:51:20Não é para o dia a dia do desenvolvimento comum.
00:51:23Você vai querer usar um framework.
00:51:27Foi para isso que ele foi feito.
00:51:29Mas para usar RSC em um framework,
00:51:30o framework precisa tomar decisões de design
00:51:33sobre como apresentar o RSC
00:51:36de uma forma que ofereça uma boa DX.
00:51:39E eu acho que o Next.js não acertou nisso.
00:51:42Toda essa confusão de "use server", "use client",
00:51:47o grafo misto onde, ao definir algo como "use server",
00:51:51outras coisas param de funcionar.
00:51:55Você fica limitado a usar apenas certas coisas,
00:51:58aí precisa importar uma dependência
00:52:01e ela não funciona com "use server".
00:52:03Aí você tem que voltar para o "use client" de novo.
00:52:06Esse vai e vem,
00:52:08esses pequenos incômodos na DX
00:52:10fazem as pessoas pensarem: "ok",
00:52:12"para ter esses benefícios prometidos,"
00:52:15"agora tenho que aguentar essa chateação de DX"
00:52:20"o tempo todo, para sempre?"
00:52:24"Será que vale mesmo a pena?"
00:52:27É compreensível que as pessoas fiquem em dúvida.
00:52:28Até para autores de frameworks...
00:52:35a Vercel tinha essa relação muito próxima com o time do React
00:52:37para colaborar e iterar rápido.
00:52:40Mas para terceiros... eu nem diria terceiros
00:52:42porque, tecnicamente, a Vercel é um terceiro, né?
00:52:45Mas para outros frameworks como Remix e TanStack,
00:52:49não é nada simples trabalhar
00:52:52nesse problema, porque as iterações de API
00:52:57do time do React priorizavam o Next.js.
00:53:02Não estou criticando, pois
00:53:06a Vercel é o parceiro de design deles.
00:53:08Eles querem essa parceria
00:53:13para polir o recurso e lançar,
00:53:15o que faz sentido, né?
00:53:17Mas, por causa disso,
00:53:19o Next.js era basicamente a única forma real
00:53:21de usar RSC.
00:53:25E essa experiência não tem sido incrível.
00:53:29Por isso não deu tão certo quanto poderia.
00:53:31E também acho que, mesmo em um mundo ideal,"
00:53:33com uma DX perfeita para o RSC,
00:53:38ainda não acho que seria a solução para tudo.
00:53:41É preciso entender muito bem
00:53:46onde faz sentido e onde não faz.
00:53:49São muitas concessões.
00:53:50- Imagino que não houve pressão
00:53:52para implementar algo assim no Vue,
00:53:54pois a ligação volta para a Vercel.
00:53:57Eles compraram a NuxtLabs,
00:53:59que é o meta-framework sobre o Vue.
00:54:01Como tem sido a relação entre o Nuxt e o Vue
00:54:03agora que a Vercel é a dona?
00:54:05- Sinceramente, não mudou muita coisa.
00:54:08A Vercel tem sido bem discreta desde a aquisição,
00:54:09então o time do Nuxt está feliz por poder
00:54:13continuar fazendo o que já faziam.
00:54:14Provavelmente há esforços para
00:54:18fazer o Nuxt rodar melhor na Vercel,
00:54:21torná-lo um cidadão de primeira classe.
00:54:24Mas a Vercel tem consciência
00:54:25da imagem que tem na comunidade
00:54:30e eles são cuidadosos para não prejudicá-la ainda mais.
00:54:32Então, após comprar o Nuxt,
00:54:34a última coisa que fariam
00:54:38seria forçar o Nuxt a fazer coisas que as pessoas não gostam.
00:54:43- Infelizmente, o Evan teve que sair mais cedo
00:54:47para uma ligação importante,
00:54:50mas agradecemos muito pelo tempo dele
00:54:52e pelas opiniões valiosas sobre todas as perguntas.
00:54:54Se você tiver sugestões de convidados para o podcast,
00:54:56deixe nos comentários.
00:54:58E se tiver qualquer feedback em geral,
00:55:00nos avise também.
00:55:04Adoraríamos ouvir.
00:55:06Nos encontre em qualquer plataforma de podcasts,
00:55:08como Spotify ou Apple Podcasts.
00:55:10Até a próxima, tchau!
00:55:11- Tchau de minha parte.
00:55:12- Tchau.
00:55:15- Foi um prazer, obrigado a todos.
00:55:17- Muito obrigado por nos acompanhar.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.