00:00:00(música animada) - Oi, pessoal.
00:00:06Sou a Lydia.
00:00:07Meu cargo é Diretora de Propaganda na BUN.
00:00:11E quem me conhece sabe que eu adoro falar sobre runtimes JavaScript e performance.
00:00:17Antes de entrar na BUN,
00:00:18trabalhei na Vercel por alguns anos ensinando desenvolvedores Next como construir aplicações mais rápidas.
00:00:24Então estou muito animada de estar aqui hoje e mostrar como fica muito melhor quando combinamos a Performance do Next Framework com a performance do runtime da BUN.
00:00:35Mas antes de falar sobre a BUN,
00:00:37quero dar um passo atrás e explicar o que torna frameworks como o Next.js tão especiais em primeiro lugar.
00:00:45Porque eles realmente redefinieron como vemos performance na web.
00:00:49Não foi só tornar websites mais rápidos.
00:00:52Simplificou cada parte do processo.
00:00:55Temos bundling inteligente com Webpack e agora com Turbo Pack.
00:00:59Temos otimização de imagem e fontes integradas.
00:01:02Temos renderização eficiente no servidor,
00:01:05renderização estática e agora ISR e também RSC para trazer busca de dados direto para o componente.
00:01:12E todas essas melhorias basicamente expandiram o que o framework consegue otimizar,
00:01:19mas só até certo ponto.
00:01:21Sempre houve uma camada fundamental que o Next.js não conseguiu otimizar ainda.
00:01:26E não é por falta de esforço de engenharia ou capacidade,
00:01:30mas simplesmente está fora do escopo do Next.
00:01:34E esse é o runtime em si.
00:01:37Normalmente quando você roda Next dev ou faz deploy na Vercel,
00:01:40sua aplicação Next roda em Node.
00:01:42Isso significa que o runtime do Node executa seu JavaScript.
00:01:45Gerencia o event loop, file IO, tudo.
00:01:49E conecta seu código JavaScript ao sistema operacional.
00:01:53E faz sentido porque Node tem sido o runtime padrão nos últimos 15 anos.
00:01:59É testado e confiável,
00:02:01mas em 2025,
00:02:03virou um pouco um gargalo.
00:02:06Não me entendam errado, Node é fantástico.
00:02:09Tornou possível rodar JavaScript no servidor.
00:02:13Antes disso, JavaScript era realmente só para o navegador.
00:02:20Node mudou tudo isso ao nos dar um runtime com engine JavaScript,
00:02:24um event loop,
00:02:25async IO e APIs para fazer tudo que browsers não conseguem.
00:02:29Como ler arquivos do disco, memória, tudo isso.
00:02:33Internamente, Node usa a engine JavaScript V8.
00:02:37Essa é a rápida engine Chrome do Google,
00:02:39que é ótima para tarefas longas,
00:02:41como uma aba no seu navegador Chrome.
00:02:44Mas é claro, V8 é só uma engine.
00:02:46Ela só sabe executar JavaScript.
00:02:49Não consegue abrir arquivos,
00:02:52fazer conexões TCP,
00:02:53essas coisas.
00:02:54Aí é que entram as APIs nativas do Node.
00:02:57Como FS, HTTP, NET, e por aí vai.
00:03:01Essas APIs são tipo a ponte entre nosso código JavaScript e o sistema operacional.
00:03:07E essas APIs dependem de uma biblioteca C chamada libuv.
00:03:13Isso não foi construído pro JavaScript em si.
00:03:16É mais uma abstração genérica que Node usa pra fazer coisas como file IO,
00:03:22networking,
00:03:23essas coisas em diferentes sistemas operacionais.
00:03:27Então quando a gente chama algo como fs.readFile no nosso código JavaScript,
00:03:32estamos pedindo pro computador que leia esse arquivo do disco.
00:03:36Mas antes de chegar lá,
00:03:38tem que passar por V8,
00:03:39ou melhor,
00:03:40do código JavaScript para V8.
00:03:42Depois passa pro binding C++ do Node.
00:03:46Que aí chama libuv,
00:03:47e nem estou mencionando o trabalho de threads e todo aquele overhead.
00:03:52E só aí libuv faz a chamada do sistema ao kernel pra realmente pegar esse arquivo do disco.
00:03:58E enquanto tudo isso acontece,
00:04:00tem o event loop que libuv usa para que o resto do nosso código JavaScript consiga executar e por aí vai.
00:04:06E esse modelo funciona bem.
00:04:08A gente ainda usa Node, mas não é ótimo.
00:04:13Voltando a 2009,
00:04:14quando Node foi introduzido,
00:04:16nosso hardware era muito diferente.
00:04:19Servidores talvez tivessem uns quatro núcleos,
00:04:22memória limitada,
00:04:23e armazenamento era bem lento.
00:04:25Threads também eram caros,
00:04:27então criar uma nova thread pra cada conexão simplesmente não escalava bem.
00:04:32Então o modelo do Node era ótimo pra essa época porque a gente conseguia usar uma thread pra lidar com milhares de conexões bem eficientemente.
00:04:40Mas avançando para 2025, nosso hardware é muito diferente.
00:04:44Agora temos centenas de núcleos de CPU,
00:04:46terabytes de memória,
00:04:48e armazenamento é tipo 50 vezes mais rápido.
00:04:51Mas ainda estamos usando o modelo do Node baseado em 2009.
00:04:55Ainda empurrando tudo pelo mesmo event loop.
00:04:59E de novo, tudo bem.
00:05:00A arquitetura do Node é ok quando servidores rodavam por dias.
00:05:04Mas nos tempos modernos,
00:05:05muitas vezes temos serverless functions ou dev servers.
00:05:09Tudo isso de scripts mais curtos que precisam iniciar rápido e rodar por muito menos tempo.
00:05:16Então nesses ambientes,
00:05:18cada milissegundo de inicialização e cada camada de dados importa porque somam latência.
00:05:24Agora de novo,
00:05:26quando você roda sua app Next,
00:05:30está rodando em Node.
00:05:34Isso significa que tudo que sua app faz,
00:05:36como renderizar páginas,
00:05:37servir assets,
00:05:38fazer streaming de respostas,
00:05:40tudo passa por essas camadas que vimos.
00:05:43Então de JavaScript pra V8 pra Node, tudo essas coisas.
00:05:46E o Next fez um trabalho incrível espremendo cada bit de performance apesar do runtime Node ainda bloquear certas coisas.
00:05:57Porque no final,
00:05:58todas essas melhorias ainda rodam em cima do Node.
00:06:01Então quando você liga um dev server ou reconstrói arquivos,
00:06:05hot reloading,
00:06:06você ainda bate nos limites do runtime.
00:06:09Então se a gente realmente quer ir mais rápido,
00:06:11tem que olhar além do framework.
00:06:13Tem que ir um nível mais profundo.
00:06:15Tem que repensar o runtime em si.
00:06:18E aí é que entra a BUN.
00:06:20BUN não é só outra camada em cima do Node.
00:06:24É um brand new runtime construído do zero pro hardware que realmente temos em 2025.
00:06:33Então em vez de ser escrito em C++ em cima de LibUV como você viu com Node,
00:06:38BUN é construída em Zig.
00:06:40E essa é uma linguagem de sistemas moderna que roda muito mais perto do metal.
00:06:45Pra engine JavaScript,
00:06:47BUN usa a super rápida engine JavaScriptCore da Apple.
00:06:51E ela inicia muito rápido,
00:06:53principalmente porque consegue adiar algumas otimizações de inicialização que engines como V8 fazem.
00:06:59E também roda muito rápido,
00:07:01o que de novo é perfeito pra tarefas modernas que usamos agora com dev servers,
00:07:07ambientes serverless,
00:07:08e esses scripts mais curtos.
00:07:10O core do runtime em si é escrito em Zig.
00:07:13Então as APIs da BUN e todas as partes que lidam com async I/O.
00:07:17Então onde Node usa LibUV pra todas essas operações async,
00:07:22como ler arquivos,
00:07:23requisições de rede,
00:07:25e por aí vai,
00:07:26BUN consegue implementar como chamadas diretas do sistema operacional porque é escrito em Zig.
00:07:33Agora pra requisições de rede,
00:07:35a gente usa uSockets,
00:07:36então é um pouco diferente.
00:07:37Mas a gente está removendo tantas camadas de abstração usando Zig em vez de LibUV.
00:07:44Então agora se você quer ler um arquivo com o runtime BUN,
00:07:47claro que passa do seu código JavaScript.
00:07:49Passa pra engine JSC direto pra Zig,
00:07:52que aí faz a chamada direta do sistema.
00:07:55Então de novo,
00:07:56menos camadas entre nosso código JavaScript e o sistema operacional de verdade.
00:08:01E o resultado é que tudo é muito mais rápido,
00:08:04desde inicialização até acesso a arquivos,
00:08:07servidores HTTP,
00:08:08e por aí vai.
00:08:09Mas BUN não é só sobre performance.
00:08:12A gente também tem como objetivo ser 100% compatível com Node.
00:08:15Então a gente quer garantir que todas as APIs próprias do Node funcionem.
00:08:19Mas também vem com toneladas de APIs nativas extras,
00:08:23como S3,
00:08:24SQL,
00:08:24Squeel,
00:08:25como você quiser chamar.
00:08:27Redis, hashing, shell, muita coisa.
00:08:30E se você já usou outras linguagens de programação,
00:08:34como Go ou Python,
00:08:35essa abordagem batteries-included é bem familiar.
00:08:39Mas como desenvolvedores JavaScript,
00:08:41a gente só ficou acostumado instalando dependências pra praticamente tudo.
00:08:45Uso password hashing em quase todas as minhas apps.
00:08:48Mas ainda tenho que instalar uma dependência toda vez que uso.
00:08:52Então BUN muda isso.
00:08:54As coisas que você usa praticamente o tempo todo já estão integradas no runtime.
00:08:59Já está no global.
00:09:01E de novo,
00:09:02não são só wrappers de superfície em cima de uma dependência NPM.
00:09:06São realmente construídas em Zig.
00:09:08Então são otimizadas pra performance pro hardware moderno.
00:09:12Então por exemplo, BUN tem um cliente SQL integrado.
00:09:16Então você consegue conectar direto em Postgres,
00:09:20MySQL,
00:09:20e SQLite usando uma única API.
00:09:23Você não precisa instalar nenhuma dependência adicional.
00:09:26E de novo, não é só chamar algum pacote NPM.
00:09:30É realmente BUN conversando direto com o sistema.
00:09:35E não é só conveniência que a gente tem essas coisas integradas.
00:09:38As opções da BUN geralmente são muito mais rápidas que as alternativas Node e NPM.
00:09:44Então por exemplo,
00:09:45BUN.SQL é até 11 vezes mais rápida que MySQL 2 em Node,
00:09:50que é bem legal.
00:09:51Ou você pode usar tipo o cliente S3 da BUN.
00:09:54E isso funciona out of the box com qualquer armazenamento compatível com S3.
00:09:58Amazon S3, Supabase Storage, Cloudflare R2, você escolhe.
00:10:03E de novo, essa API também é incrivelmente rápida.
00:10:06Então aqui,
00:10:07a gente vê que é até tipo 6 vezes mais rápida que AWS S3 SDK em Node.
00:10:12Agora é claro,
00:10:13você ainda consegue usar suas dependências normais com o runtime BUN também.
00:10:17Você não precisa usar essas APIs nativas.
00:10:20Mas elas reduzem seu bundle size bastante,
00:10:22porque não estamos adicionando mais essas dependências.
00:10:25E ajuda com vulnerabilidades NPM que a gente viu tipo no mês passado,
00:10:30porque você não precisa instalar.
00:10:32Tem muito mais APIs.
00:10:33Eu recomendo muito que você confira a documentação também.
00:10:37Mas BUN vem com bem mais que só um runtime.
00:10:40Também vem com um gerenciador de pacotes super rápido que é até 17 vezes mais rápido que YARN,
00:10:477 vezes mais rápido que NPM,
00:10:49e 4 vezes mais rápido que PNPM.
00:10:51E o bom é que você não precisa usar o runtime BUN pra usar BUN install.
00:10:55E isso é só... você consegue usar BUN install com Node.
00:10:58Só funciona.
00:10:59Então você não precisa mudar nada do seu projeto.
00:11:03Também tem um bundler integrado super rápido e transpiler.
00:11:06Então você consegue servir e construir seus arquivos instantaneamente.
00:11:09Então não precisa de Webpack, ESBuild, sem setup extra.
00:11:12E o legal é que também suporta TypeScript e JSX direto da caixa.
00:11:18Também tem um test runner super rápido que é até 14 vezes mais rápido que Vitest e 23 vezes mais rápido que Jest quando a gente rodava tipo 1.000 testes React.
00:11:26Então de novo, você consegue testes super rápidos.
00:11:29Não precisa instalar nada.
00:11:31Então tudo isso soa ótimo,
00:11:33mas como a gente consegue usar o runtime BUN?
00:11:35E Next, honestamente, é bem simples.
00:11:38Depois de instalar BUN,
00:11:39você só precisa atualizar seu comando start ou dev command e adicionar bun run --bun.
00:11:45Pronto.
00:11:46Agora você está rodando o runtime BUN.
00:11:48Agora você pode estar se perguntando,
00:11:50por que preciso dessa flag --bun?
00:11:51Como assim, já estou dizendo bun run.
00:11:54Isso,
00:11:54de novo,
00:11:55é porque BUN realmente se importa com compatibilidade com Node.
00:11:57Então normalmente,
00:11:59se a gente usa só bun run next dev,
00:12:02BUN vai detectar que next CLI usa aquele shebang do node.
00:12:07E nesse caso,
00:12:07BUN vai tipo,
00:12:08OK,
00:12:09entendi que preciso usar Node.
00:12:11Então vai voltar pro Node,
00:12:13mesmo que a gente tenha dito bun run.
00:12:15Mas com a flag --bun,
00:12:16a gente está forçando aquilo a pular o shebang e dizer,
00:12:19OK,
00:12:20a gente está só usando o runtime bun.
00:12:21Então é só uma explicação extra.
00:12:25Então agora com esse comando,
00:12:27bun inicia seu servidor next dev.
00:12:29O bundler em si ainda é Next.
00:12:31Então é tipo, você sabe, Turbo Pack.
00:12:33Acho que Webpack, Turbo Pack, agora é o padrão.
00:12:35Mas agora o runtime em baixo de tudo aquilo,
00:12:38então a coisa que está executando seu JavaScript,
00:12:40lendo arquivos,
00:12:41servindo respostas,
00:12:42e por aí vai,
00:12:43tudo isso é bun.
00:12:44E porque bun é desenhado pra ser compatível com Node,
00:12:47você não deveria ter que mudar nada do seu código.
00:12:50Ou seus pacotes ou seu middleware.
00:12:51Tudo deveria continuar funcionando.
00:12:53Se não funcionar, isso também é considerado um bug em bun.
00:12:57Deveria ser 100% compatível com Node.
00:12:59Então se você está testando isso e esbarra em problemas,
00:13:02nos avisa.
00:13:02Mas você não deveria ter que reescrever nada.
00:13:05E agora que sua app roda em cima de bun,
00:13:07você consegue acessar todas as APIs nativas da bun.
00:13:10Então por exemplo,
00:13:11a gente consegue usar o cliente S3,
00:13:13tipo,
00:13:13em uma server function,
00:13:14em um React Server Component,
00:13:16e por aí vai.
00:13:16Então não precisamos instalar nenhuma dependência.
00:13:18Então só pra comparar como normalmente seria com Node,
00:13:22você consegue ver que com bun,
00:13:23a gente tem muito menos código.
00:13:25Menos dependências.
00:13:27E é instantaneamente compatível com todos os outros provedores S3 também.
00:13:32Então se você quer trocar de Amazon S3 pra tipo Cloudflare R2,
00:13:36Supabase Storage,
00:13:37todos esses outros provedores,
00:13:39é super simples.
00:13:40Ou algo mais completo,
00:13:42a gente consegue usar S3,
00:13:43bun shell,
00:13:44e SQL direto em um React Server Component.
00:13:47Então primeiro,
00:13:48a gente tipo consulta o banco de dados com SQL pra pegar um blog post,
00:13:52gera uma URL S3 presignada pra imagem,
00:13:54usa bun shell pra contar as palavras.
00:13:57De novo,
00:13:57não tem nenhuma camada de API extra ou ferramentas de terceiros que bun esteja chamando.
00:14:02Bun lida com o runtime,
00:14:03conexões de banco de dados,
00:14:05e shell tudo nativamente em Zig,
00:14:08bem perto do metal.
00:14:10E de novo, claro, não é só S3 SQL.
00:14:12A gente consegue acessar todas as APIs de bun simplesmente adicionando bun run --bun na frente de next dev.
00:14:20Mas claro,
00:14:21agora você pode estar pensando,
00:14:22OK,
00:14:23não estou usando Postgres.
00:14:24Não estou usando S3.
00:14:25Não estou usando nenhuma dependência maluca,
00:14:27então por que deveria me importar?
00:14:28O que me levou pra bun antes de entrar era honestamente só a incrível DX.
00:14:34Você consegue rodar qualquer arquivo JS,
00:14:37TS,
00:14:38TSX,
00:14:38JSX,
00:14:39não importa,
00:14:39sem nenhuma configuração.
00:14:41Só funciona.
00:14:41Você não precisa pensar em TSNode, Babel, SWC, e por aí vai.
00:14:46Então mesmo que você não esteja usando Next,
00:14:49mesmo que esteja só desenvolvendo,
00:14:51quer um script de build rápido,
00:14:53só usa bun run,
00:14:54só tenta,
00:14:54faz sua vida muito melhor porque você não precisa de nenhuma configuração.
00:14:59Bun também vem com bun x.
00:15:01E esse é o equivalente de bun pro NPX.
00:15:04De novo, você não precisa mudar nada.
00:15:06Você não precisa usar o runtime bun pra isso.
00:15:08Você consegue só trocar NPX por bun x.
00:15:11E você vê melhorias instantâneas de inicialização.
00:15:13Então por exemplo,
00:15:15usar bun x create next app é tipo 5 vezes mais rápido que NPX create next app.
00:15:20E de novo, você não precisa usar o runtime bun pra isso.
00:15:23É só muito mais rápido.
00:15:25Mas claro,
00:15:26tem também bun install,
00:15:28que de novo,
00:15:28não requer você mudar o runtime.
00:15:31Só faz seus installs muito mais rápido,
00:15:34também em projetos básicos Next.
00:15:36Agora óbvio, rodar bun localmente é uma coisa.
00:15:39Mas como a gente faz deploy de apps que rodam em bun?
00:15:42Porque isso é, claro, um runtime completamente novo.
00:15:46Agora você já consegue usar Next.js em bun em varias plataformas como Render,
00:15:51Railway,
00:15:52ou containerizar sua app com Docker.
00:15:54Mas a gente todos somos desenvolvedores Next.js.
00:15:56Idealmente,
00:15:57a gente também quer conseguir fazer deploy pra Vercel.
00:16:00Então naturalmente,
00:16:02tweetamos pro Guillermo,
00:16:03pedindo educadamente por suporte nativo bun na Vercel.
00:16:07E rapidinho a gente recebeu uma resposta bem promissora.
00:16:10E aí umas semanas depois,
00:16:12suporte a bun foi alcançado,
00:16:14pelo menos internamente.
00:16:15Então estou muito animada que suporte nativo a bun vai chegar na Vercel muito,
00:16:20muito em breve.
00:16:20E isso significa que você vai conseguir-- [APLAUSOS]
00:16:25Os aplausos vão pros ótimos engenheiros da Vercel que tornaram isso possível.
00:16:29Mas isso é muito emocionante porque significa que agora a gente consegue rodar apps bun tão fácil quanto qualquer outro projeto Next na Vercel.
00:16:37Então também é um exemplo do mundo real.
00:16:39Não sei se você consegue ver na tela.
00:16:41Mas rodando uma HONO API com bun já viu uma queda de 30% ou uma queda de CPU só rodando bun na Vercel.
00:16:49Isso é, claro, um framework diferente.
00:16:50Isso é HONO API.
00:16:52Mas são os mesmos benefícios de runtime que você vai receber se isso fosse tipo uma server function,
00:16:56RSC,
00:16:57e por aí vai.
00:16:57Porque bun economiza muito em CPU e uso de memória.
00:17:02Agora a gente,
00:17:02claro,
00:17:03não precisa esperar por suporte nativo a bun pra começar a usar em nossas apps.
00:17:06O jeito mais simples é tipo começar a usar ou adotar incrementalmente.
00:17:11Então primeiro, eu recomendo só trocar pra bun install.
00:17:14Não muda nada na sua codebase.
00:17:16Isso só usa o gerenciador de pacotes super rápido da bun.
00:17:19Também,
00:17:19se você estiver interessado em saber por que bun install é tão muito mais rápido,
00:17:22eu escrevi um artigo sobre isso não muito tempo atrás.
00:17:24Eu recomendo muito que você confira.
00:17:26Só explica...
00:17:27sabe, a gente não está só pulando passos..
00:17:29A gente está fazendo tudo.
00:17:29Tipo explica a engenharia de sistemas por trás que faz isso muito mais rápido.
00:17:35Agora depois de usar bun install,
00:17:37aí tenta usar o runtime bun.
00:17:39Você consegue só usar localmente com bun run --bun.
00:17:42Testa sua app.
00:17:42Vê se tudo funciona.
00:17:44Deveria funcionar.
00:17:45Se não funcionar, nos avisa.
00:17:47E depois,
00:17:48você consegue meio que incrementalmente se mover pra APIs nativas da bun onde faz sentido.
00:17:53Você consegue,
00:17:54claro,
00:17:54ainda misturar e combinar essas dependências NPM.
00:17:57Mas a melhor parte é também que cada passo aqui é reversível.
00:18:00Então se você usou uma das APIs nativas de bun e não funcionou,
00:18:04você consegue sempre só voltar pro Node.
00:18:06Mas é definitivamente worth checking out.
00:18:08Agora antes de terminar essa talk,
00:18:10eu só quero dar um muito obrigado enorme pro incrível time de engenheiros na bun.
00:18:17Muitas pessoas podem conhecer Jared,
00:18:19mas tem um time inteiro por trás de bun que trabalha tão duro todo dia pra fazer bun ainda mais rápido,
00:18:24mais estável,
00:18:25e muito mais divertido de usar.
00:18:27Eles estão realmente empurrando os limites do que é possível com JavaScript.
00:18:32Então Next reimaginou como a gente constrói pra web,
00:18:35mas bun reimagina o que a alimenta.
00:18:38Muito obrigada por vir na minha talk,
00:18:40e estou tão animada pra ver o que vocês vão construir com bun e Next.