Você sabe como funciona e como evoluíram os browsers? | PPT Não Compila Podcast
Convidados
Clauber Stipkovic
🖥️ No episódio de hoje do Podcast PPT Não Compila recebemos Clauber Stipkovic para um mergulho no fascinante universo dos browsers. Vamos explorar a história desde o pioneiro Mosaic até os modernos navegadores como Chrome e Firefox, passando pelas intensas batalhas entre Netscape e Internet Explorer 🔍 Durante esse bate-papo recheado de curiosidades, você vai descobrir como esses navegadores evoluíram, como suas engines de renderização funcionam e a importância da integração de JavaScript, HTML e CSS no desenvolvimento web. Quer saber como o web assembly está revolucionando a forma como interagimos com as aplicações? Então esse episódio é para você. ⚙️ Não perca a chance de entender melhor essa tecnologia que está em todos os seus dispositivos! Deixe seu like, comente o que achou e compartilhe com seus amigos. Ajude-nos a crescer! 🔗 Se inscreva no nosso canal e siga-nos no Spotify também! #Podcast #PPTNãoCompila #Browsers #TecnologiaWeb Convidados: Clauber Stipkovic : linkedin.com/in/cstipkovic/ Spotify: https://bit.ly/3V0KeHb Youtube: https://youtu.be/ToRlsxk9Esc Outras plataformas: https://linktr.ee/pptnaocompila Acompanhe nas redes Instagram e Twitter: @pptnaocompila LinkedIn: https://www.linkedin.com/company/pptnaocompila Produção: Voz e conteúdo | https://www.vozeconteudo.com.br - @estudiosvoz
- Contexto do Firefox e Netscape
- Nascimento do Chrome e Web moderna
- Browser como ambiente de execução
- Introdução do Podcast e Marcos
- Tema do Episódio: Funcionamento do Browser
- Escopo do Episódio: História e Tecnologias Web
- Transição para o conteúdo principal
- Chamada para Ação e Apoio ao Podcast
- Retrospectiva: Primórdios da Web
- Servidores Estáticos e CGI
- Humor e Experiência com CGI
- Evolução do HTML e JavaScript
- Browsers Pioneiros: IE e Netscape
- Primeira Guerra dos Browsers
- A Era Flash e Estagnação da Web
- Origem do JavaScript e Brendan Eich
- Netscape, Mozilla e o Código Aberto
- Documentário e a História do Mozilla
- Genealogia dos Browsers: Mosaic
- Mozilla como "Mosaic Killer"
- Herança de Código e Motores de Renderização
- Engines de HTML, CSS e JavaScript
- Windows Explorer como Browser
- Arquitetura e Reusabilidade no Explorer
- Famílias de Browsers: IE vs. Netscape/Mozilla
- Evolução do Mozilla e Nomenclatura
- Versionamento de Browsers Modernos
- KHTML e o Nascimento do Safari
- Safari e Sistemas Unix-like
- História do Opera Browser
- Criação do Chrome e Chromium
- Anúncio: Clever (Criptomoedas)
- Domínio do Chromium e Safari Isolado
- V8 como Padrão e Interoperabilidade
- Padronização W3C e JScript da Microsoft
- Google e Padrões Próprios
- Impacto do jQuery na Evolução do JavaScript
- Funcionamento Interno do Browser: DOM
- Document Object Model (DOM) e HTML
- DOCTYPE, Parsing e Árvore de Sintaxe
- CSS, JavaScript e o DOM
- Shadow DOM e Frameworks Modernos
- Paralelismo no Browser e Shadow DOM
- Explicação do Shadow DOM Detalhada
- Assincronicidade e Ferramentas Frontend
- Desenvolvimento Front-end com IA
- Evolução da Estrutura de Código Frontend
- Anúncio: VMBERS (Desenvolvimento de Software)
- Browsers e Compilação Just-In-Time (JIT)
- JIT, AST e Paralelismo JavaScript
- História do AJAX e Web 2.0
- Otimização de Engines e Rust
- Browser como Mini Sistema Operacional
- Chromebooks e Aplicações Web Nativas (Electron)
- Comparativo com JVM e Tecnologias Web
- Aplicações Gigantes no Browser e WebAssembly
- WebAssembly: Binário no Browser
- Dúvida sobre Execução de Binários no Browser
- JS Engine e Execução de Binários
- Origem do WebAssembly (ASM.js)
- Transição de JavaScript Estendido para WebAssembly
- WebAssembly: Código Pré-Compilado e Sandbox
- Funcionamento do WebAssembly e JavaScript
- Especificação W3C e Segurança do WebAssembly
- Formatos WASM e WAT
- Resumo: JIT vs. WebAssembly
- Uso do WebAssembly para Performance em Computação
- Exemplo: Photoshop Online e Latência
- WebAssembly para Tarefas Computacionais (não UI)
- Vantagens do WebAssembly: Latência e Custo
- Exemplo: Decodificação de Vídeo da Netflix
- Exemplos: Games (Unity, Unreal) e Design (Figma)
- WebAssembly e Inteligência Artificial (TensorFlow.js)
- Mercado de Trabalho e Linguagens para WebAssembly
- Importância de Conhecer a Base da Web
- Agradecimentos e Chamada Final para Ação
Quem tiver curiosidade aí baixar o código do Firefox hoje você tem muita função lá dentro que começa com NS ponto, que é da época do Netscape. Ainda ainda tem muita função lá dentro perdida assim. Isso aí entra o Chrome um na jogada. Então você tem mais um browser ali para >> que dá origem ao Chrome do Google.
>> Baseado nessas nessa trincazinha de JavaScript, HTML, CSS, você consegue botar as coisas por debaixo dos panos, renderizar aqui e só mostrar. Eu não consigo assimilar.
Como que a camada de cima executa se ela deveria estar na camada de baixo para ser interpretada pelo sistema operacional? Porque quea um binário, não vou chamar de máquina virtual, mas a gente criou um environment.
>> Sim, sim.
>> Que a gente consegue sair até de dentro do browser, como o Electron, >> para executar aplicações locais.
>> Muito bem. Muito bem, meus amigos do PPT não compil. Estamos aqui para mais um episódio.
>> Mais um, >> mais um, >> mais um.
>> Quase 200, cara. Quase, quase.
>> Na beola dos 200.
>> Na berola ali, ó. Falta pouquinho, hein.
>> E, e a nossa editora soprou o número, hein? Que a gente não sabia. Tem que revelar isso aqui.
>> Exatamente. Eu não achava que ia chegar no 10, >> não. Olha só, hein.
>> E estamos aqui já, hein, cara. Olha só que 10 e um zerinho aí.
>> É, estamos durando. Estamos durando, Glob, cara. Eh, hoje a gente vai falar de um assunto >> Uhum.
>> Que tá na máquina de todo mundo.
>> Sim.
>> Né? e que muita gente sabe que não não sabe como funciona, não >> tá no celular, tá na no na no tablet, tá no computador.
>> É isso aí. O cara às vezes desenvolve para essa parada e não sabe exatamente como funciona, né?
>> Então você, como é um cara que passou anos na Mozila, >> bastante, >> conhece como isso funciona de dentro, cara, achei muito legal a gente fazer esse episódio aqui para falar pra galera >> como que funciona um browser por dentro.
>> Exatamente. A gente vai vir desde lá do comecinho, porque tudo precisa de contexto, né? Exatamente. E fala até das tecnologias mais novas até rodar >> assembler direto no browser, né? Como é que essa [ __ ] funciona, mano?
>> Vamos falar sobre isso hoje.
>> É isso aí. Vamos falar sobre como desenvolve eh como que como que funciona o teu o framework front end que você tá rodando na tua máquina, como que o JavaScript é é interpretado, o CSS, o HTML, o que que o HTML, cara?
Vamos passar aqui. Se você gosta de entender como funcionam as coisas, se você gosta de tecnologia, esse episódio vai ser sensacional.
>> E para quem sabe, a gente vai lá no almoxarifado da web, né, da história da web e vamos trazer as coisas.
>> Vamos lá no baú pegar, >> tirar poeira, aquela, >> aquela lá no final, >> lá no finalzão do corredor.
>> Isso. Vamos explicar como que os browsers chegaram, ao que eles são hoje, como eles funcionam, né?
>> E dar um overview do que vem por aí de tecnologia, né? Então, se você gosta de entender como funciona a computação, esse episódio é para você, né, cara?
>> Exato.
>> E meu amigo, obrigado demais, Clubbert aqui para dar essa aula aqui pra gente.
Junto, só avisar.
>> Show de bola. Vamos lá que o episódio tá muito bom.
>> Bora.
>> Quer entender como funciona o seu browser? Acompanha a gente. Mas antes, deixa o seu like. Exato. Já aproveita, já tá aí, agora >> já abriu.
>> Deixa seu comentário, segue a gente no Instagram, no Spotify, dá cinco estrelinhas pra gente. Se você acha que o nosso trabalho traz para você uma evolução profissional, você pode ser membro do PPT no Compila. Exato.
>> Vai lá, contribui com uma cervejinha pra gente todo mês, né? Aqui, ó.
>> Isso aqui é pago pelos nossos membros.
>> Exatamente. Obrigado. Muito obrigado.
Obrigado, viu? Tá muito boa. Tá geladinha, galera. Obrigado. E você vai ajudar a gente aqui com com a nossa o nosso trabalho, com a nossa produção. Se você não pode ajudar dessa forma, você já ajuda demais compartilhando no Slack, mandando no grupo da família.
>> Uhum.
>> Não vão entender [ __ ] nenhuma, mas manda.
>> Bota no Twitter. Ex lá também.
>> Bota no Twitter.
>> Bota no Facebook.
>> Ex é o [ __ ] É Twitter o nome.
>> Twitter. Twitter.
>> Twitter.
>> Twitter. Bota no Facebook, >> TikTok. Faz tudo.
>> Isso. Ajuda a nossa comunidade a crescer que você já ajuda demais o PPT no Cupila, né? Vamos lá que o episódio está ótimo. Bora. Valeu.
[Música] >> Vamos fazer primeiro uma retrospectiva.
>> Vamos. Vamos puxar um pouquinho essa naftalina para cima, né?
>> Posso ir lá no fundo do baú e pegar aquela cueca velha lá do final do do fundo do baú.
>> Bora.
Primeira vez que eu lidei com desenvolvimento paraa web, a gente fazia o HTML puro.
>> Uhum.
>> Não se falava em JavaScript ainda ou eu não tinha conhecimento, né? Eh, tinha muito gif animado, >> tinha bastante os marquis, >> Marquis passando de um lado pro outro.
Basicamente você fazia um uma estrutura de HTML estático ali, HTML tabela não, quem que falava em tessag >> e aí para executar você geralmente tinha servidores que eram basicamente uns a paixão para servir estático gratuito.
>> Sim, sim.
>> Uns geosites da vida.
>> Uhum. Hum.
>> Lembra quem quem quem tem mais 40 mais aí lembra dosites?
>> Nossa, >> lembra do tinha coisas ainda em em CGI, né?
>> Então aí CGI tinha que pagar hospedagem paga.
>> CGI era meio um C, né?
>> É, o CGI era era é o pai do Server Side, né? Do >> Server Side Web, né? Sim, sim. que ele rodava ali um C e aí geralmente usava para mandar e-mail, né?
>> Cara, aqui aqui devia ser uma coxa de retalho porque eu lembro que você chamava o 100 de meio direto no CGI, cara. Ali >> é, eu não cheguei a mexer nessa época, mas nossa, >> tá me chamando de velho, isso >> não [Risadas] >> é que você começou antes ainda, né? É um pouquinho, um pouquinho. Minha barba tá só um pouquinho mais branca que a sua.
Pelo nível de brancura da barba, a gente percebe.
>> Eh, e isso, cara, foi assim o primeiro contato que eu tive assim com com néum.
>> E depois a gente começou a ter um um uma evolução natural. Aí já começava a ter uns um uns JavaScriptzinho, já tinha uns alerts, uns promptes, né? né? E aí, cara, eu acho que isso ainda era HTML 3.0, 3.1 ainda, né?
>> Não era nem HTML 4 ainda, não.
>> Era primeira.
>> É até uma pergunta, você lembra que browser que foi o que você usava nessa época, >> cara? O primeiro foi o I3 que eu usei.
>> Chegou a usar Netscape?
>> Cheguei a usar Netscape e Era o primeirão assim que era aquele que tinha um globinho ainda girando, lembra?
>> Sim, lembro. Era aquele bem rústico assim. Aí depois a gente começou a usar o o i3 porque já vinha no Windows 98.
>> Sim. Foi a época da guerra dos Browsers, né?
>> Foi a época da guerra dos browsers.
>> A primeira guerra dos browsers, né?
Porque teve a segunda. Depois a gente vai chegar lá. Mas >> que aí você tinha que desenvolver duas versões iguais, porque o o que rodava no IA não rodava no Netscape e Viceversa.
>> É. E tinha o selinho, lembra? Melhor. É.
É feito para Internet Explorer, feito para Netcape. Vi, vim uns alerts assim, tipo, acesse no Netscape, acesse no IA, né?
>> Não tinha, não tinha console, log, não tinha nada, era alert mesmo, >> não tinha modal, não tinha nada dessas coisas bonitas que a gente tem hoje.
>> Era uma coisa, cara, como a gente sobreviveu esse mundo, né?
>> E aí a gente começou a ter um um uma evoluçãozinha aí, JavaScript. E aí logo, eu acho que isso foi o que atrapalhou a vida da web, né? Queria até ouvir a tua opinião olhando pro pro timeline todo.
>> Uhum.
>> Por muito tempo a gente poderia ter evoluído para chegar no nível que nós temos hoje, que a gente tem um desenvolvimento web absurdo, né?
>> Sim, sim.
>> Eh, muito muito mais evoluído do que até então, né? Mas acho que a gente estagnou numa época por causa de um surto coletivo que a gente teve chamado Flash.
>> Foi, foi.
>> A gente não evoluía mais browser, não evoluía mais linguagem.
pra web praticamente.
>> Sim.
>> E aí era só S FLW, né, que era o extensão.
>> Isso, isso era FLW.
>> E você desenvolvia naquela desgraça. Eu programei em Flash. Caraca, tinha um script 3.
>> Sim, eu lembro que você comentou umas vezes já.
>> É, e era divertido, cara. Era divertido, né?
>> É o o se a gente der um passo para trás aí que você falou do do JavaScript, nessa época da guerra dos Browsers, né, EA Netscape, teve o Brandonike, que é o criador do JavaScript, né? Na verdade, ele criou uma linguagem eh, eu não lembro se era o ECMA Script, mas ele criou a linguagem em duas semanas, porque o pessoal foi assim, eu já conversei com ele >> e ele contando que ele falou: "Cara, eu precisava". O pessoal falou: "Você precisa criar um negócio pra gente botar no browser." E é isso.
>> Cara, eu não consigo escrever um e-mail em duas semanas. O cara fez uma linguagem, >> ele fez uma linguagem em duas semanas.
Aquela tem as as papagaiada até hoje, né?
>> Porque ele é esse cara e eu sou um >> É, hoje ele é o o o dono, entre aspas, do Brave, né?
>> Ele saiu da Mozila, enfim. Mas nessa época ele criou o JavaScript, que não chamava JavaScript ainda. E a questão do JavaScript ali, o Java na frente era para fazer analogia o Java, a linguagem, >> mas mesmo não tendo >> mesmo não tendo nenhuma ligação, porque era marketing, né? Ia ia fazer bem pra linguagem, ter um nome que já era conhecido, que era o Java na época.
>> Então o cara se trancou duas semanas.
>> Além de tudo, o cara é um gênio do marketing ainda.
>> É, foi a galera da Netscape ainda na época, né? que não era nemzila, entendi.
>> Então teve essa questão toda, aí teve a guerra dos browsers, a Netscape teve que abrir o código, na verdade não, eles optaram por abrir o código do browser e com isso surgiu Mozila e aí começou a surgir outras coisas, eh, que aí a gente já desemboca nessa questão de ter Firefox, ter >> Sim, >> há anos depois Chrome, >> que são os forks que, que nasceram daí, né? Isso. Eh, o Firefox, por exemplo, ele nasceu num fork do do Netscape por conta da briga judicial que teve lá.
Então, os caras forcaram, tem até um um vídeo muito legal de documentário no YouTube, se eu não me engano chama Internet Rush, que ele mostra essa época que o pessoal da Mozilla da Netscape ainda tava correndo atrás para poder lançar o o o Mozilla na época, não era nem Firefox ainda. E eles tinham que tirar código proprietário, tiveram que fazer um monte de coisa. Foi é bem interessante isso que o pessoal quiser procurar aí. É bem legal.
>> É, vamos abrir um parênteses aqui pra gente falar um pouco dessa árvore genealógica dos browsers que eu acho que é legal explicar, né?
>> A gente tinha o I >> e tinha o Netscape.
>> É, tinha um cara chamada chamado Mosaic antes, né?
>> Mosaic, velho. Pode crer que é tipo o a pedra fundamental do do dos browsers.
Mas o Mosaque ele é ele tem alguma ligação com Mozilo ou ele era só um cara isolado?
>> Se eu não tiver errado, a questão do do Mosaic, ele evoluiu para dentro do Netscape.
>> Hum.
>> Então ele é um ancestral do Netscape. É tanto que assim o Mozila, a o acrônimo Mozilla significa mosaic killer.
>> Ah, >> né? Então muita gente não sabe disso, mas era era essa. Nossa, >> pera aí. Era uma uma brincadeira que eles faziam de >> envolve letra. É porque o o o a Mozila eles queriam matar toda a herança que vinha do Mosaic.
>> Ah, tipo fazer um refecto.
>> Exato. Exato. Então assim, eles pegaram que já tinha do Netscape. Tanto que quem tiver curiosidade aí baixar o código do Firefox hoje, você tem muita função lá dentro que começa com NS PON, que é da época do Netscape. Ainda ainda tem muita função lá dentro perdida, assim, tem as novas coisas que eles estão implementando, mas muita coisa é a herança do código do Netscape. Então veio Mosaic Netscape e aí, né? Aí surgiu IE Mozila. Então foi >> o I nasceu sozinho com a Microsoft, >> né?
>> Então ele nasceu isolado, né?
>> É.
>> Tanto que a indine dele é diferente.
>> Isso aí. Tem tem outra máquina de transparç, >> se não me engano na época era o Presto.
Porque assim, o que que acontece? Os browsers eles têm ã endines separadas, né? Eles têm motores de renderização separados. Naquela época não, né?
Naquela época era provavelmente tudo um monolitão, né? A galera empacotava e vai. Isso.
>> Hoje em dia você tem os os as engines separadas. Você tem a engineerização do HTML, do CSS e do JavaScript.
>> Hum.
>> Né? Então assim, eh, >> são processos distintos >> são processos distintos. São. E por exemplo, a Indine do Firefox é a Spider Monkey. Ã, dentro do do I, hoje eu não sei se eles trouxeram, acho que não, porque eles eles migraram pra base do Chrome, né? Então, provavelmente é o V8, >> mas na época era o presto que era do do I, então acho que foi até o I10 ali, I11. Uhum.
>> Com essa engine que era na verdade a mesma engine que você usava no Explorer do do Windows.
>> [ __ ] mesmo.
>> Eles só adaptaram ali. Tanto se você digitasse lá, ele >> baixava as coisas. Verdade, verdade.
Você p, você abria o o Explorer, você botava o endereço web, >> ele ia >> e ele ele É verdade, >> eles meio que colocaram tudo junto ali.
>> Entendi.
>> Muito provavelmente, não sei, não conheço o código do do do Windows, mas provavelmente o que tem lá hoje ainda é risquício do dos caras lá atrás, né?
Não, mas se você parar pensar a >> renderização de de pasta e >> se você parar para pensar um princípio de desenvolvimento de abstração do software, faz todo sentido.
>> Sim. Sim. Eu abri uma pasta, abri uma página, eu vou mudar a renderização, mas eu posso ter um objeto abstrato suficiente >> para chegar em qualquer end point, >> seja local, seja remoto. Uhum. Porque na verdade você tem a barra de endereço ali. Que endereço? Não sei.
>> Exato. Pode ser um endereço local, pode ser um endereço web, pode ser um endereço FTP. Exato, >> né?
Hoje eu não sei mais como é que funciona isso, porque eu não uso Windows mais há muito tempo, mas você poderia colocar no próprio Windows Explorer, >> sim, >> uma URL FTP e você ser acessado. É, também não sei hoje mais como é que é o Windows.
>> Sei mais como é que funciona, mas é, >> a gente não usa mais Windows, >> mas era mais funcionava, então podia chegar no end point FTP, http >> ou file.
>> Sim, sim, >> né? Então do ponto de vista de arquitetura de software, >> reusabilidade e abstração. Perfeito.
>> Só era uma merda.
É, só era ruim pra Cilda, né? E lembrar que nessa época não tinha nem aba, né?
>> Não tinha aba, né?
>> Você ficava com uma barra de tarefa gigante, com um monte de janela do Windows de qualquer um deles.
>> Verdade. Sim.
>> Para poder ter isso aí, né?
>> Então, a gente teve duas famílias. Teve o Mosaic, >> Sim. Que foi o, entre aspas, o pai de todo mundo.
>> Isso. E aí derivou no Netscape.
>> Isso.
>> Em paralelo aqui nasceu o IE.
>> Sim, >> né?
>> Uhum. E o I foi evoluindo aí desde o primeiro até o último, que eu acho que foi o 12, >> se não engano foi o 11. Acho que foi o I11. É, >> eh, aqui em paralelo a gente teve o Netscape que foi evoluindo nas versões.
>> Sim, eu não lembro agora as versões do Netscape. Acho que foi até seis ou sete, não lembro.
>> É, eu também não lembro, >> mas desse do Netscape aí foi começou o Fork.
>> Isso.
>> Começou o Mozilla.
>> Aham. que foi a parte, entre aspas, opence do Netscape. E aí continuou, o pessoal eh eh parou, a Netscape não existe mais, né? Acabou e eles pararam de fazer o browser >> e aí continuaram só com o Mozilla.
>> Uhum.
>> Só que a Mozila, por ter virado depois uma fundação, eles separaram, né? Eles tinham a Fundação Mozilla e a Mozilla Corporation, as uma cuidadora virou uma holding, né? Uma mantenedora, digamos assim. Isso porque eh eh eles separaram porque às vezes precisava de alguma empresa formal mesmo ali corporation para poder cuidar dos interesses do browser e uma filantrópica para poder receber doação e tudo mais. Então eles dividiram em duas, >> mas com isso eles tinham algum problema de nome, alguma coisa assim que o browser não podia ter o mesmo nome. Eu não, essa parte eu não sei direito, é mais burocrática da coisa.
>> Uhum.
>> Mas aí eles começaram a e a trocar o nome do navegador.
>> Hum. né? Então, primeiro teve, se eu não me engano, foi o Firey Bird.
>> Firey Bird.
>> É que pessoal não era muito criativo, né?
>> O Fênix primeiro.
>> Fênix, eu lembro do fênix. Lembro do >> tinha, a gente acabava usando muito no Linux, né? Quando eles começaram, >> teve o o Fênix, aí depois foi o Firebird, mas tinha um banco de dados já como Firebird. E aí trouxeram Firefox, que foi o o browser depois. E é uma confusão do [ __ ] porque depois o Outlook >> virou Thunder ThunderBerbird. É >> vir Thunderbird, >> exatamente ol da Mozilla, né?
>> É, é o look da o par dail, >> isso que era como era o Outlook da Microsoft, né?
>> Isso. É.
>> Então, >> então, mas a gente teve ainda o browser Mozilla em algumas versões. Teve, era um Mozilão que a gente chamava. Aí virou o Fênix, >> isso.
>> Firebird >> e depois o Firefox. O Firebird não não era um que o bichinho parecia um Charizard assim.
>> Isso, isso, isso.
>> Eu lembro, eu lembro do Firebird.
>> É, >> mas foi muito rápida essa transição do Fenix pro Firebird e o Firefox. O Firebird ficou muito pouco tempo, né? E aí depois eu lembro até hoje a a o lançamento do Firefox 1.
>> Caraca, >> né? Então assim, >> tá tá em qual agora? Só para >> [ __ ] 100 e lá vai pedrada. Eles mudaram o esquema de de contagem igual o Chrome, né? Antes >> o Chrome tá em centro e [ __ ] também.
>> É. Aí o a Mozila adotou essa questão também para não ter ah versão nova, versão nova. Não, agora eles vão vão lançando igual o esquema de de release da da do Chrome, né?
>> E aí falando já agora do dos tempos modernos, >> aí a gente entra num negócio chamado KHTML que surgiu dentro do KDE.
>> Pera aí, pera aí. Ficou cacófano.
>> KHTML.
Tá, não é KHTML.
>> Ah, tá bom. Só para saber, porque algumas pessoas fazem isso.
>> Exato. Exato. Que esse cara é o embrião do safari. A gente não pode esquecer o Safari.
>> É verdade. Ninguém do Safari.
>> Então não, a gente só pessoal que usa e eh Mac aí ou Internet Explorer ou desculpa, o o iPhone ele já tá lá dentro, né? Então o Safari o Safari veio dessa engine que é o K HTML que nasceu dentro do KDE. Esse K não é à toa.
>> Ah, [ __ ] [ __ ] Então o Safari ele vem do KDE. Exatamente. Exatamente.
>> Minuto de >> A. É, exato. A INE que veio dentro do Safari é essa INE que surgiu dentro do KDE. Tanto que assim, muita coisa que tem no Mac hoje também veio dos Unix, né? Ele é um Unix Like.
>> Sim. É. É. Se perdeu, né?
>> É. Não, ele hoje é uma uma coxa de retalho gigante porque tem coisa open tem coisa proprietária.
>> Sim. Mas o o kernel dele era o Darwin, né? Até >> era. Eu acho que ainda é. Eu acho que ainda é que veio da Next, né?
>> Isso >> que eles trouxeram da da Next quando o Jobs voltou paraa Apple, aí eles trouxeram ali e incorporaram dentro do sistem, mas nunca teve nada a ver com o Linux. Muita gente confund. Exatamente.
É outra outra pegada. E aí a gente tem o Safari, né, com essa e não sei se é bem isso mesmo, mas a gente caminhou por muito tempo com Tem o Ópera também que a gente não pode esquecer. Então ia te perguntar do Ópera.
>> O Opera é um cara ali apartado, né? Ele surgiu também, nasceu proprietário.
>> E uma caixinha preta.
>> Hoje em dia, se eu não tiver errado, ele também tá usando Chrome.
>> Hum.
>> Né? Ele é um V8 ali também por debaixo dos panos. Muita gente acabou migrando, né? Muitos browser acabaram migrando.
>> Sim.
>> Eh, e por muito tempo a gente teve Firefox, eh, IE, né? Safari e Opera eram os quatro browsers que você tinha mais populares.
>> Então você foi levando tudo isso e aí depois que alguns caras saíram da Mozilla e foram pro Google, eles tiveram a a a difícil tarefa de criar o Chrome.
Na verdade era o Chromium, >> isso que é o open source open source da do Chrome.
>> Exatamente. Mas foram as pessoas que trabalharam na Mozila. Inclusive, um dos criadores do Firefox lá atrás foi para pro Google e ajudou a criar o Chrome em cima do V8.
>> Cri, mas ele ele é um fork. Exatamente.
Ou ele é uma inspiração?
>> Ele é uma inspiração só. Tanto que na época quando eles lançaram >> não tem código. Então >> tem alguns códigos, pelo que já me falaram que eles pegaram da do Netscape isso lá no primeiro, né? Hoje eu já não sei mais como é que tá, mas eles pegaram isso do primeiro Firefox lá atrás, dos últimos Firefox antes de lançar o Chrome.
>> Uhum.
>> Ou eles trouxeram a ideia ou eles trouxeram parte do código, porque o código da Mozilla também era Open Search já nessa época.
>> Aham.
>> Então eles criaram o Fire, o o Chrome, né, o V8 totalmente novo, né? Eles não pegaram de ninguém. Entendi.
>> Então assim, deve ter dado um trabalhinho, >> é, é >> bom para você fazer uma desse porte com essa velocidade. Então assim, o bom para eles é que eles criaram do zero, então você não tinha amarra de nada, você podia criar coisas refactoring, >> com certeza >> deu uma otimizada em muita coisa que eles já conheciam, etc. Tinha grana >> sim, pra caramba, né? Na época era grana infinita do mundo.
>> Grana infinita, né?
Quero falar com você agora que ainda não conhece a Clever. Clever é uma empresa que já tem mais de 3 milhões de usuários em 30 países com 30 idiomas diferentes, que tem trazido soluções em blockchain, criptomoedas e ativos digitais. O objetivo da Clever é te dar liberdade financeira para operar nesse mercado de cripto. Então, se você acredita nisso, se você acredita nessa liberdade, você já pensa como a Clever, vai conhecer os caras, é clever.Ou estão contratando também pessoal para trabalhar com cripto, com blockchain. Então, se você tem interesse, se você tem conhecimento nessa área, procura a Clever. Se você gosta de criptomoedas, se você opera no mercado, você precisa conhecer a Clever, precisa conhecer as soluções da Clever.
Então, o endereço tá aqui embaixo no vídeo. Para quem não tá no YouTube é clever. Vai lá, vai conhecer que realmente é um mercado sensacional.
[Música] Então, >> então a gente tem nesse momento o Chromium.
>> Isso aí entra o Chromium na jogada.
Então você tem mais um browser ali para >> que dá origem Chrome do Google.
>> Isso. Isso.
>> E que ainda rivalizou um tempo com o I.
>> Sim. Sim.
>> E com o Firefox.
>> Sim.
>> E o Safari ali com os Playboyzinhos.
>> Ah, e ele ficou, ele tá sempre apartado.
É, ele tá sempre. A partir desse momento a gente tira o Safari daquação que ele continua igual mesmo.Gig. E >> e outra, né? Ele não é multiplataforma, ele sempre rodou. Só, >> se eu não me engano, teve uma época que eles tentaram fazer, acho que o porte do Safari pro Windows, mas acho que muita gente não usou. Era >> eu, eu eu posso estar errado, mas eu me lembro que teve uma um esquema assim que tava para você instalar o Safari no Windows.
>> Tem coisas que a gente tipo mesmo >> não precisa.
>> É aquela vez, >> aquela coisa que você só isso, eu posso, mas eu devo.
>> Exato. São as perguntas que a gente tem que fazer.
>> Ex. É. Agora, beleza. Aí, em que momento a Indine V8 começou a ser de fato o padrão que enterrou o I, criou o Ed?
>> Hum.
>> Né? E hoje é basicamente a a mais usada.
>> É, se não for claro, tirando safari, né?
E >> é hoje o que você tem de engin da Mozilla e você tem o Ktml que é o do Safari. Sim, >> acabou. Daqui >> é verdade. É o a o o Firefox continua na mesma linha de desenvolvimento e Spiderman.
>> Em que momento elas conseguiram de fato atender o consórcium de web e de fato ficar eh interoperável entre entre tudo? Porque assim, a gente a gente tende a entend a imaginar que a gente resolveu esse problema porque matou o I e o Ed tá usando V8.
>> Então, tanto faz se eu abro no no ED V, né, que é o I New Generation.
>> É >> porque é a mesma identidade, tudo, né, parecido.
>> Mesma >> e no Chrome eu não vou ter dificuldade porque é o mesmo motor, né? Mas a Spidermk não, só porque as duas atendem as as mesmas especificações, né? Tem um tem um compromisso no consórcium web na W3C >> para poder atender isso, né? Mas é é tão perfeito, cara, que mesmo antigamente quando a gente falava que o o I já tava ficando W3C compliance e tal, >> né? no 10, 11 ali rolava ali um tipo quando tentavam enfiar guela abaixo o I na gente >> e não era igual, tipo uma largura de pixel e tal, >> funções de JavaScript mesmo.
>> E hoje a gente não tem problema nenhum com browser, você especifica, você desenvolve e em qualquer browser, >> inclusive no Safari.
>> Sim, sim. É, essa questão da W3C é interessante você trazer porque por muito tempo cada browser fazia do seu jeito e você que se vira para, né, para implementar.
>> Meu padradão é cinco.
>> Exato. Exato.
>> Se você não colocou que é um, [ __ ] >> Tanto que a gente, você trabalhou em agência também, não foi?
>> Eh, a gente trabalhava com front end na época, você tinha que fazer tudo funcionar no I e aí você pegava os outros browsers e ia >> isso >> ajeitando, né? Você falava: "Ó, funcionou tudo no I". Beleza, agora abre nos outros e corrige os problemas só para eles.
>> Sim, porque gente, na época o I era 80% do mercado, >> então você atendia 5, I6, lembra disso?
>> Isso. Nossa, I6.
>> É, então, e aí e mesmo nessa época do I6, a Microsoft já participava desse consórcio do da W3C, porque teve uma época na na vida do IE que eles tentaram criar uma linguagem JavaScript só da Microsoft, >> mas que >> para ajudar, por que não, né? Por que não? Para que que eu vou ajudar o mundo?
>> Chamava e chamava JS script.
>> Nossa, velho, >> né? Para você ter uma ideia. E e qual que era o detalhe dos caras? Eles queriam fazer a implementação deles ali e eles iam funcionar do jeito que eles quisessem. Eles eram 80% do do mercado.
Então, com essa questão de todo mundo falou: "Ó, vamos parar com esse negócio". Na época era Apple, Mozilla, a Microsoft entrou e se eu não me engano, eu não lembro se já tinha alguma coisa da Oracle ou alguma outra empresa que tentava ali também no consórcio falar: "Gente, vamos padronizar esse troço porque tá uma loucura isso aqui, né?" E aí nessa época Google já entrou, começou, né, empurrar a Microsoft ali também na parede porque o Google já tinha mais força.
>> Então o pessoal falou: "Ó, não, vamos padronizar esse troço". E aí começaram tanto que se você entrar no no site da W3C, você vai não vai achar coisas de JavaScript, você vai achar de ECMA Script, né? Então aí eles começaram a padronizar, ó, essa função tem que fazer isso aqui. Esse pading de um pixel tem que ser realmente um pixel, >> né? Tanto que antigamente, hoje você não, quase não tem, mas você tinha aqueles CSS que você zerava tudo, lembra? É, você dava um reset, >> você dava um reset em tudo, >> pede em margem, tudo.
>> E aí você declarava só o que era diferente.
>> Exatamente.
>> Então assim, para poder, porque não tinha esse padrão, né?
>> Então é o que você falou, hoje em dia, cara, hoje em dia tá um filezinho. Tem coisas ainda que agora quem tá nessa parada de tentar fazer só o dele é o Google.
>> Pois é, como o mundo da voltas, né? A terra, a terra plana ela capota, né?
>> Exato. Exatamente.
>> Impressionante, né? Então, hoje o Google dá aquelas pedaladinhas e fala assim: "Não, deixa eu colocar aqui, pô, é legal", ó.
>> E aí, né? Você vai trazendo algumas coisas novas. Até uma coisa que é interessante, você lembra do JQuerry, né, >> cara? E tá ativo ainda essa [ __ ] Eu fes dias, pô, tem muita gente que usa Jackware ainda.
>> Sim. O John Hesg, eu conheci ele uma época. O cara é muito gente boa. Ele tá na Can Academy hoje, faz muitos anos. E cara, tanto que o tanto de sucesso que a JQuery fez que os vendores de browsers falaram assim: "Gente, a gente precisa melhorar o JavaScript". Muita coisa do jeito que funcionava dentro da JQU foi incorporada na linguagem padrão >> para dentro do >> para dentro da linguagem JavaScript, né?
>> Pô, porque realmente era um negócio impressionante.
>> Sim, sim.
>> Ah, JQU foi o que criou os seletores, né?
>> Sim, sim. porque você não não tinha como coere >> a árvore de de objetos do browser, né? E aí era o próximo ponto que eu queria que eu queria te perguntar, cara, pra gente chegar no no nosso ponto de discussão final.
>> Uhum.
>> Dá um overview para quem tá ouvindo a gente de como funciona o browser, >> o que é o dom, >> o que é essa camada de renderização?
>> Uhum. como que você tem essa árvore hierárquica de objetos dentro do do da memória ali para poder trabalhar com os objetos? Porque isso é a base pro funcionamento dos seletores do JQuery >> e que é a base do funcionamento das linguagens de front endum >> modernas, né?
>> Então, dá um overview pra galera.
>> É, então, basicamente assim, a a ideia do da engine, que a gente chama, elas são divididas em três, né? Hoje em dia, alguns browsers voltaram a ter só duas, mas basicamente como eu brinco é a trinca de ouro da web, né? JavaScript, HTML, CSS.
>> Isso >> no fim tudo é isso dentro do browser.
Eh, >> e aí o que acontece?
>> Java Applet não tem mais, né?
>> Graças a Deus.
>> O velho, né?
>> O Java na minha é não tem mais.
tem uma aplicação lá rodando ainda, mas assim, eh, você tem o dom, que é o document object, que é o, entre aspas, a hierarquia do HTML, quem é pai de quem, quem é filho de quem, né, para pro browser saber o que que ele tem que renderizar.
>> Então você tem essa árvore que é o Dom.
>> Sim. E se você tá ouvindo a gente, você conhece HTML, é fácil você imaginar que dentro da estrutura da HTML você tem tags. Dend tags.
>> Exato.
>> Então se você imaginar isso, você consegue montar uma árvore. Só de >> de você pensar que tá um encampsulando o outro ali, você consegue montar uma árvore facilmente.
>> E para quem é desenvolvedor Java, o HTML é um uma especificação de um XML. É, é isso.
>> É um XML com padrão.
>> É um XML com um contrato lá. Um exato. É uma árvore ali. Tem, >> só que ele tem as definições que sempre são aquelas, né?
>> Isso é, tem. Agora acho que nem precisa mais, mas antes você tinha colocado, declarar, >> é bom >> no começo lá qual que é a especificação do documento, né?
>> É, na verdade assim, isso daí document type, isso, isso mesmo.
>> Isso daí é bom para essas engines do browser saberem o que que ela tá renderizando.
>> Hum. Porque assim, se se para quem já fez fez computação ou é curioso, eh se você lembrar das aulas de compiladores, você tem ali uma certa informação do que que você tá rodando antes de começar a rodar de fato.
>> Sim. Até para você fazer o parcelamento e análise léxica.
>> Exato.
Sintática, toda aquela coisa.
>> Eh, mas qual que é a ideia aí? O document type hoje, quando o browser é começa a renderizar, primeira coisa que ele procura é o HTML e vai falar: "Tá, o que que é essa página aqui? HTML4, HTML5, o que que eu tô rodando?" Então ele vai procurar esse doc e aí >> e o HTML é o nó raiz da árvore.
>> É o nó raiz da árvore, porque dali ele vai conseguir saber o que que tem para ele poder fazer. CSS, JavaScript, >> como que ele vai organizar essas coisas.
Isso é pegando um document, ele sabe a especificação dos nós que ele pode esperar chegar ali dentro.
>> Isso. Isso porque ele sabe o que que ele vai esperar de tag, eh de quem vai ser filho de quem ali. Então ele consegue, ele começa a montar, para quem também lembra, da ST, né? Eh, abstract Syntax Tree, a a árvore de síntax abstrata.
Então, querendo ou não, se você for parar para ver, uma HTML é uma uma árvore, né, de de síntax.
>> Só que é uma síntax HTML. Então ele tem essa engine que cuida do HTML, a engine cuida do CSS e a engine que cuida do JavaScript. Então na hora do processo de renderização, ele vai pegar tudo que HTML vai jogar para essa para essa engine, vai renderizar e aí como a gente falava antigamente, hoje em dia tá tá mais tranquilo, mas ele vai ler o HTML primeiro, volta, passa a colocar todo o CSS, volta e aí começa a aplicar o JavaScript. Então, em cada momento, uma dessas desses motores vai ativar.
>> E faz sentido, né? Porque você vai ter primeira árvore de objetos montados pelo HTML.
>> O CSS depende dessa estrutura.
>> Sim, porque ele senão ele não sabe onde onde ele vai aplicar.
>> Sabe exatamente que aí você vai saber quais são as classes e você tem declaração de herança no CSS, né?
>> Então, tipo, quando for uma classe tipo tal, dentro de tal classe.
>> Uhum. E aí você que nunca soube como funciona, agora você sabe que existe uma uma árvore dentro da memória do browser e que ali ele consegue definir de acordo com o que você coloca >> de estrutura do CSS, né?
>> Uhum.
>> Você define quais são as classes, os IDs, né, os identificadores e a ordem onde eles podem estar declarados. Por isso que você pode colocar >> um ID, espaço, uma classe e aí isso vai dar mat com padrão.
>> Exato.
>> Que é daquela árvore. Uhum. né? E esse tipo de padrão é o que faz o seletor do jQuery, né?
>> Exatamente. A questão do seletor, por exemplo, quem cuida desse seletor é a engine de JavaScript.
Eh, mas aí tem aquelas regrinhas que a gente falava antigamente. ID ele tem que ser único por página, ele não pode ser dois, >> porque senão, se a ID é uma identificação, >> como que o JavaScript vai saber? Ele roda, ele sabe que dá para fazer aquilo.
Mas a boa prática, né? Vamos colocar só um ID. Classe, não, classe para todo mundo. Aí você pode repetir quando você precisar. Então tem essas regrinhas, né?
Até você tava falando da questão de árvore e renderização do HTML. Hoje para quem mexe aí com eh Angular React, tem o Shadow Daw, tem todas essas novas tecnologias que você baseado nessas nessa trincazinha de JavaScript, HTML, CSS, você consegue botar as coisas por debaixo dos panos, renderizar aqui e só mostrar.
Agora você saiu da parte de que eu já não sei mais absolutamente nada porque eu parei no Jquery. O que que é essa [ __ ] de Shadow Dom?
>> É basicamente uma pré-renderização.
O browser por enquanto ele tá te mostrando uma página, ele já tá pré-renderizando outra >> e você consegue alterar coisas aqui com o teu framework, seja o React. É que o o React não é um framework, ele é uma lib, né? E o Angular é uma um framework, mas cada um deles implementou essa parte um pouquinho diferente, mas eles conseguem só trocar o que você tá vendo para isso.
Daí você economiza processamento que você já tá usando aqui, mesmo enquanto o cara tá interagindo com essa página que tá visível e aí a hora que precisa, por isso que parece tão instantâneo, ele só troca.
>> Mas como é que isso funciona internamente no browser? Porque eu tenho um processamento de dom >> e tem um par um parcelamento ali de ser que parece ser meio que >> concorrente meio para não é paralelo, parece uma coisa meio que sequencial. Eu consigo abrir uma trad e rodar esse background no browser. consegue no Firefox, na engine do, eu não lembro se é na Engine de HTML ou se é na engine de JavaScript, mas eh ele tem um projeto, tinha um projeto, eu não sei se ainda tá e eh rodando dentro da Mozila, que chama eh drop alguma coisa. Qual que era a ideia?
Era a questão de gotas mesmo. Então eles pegavam essas trads e começavam a distribuir por dentro do browser ali.
Falar: "Você precisa rodar coisa em paralelo? Vamos separando, né? Os processos eram separados, não era mais só um processo. Quem começou com isso, inclusive foi o Chrome, né, de ter múltiplos processos. Antigamente você tinha um processo no no no seu sistema operacional que era só o Firefox, por exemplo. E aí quando entrou o Chrome, os caras, não, pô, para que que a gente precisa? Se a gente tem aba, se o Chrome já nasceu com aba, cada aba é um processo.
>> É, não. Aí olhando, olhando o macro no browser, >> eu consigo imaginar que você tem abas ali que >> Mas aí pera aí que você me bugou.
>> Se você parar para pensar essa questão do Shad, ele pode ser mais uma aba, ele só troca.
É como se fosse uma trad ali um um aba nova onde ele renderiza as coisas aqui.
Só que é uma cópia dessa aba que você tá vendo.
>> Não faz sentido. Mas é que para mim são coisas diferentes na minha cabeça. Então me ajuda a entender.
>> Porque para mim a aba é como se fosse uma instância nova do browser.
>> Sim. Sim, >> né? Uhum.
>> Então, beleza, instanciei de novo o browser e tá rodando aqui. Agora, quando eu tô dentro daquela mesma aba, >> Uhum.
>> que é uma instância única do browser.
>> Sim.
>> E aí eu tô pensando como desenvolvedor interagindo com o código.
>> Uhum.
>> Eu faço uma sequência de código ali dentro do do JavaScript.
Entenda que eu parei lá no jQuery e eu estou pensando ainda com aquela cabeça de que para JQU.
toda a mudança que eu faço ali na na nos meus seletores, etc., eu tô mudando, eu tô eu tô mudando o dom que que tá naquela única trad que tá saindo na rinerização, cara.
>> Mas imagina que você tem uma uma filha da filha, digamos assim, você tem o processo pai, que é o browser, você tem a aba, que é um processo filho, certo?
Se você tem um outro, um dom escondido, você pode ter um filho do filho.
>> Mas eu consigo falar, ó, eu vou fazer essa modificação, >> mas não é no dom ativo, é no na outra trad. Dom, no dom escondido, por isso que é o shadow dom.
>> [ __ ] >> É. E aí você >> agora eu tô me sentindo velho.
>> E aí você tem a questão de sincronicidade, né? O, por exemplo, que antigamente a gente tinha os promises, não sei se você chegou a a mexer com você tem o assim que é weight também. Você já chegou a mexer? Eu eu eu mexo com os promises, mas não em front, né?
>> No back, >> no back. É exatamente, >> né? Então, então o pessoal começou a trazer essas, eu brinco com o pessoal que hoje em dia eh, você tem tanta ferramenta que você não sabe o que usa mais. Antigamente você falava: "Putz, vou usar JQuery CSS aqui". Quando teve o Bootstrap, >> né?
>> Bootstrap ainda tinha, >> tem ainda tem o Bootstrap. Hoje tem um monte de coisa. Tem o tal de do te, tem uma porrada de biblioteca. um browser, eu fiz uma uma um front end para uma poc no na empresa esses dias e eu fui usar o Gemini Clean.
>> Ah, tá.
>> E aí, eh, não queria abrir ainda essa aspas aqui sobre a porque eu acho que, aliás, eu acho que foi o episódio que a gente ficou mais tempo esse ano falando sobre computação sem falar de A, cara, parabéns. Toque aqui, conseguimos. É nós.
>> Quanto tempo de operador? Quanto tempo de >> 34 >> 34 minutos? Sem falar de a >> sem falar de Vamos falar agora de >> história.
>> E eu não quero falar de a agora, depois a gente vai falar. Mas eh >> só abrindo o parênteses, eu fui, eu eu criei um layoutum >> que, cara, eu sou programador for sou arquiteto, né? Sou programador back, né?
[ __ ] Aí precisava, já tinha feito tudo o os scripts, tudo back end precisava fazer um front end para apresentar aquela parada.
>> Uhum.
>> Aí fui lá no Canva e no Canva eu consigo fazer o layout.
>> Uhum.
>> Sem a HTML, né? Agora ele tá até gerando HTML.
>> Tem. Agora tem várias ferramentas que fazem isso.
>> Pal, precisava de uma tela que fosse assim. Sim. Falei: "Pô, fez, fiz uma telinha bonitinha." >> Falei, pô, da hora a telinha, né? Peguei o PNG, aí levei pro meu pro meu meu file system.
>> Abri o Gemini ali, falei: "Ó, lê esse PNG e cria um front end para mim com as últimas tecnologias de front end.
>> Uhum.
>> E com as melhores práticas e tal". Cara, ele fez um front ending React. É, >> com tail wind CSS. É isso mesmo.
>> Aí um framework para desenvolvimento que eu achava que era um framework web, mas é um framework de desenvolvimento porque depois ele não vai pra produção. Não entendi muito bem isso ainda. Mas é o Vit, >> o Next. Ah, o Vit. Sim, sim.
>> Que aí ele, tipo, ele fragmenta ali para você desenvolver, mas ele gera um build do front end para produt. Como assim um build de front end, velho?
>> É, não, hoje em dia escalou tanto, >> [ __ ] >> Eu tô buildando o front end.
>> Como assim, né?
>> Históri.
>> Cadê? Cadê meu arquivo de até da gente trazendo essa questão desses frameworks?
Eh, eu lembro da minha estranheza quando eu comecei a ver Angular e e React.
Olhei e falei: "Gente, mas por que que vocês estão misturando HTML e e JavaScript no mesmo arquivo? Que loucura é essa?
>> Que que tá acontecendo aqui?
>> Vamos isolar. Sempre foi isolado. Hoje em dia você entende, você fala: "Putz, não tá, faz todo sentido, >> né?" Mas a gente passou por essa época, né? que você tinha o HTML para ali, pasta de CSS, pasta de JavaScript e era isso. Botava script no final porque tinha que esperar montar o dom.
Exatamente. Você colocasse, ele não tinha exatamente, >> porque ele ia ler, falar: "Tá, vou aplicar o JavaScript". Não tem don.
Exato.
>> Pois vai, todo o mundo muda.
>> Então você dá toda essa volta, provavelmente no final das contas, né?
Que a gente brincava na faculdade que no final tudo vira C, né? Na web tudo vira HTML, CSS, JavaScript.
>> Sim, >> basicamente é isso.
>> São só meios que você tem de tornar isso mais produtivo, né? E organizado.
>> Seria os BT codes do Java, por exemplo.
>> Isso. O mais organizado eu não sei porque até hoje eu não entendo o que aconteceu naquele front end. Também não quero entender, mas saiu meu front. Saiu meu front, tá tudo certo.
>> Você que tá aí escutando esse episódio bacana e quer levar toda essa tecnologia, essas novidades paraa sua empresa e não sabe como, chama o time da VMBERS. A gente pode ajudar vocês com desenvolvimento de software, com arquitetura de soluções, a entender os problemas que vocês estão vivendo e sair do outro lado com uma solução bem bacana. E se você tá escutando o podcast para aprender coisas novas, faz o seguinte, manda um e-mail pra gente no peoplecare@vems.
E você pode fazer parte também do nosso grupo de talentos. Valeu.
Agora o time do Relações Públicas vai gostar mais de mim.
E e então voltando pro pro nosso estado atual do >> de de browsers de tecnologia HTML.
>> Uhum.
>> Então a gente tem agora então essas possibilidades de um de um processo de execução ali, né? Um >> Sim, sim.
>> Pode pode chamar de um runtime praticamente.
>> É um git, né? Um just time compiler ali, vamos, vamos dizer assim.
>> Entendi, >> né? A concentrando na engine JavaScript, ela é um just in time compiler, basicamente isso, >> tá?
>> Porque ela precisa pegar o seu HTM, o seu JavaScript, né, >> que é um código que não é compilável.
>> Sim.
>> Então ela vai, à medida que ela vai precisando daquilo, ela entre aspas compila e dá o resultado para você.
>> Sim.
>> Não é tudo pré-compilado, >> é um interpretador real. Exato. Exato.
>> É que é se assemelha muito às linguagens interpretadas como Python, Node. Node é todos eles têm um git, né?
>> Sim.
>> O Git é meio que padrão da arquitetura ali de de compiladores.
>> Sim. E isso compartimentalizado, né? Porque ele não builda tudo ao mesmo tempo, né? Claro.
Aí entra a questão da ST, >> né? Porque quando ele ele tem ele monta uma ST para HTML e monta uma ST também pro JavaScript.
>> Hum. Hum. Ó, JavaScript também tá numa ST, então ele só vai vendo os nós. Ah, esse nó aqui tá preciso de de alguma coisa que tá aqui dentro. Precisa. Faz o git, entre aspas, compilado, devolver o resultado pro browser e fica aguardando, né? Então aí entra a questão de porque também você precisa de paralelismo hoje em dia.
>> Uhum.
>> Né? De ter trado, porque às vezes você tem >> com o advento lá atrás do Ajax, né? Que a gente XHTML, HTTP request. Xhtp request.
>> É. Entendeu? Então, eh, a gente tem esse paralelismo.
>> É porque você tinha que abrir um processo à parte >> assíncrono para processar e trazer pra pra trad, né?
>> Sim, sim. E nesse caso do Ajax, né, a gente tem que dar o crédito a Microsoft que começou com isso.
>> Ah, é, foi Microsoft.
>> Foi foi Microsoft, começou com o XHTML, HTTP request. É deles.
>> Ah, às vezes, >> né, foi uma uma implementação deles primeiro.
>> Ah, não sabia, cara. Ó, tá vendo? Até relógio parado >> temos que dar os créditos.
>> Cadeira Microsoft você já tem até Linux Microsoft vocês aprender >> até distribuição Linux mas na época vocês eram uns arrumbados.
>> Expo eles e eles falavam, né, que Linux, que que é isso? Não sei.
>> Enfim, essa é a história para outro outro episódio.
>> Mas você tem, né, a questão o do pegando a história, você tem o o advento do Ajax, que aí lançou aquela questão de web 2.0, Gmail e aí começou revolução porque era era uma via de mão única, ele renderizava, carregava e acabou, né?
>> Sim. JavaScript era para validar formulário, acabou. Era isso, >> ex. Exatamente.
>> Era uma execução única, você não tinha interatividade com o servidor, né? Não.
E aí você começou a ter essa questão, né? Você pegava XML, trazia pro browser, parceava e botava um resultado na tela sem dar refresh, >> né?
>> Sem dar refresh, >> sem precisar recarregar a página.
>> E e esses frameworks que fazem isso, frameworks não, mas o essas eh interfaces que a gente tem no browser >> que possibilita a gente fazer isso eh praticamente em tempo real. Tudo que a gente faz >> ainda é muito baseado em XHTTP request e web Socket ainda ou >> a indine já evoluiu e isso já ficou para trás?
>> Ela já evoluiu e isso ainda existe. Na verdade depende do foco da tua aplicação. Por exemplo, se você e querem pegando o Node agora, que é foi uma revolução pra gente também, né?
>> Eh, o Node também roda uma ending JavaScript ali atrás, que é o V8, né?
Ele foi construído em cima do V8.
H, só que aí é o que eu falei daquela questão de você ter várias engines, vários motores, cada um responsável por uma coisa. Ele pegou o V8, que é só o responsável pelo JavaScript, e isolou.
Ele não precisava renderizar HTML nesse CSS. Então ele jogou ali dentro. E aí é o que você falou. Agora, você tem ã as questões de web socket, Promise, a Sync, o XHTML, o XHTTP request. H, então você tem várias vários jeitos de se comunicar com um servidor backend, né? Com isso, você precisa de mais velocidade dentro do do browser do da, né, vamos isolar, e precisa de paralelismo, precisa de trad, precisa dessas outras coisas. Então, as endes evoluíram também, né? Você tem tanto que, por exemplo, hoje em dia muitos dos códigos dentro do Firefox, dentro da engine do Firefox do Spider Monkey, ela tá sendo reescrita em Rust por conta de performance, de velocidade, de garbage collector que a gente teve um episódio, né, com Baiano aí que foi sensacional falando de Rust também, ele mostrando os códigos. Então assim, o pessoal tá ainda hoje melhorando as endins, porque ela precisa ser leve, ela precisa ser rápida. Então, né, porque você, querendo ou não, você tem aplicação que roda aqui, que roda com engine de JavaScript.
>> Sim, >> né? Então, e a as engines não pararam de evoluir, elas continuam evoluindo.
>> Cara, a gente tem praticamente um mini sistema operacional rodando do dentro de um browser hoje, né?
>> Sim, sim, sim. Hoje em dia você tem e eh >> porque você tem se você tem garbage collector, você tem gerenciamento de trads.
>> Sim. Sim.
>> Você tem gerenciamento de memória.
>> Uhum. Você tem acesso a IO?
>> Sim, é um mini mini sistema operacional.
Tinha até uma época agora uma uma curiosidade meio, né, de quem foi contribuidor da Mozila muito tempo, mas eu lembro da gente ter participado de uma reunião com o pessoal da Mozila que era para lançar nova campanha da de marketing da Mozila e tudo, né? E e aí a gente, o pessoal no final lançou o internet de todos para todos, que era mais, né, pô, browser para todo mundo, ele tá em todo lugar, mas e eh se você parar para pensar, a gente falava na época que o browser é a casa de todo mundo, porque você entra no seu computador ali, né, no seu Mac, no seu Windows, no seu Linux, você uma hora ou outra vai acessar a web. Então tava tudo na web até hoje em dia, né? Você tem >> Gmail na web, o seu e-mail na web, você tem seus documentos na web que você tem o o Office 360 lá que roda na web, você tem o da do da Google. Você tem um monte de coisa que você tem, você assiste vídeos na na no seu YouTube, você tem Netflix, você tem um monte de serviços que tão tudo dentro do seu browser, né? você não não instala mais uma aplicação na tua máquina para rodar um monte de coisa, né?
>> Muito bom. Não, você com foi aí que tu até começou a ter os internet notebooks, né? Como foi >> os Chromebooks, etc. Que basicamente você chegou no ponto você para aplicações simples, né, que não não tem um >> um fim específico, você precisa de um computador e um browser.
>> Sim, >> né?
>> Até desenvolver. Hoje você tem aplicações que você desenvolve dentro do browser uma aplicação, sei lá, backend, por exemplo.
>> Cara, isso é >> incrível.
>> Acho isso incrível.
>> O próprio VS Code, né? O VS Code ele é uma uma página web, digamos assim, ã, que roda em cima de uma aplicação chamada Electron, que é do GitHub.
>> [ __ ] que o VS Code é electron.
>> Ah, não é possível.
>> Não sei se ainda hoje é, mas ele nasceu como electron. Cara, o Electron me lembra muito uma parada que a gente fazia para para desenvolvimento mobile um tempo atrás, que era o fone gap.
>> Sim, sim.
>> Que você desenvolvia com HTML, JavaScript.
>> Uhum.
>> Né? E conseguia portar para tanto Apple quanto Android.
>> É, o React Native é assim também. Isso é exatamente. Só que ele, o Electron, ele criou esse paradigma de você desenvolver pra web, só que buildar pr desktop.
>> Desktop, cara. Não é isso mesmo? É uma aplicação apartada, né, com a sua trad ali reservadinha, seu ambiente de de de execução reservado. Só que é um browser ali, é uma aba de um browser que você bota tua aplicação inteira e você não tem acesso para outras coisas ali. Você não vai abrir uma nova ab e começar a mexer ali. É uma aplicação isolada, mas se eu não estiver errado, VS Code é um Electron, Spotify é um electron. Eu tô tentando lembrar aqui as as aplicações que eu uso. Às vezes o Franz, não sei se alguém já usou, mas é um um agregador de de Messengers. Você pode usar WhatsApp, >> Telegram, essas coisas. O próprio Telegram é um um é criado em cima do Electron. Então assim, muita gente usa a questão do Electron para poder >> e é um desenvolvimento voltado pra web, mas >> Jojô, nossa editora, posso pedir licença que bota um pizzinho aqui, mas pau no cu da JVM.
>> É, exatamente. Você não precisa mais.
>> JVM, não precisa. Exato, exato.
>> Porque assim, e eh hoje você lembra daquela época que você usava aquelas eh gui de Java, né, que >> você qual que era a aplicação, eu não lembro agora qual que era a biblioteca que fazia aquilo, cara.
>> Não era, não eram applets, eram >> tinha uma biblioteca do Java que você conseguia desenhar a interface. É, eu não, eu não lembro agora o nome, mas >> você que tá aí assistindo a gente, você coloca nos comentários aí pra gente lembrar, porque eu esqueci mesmo.
>> Mas a ideia dessas aplicações é isso, né? Você ã no no Node, né, no hoje em dia a gente não fala nem você fez uma aplicação pra web, não. Você fez uma eh eh aplicação com tecnologias web. Por mais, por exemplo, o VS Code, ele não é uma página, né? Tem algumas algumas empresas que trouxeram o o VS Code, a estrutura do VS Code para uma aba e você acessa lá, você tem seus arquivos, você vai fazendo as coisas, codificando num browser, você não precisa instalar o VS Code na máquina. Então evoluiu tanto nesse ponto que você tem hoje aplicações gigantes rodando num browser, né, >> cara? Impressionante.
>> Por exemplo, aí provavelmente vai entrar onde a gente e eh eh converge para um outro assunto que envolve o web, que é a questão do web assembly.
>> Isso, >> né?
>> Web assembly. Isso é uma parada que eu queria entender melhor.
>> Então tivemos toda essa caminhada para esse momento, >> isso para chegar aqui, né? Então a gente já falou como a gente aumentou a complexidade, como a gente aumentou o poder de processamento dos browsers, como isso roda por trás.
E aí eu vou >> como a web saiu do browser.
>> Como a web saiu da da É, saiu do browser literalmente, né? Exatamente.
>> E mas aí eu vejo o caminho contrário.
>> Uhum.
>> Porque veja, a gente criou uma caixa.
>> Sim.
>> A gente criou uma, não vou chamar de máquina virtual, mas a gente criou um environment.
>> Sim. Sim.
>> Que a gente consegue sair até de dentro do browser, como o Electron, >> para executar aplicações locais.
dentro daquele ecossistema web, web like, digamos assim, que é HTML, JavaScript, etc.
>> Só que quando a gente tá falando de web assembly, nós estamos falando de binário.
>> Sim.
>> E o binário ele roda com instrução para o processador direto.
Ele não é >> Uhum.
>> uma linguagem interpretada >> com um git, como você tem essa abstração.
>> Exato.
>> rodando em cima do browser.
>> Uhum. Então, eh, relembrando aqui para quem tá nos ouvindo de de alguns conceitos e para acompanhar a gente, >> sim.
>> Eu tenho um sistema operacional rodando.
>> Uhum.
>> Dentro desse sistema operacional rodando, eu tenho um binário, que é o browser rodando.
>> Exato.
>> E dentro dele eu tenho um interpretador de código que vai gerar tudo isso que a gente falou aqui.
>> Uhum. Então, eu tenho o sistema operacional, eu tenho um binário. Dentro desse binário, eu tenho um interpretador que gera o dom, que tem o git, que tem o V8, etc, etc.
>> Claro, a rigor da da da especificação técnica, temos muitas outras camadas aqui, mas eu dei uma uma simplificada para >> dar dar uma enxugada aí, >> é, pra gente falar exatamente aqui do que do que a gente trata diretamente no no episódio.
>> Uhum. Quando você fala que você gera um build em Web assembly >> e você tem um binário, eu não consigo assimilar como que a camada de cima executa, se ela deveria estar na camada de baixo para ser interpretada pelo sistema operacional, porque que era um binário.
>> Uhum.
>> Como que essa mágica acontece, meu amigo? explica pra gente.
>> Basicamente é uma o o a tua explicação tá certíssima, porque se você for parar para para ver, é uma stack, né, a gente lembrando lá da pilha, lista e fila, os conceitos básicos da programação, na verdade de de organização, né, da da das execuções. O Web assembly, ele também é uma pilha em cima de todo mundo aí. Só qual que é o detalhe? Se você parar para pensar que alguém precisa interpretar ou executar no caso e ler esse e esse binário, quem que tá mais próximo de executar isso? A engine JavaScript, né? O motor de JavaScript.
>> Pera, antes de você continuar, explica o que é o Web assembly, >> tá? O Web Assembly é uma tecnologia criada pela Mozila, se eu não tiver errado, em 2012.
Eh, que no começo era um negócio chamado ASM JS. Asm JS >> é que é assembly JS, né? O ASMJS.
A ideia deles era você já começar a ler coisas que fossem compiladas via JavaScript, né? Só que >> é é as doideiras dos caras de dentro da Mozila lá.
E e por que que isso nasceu? Também teve uma época, isso daí até tá no no meu na minha iniciação científica, que a Mozila começou a testar a implementação de tipos Cindy, single input e multipoldeira, né? Você lembra das das aulas lá de paralelismo e tudo.
>> Eh, inclusive na minha na minha iniciação científica, eu mostrei essa execução. Então, o que que aconteceu?
Você precisava baixar o Firefox. Você baixava o código, não o Firefox já compilado. Você baixava o código, flegava as coisas que você precisava para falar para de JavaScript, falava: "Ó, agora você não vai interpretar só e eh 16, 128, não. Você vai interpretar outros tipos, float 64 e e por aí vai.
>> Mas cara, como que isso acontece se você não tá na especificação da linguagem?
Então, na verdade, quem interpreta isso é o próprio, a própria Engine dentro do JavaScript. Ela quando ela lia o JavaScript, se você colocasse ela falando, ó, var float bá, ele já sabia, a própria já tava com essa flag que você compilou o seu Firefox ali na tua máquina, não que você baixou do site da Mozila, >> você compilou na sua máquina e falou para ele: "Ó, agora você sabe interpretar isso aqui".
E aí quando ele pegava o JavaScript, ele já sabia que aquele tipo era válido para ele, porque quando você fez a compilação, você habilitou esses outros tipos. Quando você baixa do site da Mozila, não tem isso habilitado.
Por >> porque você tá dentro do contexto web ali, né? Exatamente. Exatamente. Só que mesma coisa que você baixa o seu código do Firefox. Isso. Código que eu digo, você vai lá no repositório, mesmo jeito que a galera vai no GitHub, você vai lá, baixa todo o código do Firefox, tem Python, tem C, tem Rust, tudo ali dentro.
>> Ele vai compilar e vai te deixar um executável do Firefox.
>> Só quando você roda o seu JavaScript dentro desse Firefox, ele sabe que aquelas flags que você colocou eram para habilitar esses tipos novos, >> tá? E, mas aí como é que funciona esse tipo novo? Eu eu declaro ele no JavaScript.
>> Sim, sim.
>> E aí a interpretação dentro da engine é feita como se fosse uma interpretação de um binário fora do web.
>> Então, a gente ainda nesse caso, a gente ainda não chegou no Web assembly.
>> Isso daí foi o que foi o embrião para ter o web assembly. Porque qual que era o detalhe? Se você parar para pensar que tem outras linguagens fora do do browser que tem esse tipo de >> Ah, tá. Eu, então, nesse caso que você tá me dizendo que eu só mudei especificação de JavaScript para teco.
>> Isso. Exatamente. Exatamente. Tanto que no teste que eu fiz, quando eu fiz a iniciação, eu peguei um fractal de Mandel Braw. Agora eu tô, né, indo fundo no negócio.
>> Pera aí que eu vou precisar de mais um go. É, eu peguei um fractal de mandel braw, executei ele sem a flag dos tipos novos, né? Float 64, float 128, por aí vai.
>> E peguei os FPS e aí rodei a mesma o mesmo fractal dentro da compilação com o Cind habilitado, né, e os tipos. E cara, caiu acho que quase 10 vezes o o o FPS, >> né? Então assim, foi muito mais rápido a execução.
>> Uhum.
>> H, qual que foi o detalhe? Nessa época começou-se a falar de paralelismo dentro do browser, isso muito tempo atrás.
E o pessoal viu a necessidade e falou: "Pera aí, a gente não vai ter como fazer isso dentro do JavaScript porque senão ela começa a virar uma linguagem tipada".
>> Uhum.
>> Né? E a ideia do JavaScript puro não é ser tipado, né? Tipado. Diferente do ECM, é diferente do Typescript. Type scpt é tipado, JavaScript puro ali, não.
>> E aí começou a incomodar a galera dentro da Mozila. O pessoal, não, vamos então, ao invés da gente criar uma linguagem nova, vamos usar as linguagens que tem e a gente consegue usar a execução dessas linguagens dentro do browser. E aí nasceu Web assembly, porque você conseguia ter a execução dessas dessas linguagens >> já com o o binário, com tipos, com trad, com paralelismo fora do browser.
>> Você deu um salto aqui que eu me perdi.
>> Uma coisa eu eu ter uma linguagem ainda interpretada >> Uhum. Uhum.
>> E eu habilitei um tipo novo porque aí a minha engine vai conseguir interpretar.
Mas eu ainda tô falando de interpretação.
>> Uhum. Eu ainda tô falando aqui de linguagem interpretada.
>> Isso que lembrando é mais lenta em muitos casos do que compilado.
>> Exato. Porque eu não >> porque eu não preciso entender ela em tempo de execução, né? Eu preciso entender ela em tempo de compilação.
Diferente.
>> Exato.
>> Eh, mas como que eu consigo? Porque eu consigo conceber que a gente consegue trabalhar com JavaScript através da interpretação?
>> Uhum. Então eu fui lá, mudei a minha especificação, criei o JavaScript Clouber que eu tenho um float 64 nesse JavaScript.
>> Sim, isso daí foi antes do Web assembly.
>> Isso. E aí, beleza, tenho esse princípio.
>> Hum.
>> Mas a partir daí eu consegui dentro do browser ler um byte code.
Você deu um salto aqui que eu me perdi?
Como é que como é possível? Se você for parar para pensar, tudo que já tá rodando ali é um byte code.
O AST depois que ele que ele termina, ele gera os byte codes.
A a execução da árvore e eh do JavaScript, quando ele começa a fazer a ST, ele se torna um byte code depois, porque ele tem que executar aquilo, por mais que seja interpretado, >> no mesmo formato binário que eu executaria no sistema operacional.
>> Sim. Sim. Por debaixo dos panos, pro browser. É isso, né? Ele cria a árvore do JavaScript, faz a ST e na hora que ele vai fazendo esse git, ele pega, compila, entre aspas ali e manda pro browser.
>> E aí ele executa.
>> Nada, mas é com compilação e memória.
>> Exato. Exato. Que é o just in time. Ele só compila >> para executar.
>> Para executar >> e não para persistir.
>> Execut. Exato. Exatamente. Por isso que eles E qual que foi a ideia? Como eles tinham esse essa questão dos tipos, para você implementar mais essas coisas dentro do do da engine do browser, você ia começar a deixar um negócio gigante, gigante, lento, não precisa, né?
>> É, você ia trazer a complexidade de uma linguagem compilada para uma linguagem interpretada >> e para dentro de um browser que precisa ser chuto, né? E aí começaram a fazer essa questão de tentar ligar o browser, a a execução do browser, dos códigos dentro do browser com linguagens externas. E por isso nasceu Web assembly.
Por quê? Porque tem coisas que o JavaScript não dá conta. Ele não foi feito para isso.
>> Uhum.
>> Né? Então, pô, imagina você fazer cálculos de perfuração de petróleo, você vai usar um C, você vai usar um Rust, você não vai usar JavaScript para fazer isso.
>> Então, qual que foi a ideia? Ao invés de você ter esse tipo dentro do browser, você deixa a própria linguagem que ele já foi feita para isso, cuidado dessa parte e você só dá o resultado, você só se comunica com essa com essa linguagem externa. E aí entrou a questão do Web assembly, porque o que que faz o Web assembly? Ele traz para dentro do browser, ele fala assim, ó, executa aí.
É um binário. O sistema operacional se vira para executar.
>> Mas tem, o que eu fico imaginando é o seguinte, o binário eu não tenho muito controle do que que ele tá rodando ali.
>> Ele roda dentro do browser, >> mas, por exemplo, eu eu tô rodando dentro do browser.
>> Isso que é um sandbox.
>> Isso.
>> Ele não externa.
>> Ele tem é ele tem os seus boundaries ali. Tem tem. É isso aí. Então, se eu fizer um script em C >> Uhum.
>> Que tenta acesso a disco, por exemplo, direto, ele não vai rodar, >> não vai. As mesmas permissões que você tem para um site, você tem para um binário Web assembly.
>> E então não é simplesmente eu criar um, eu não vou abrir um ponto CPP no no meu bash, não >> buildar e mandar rodar no browser. você tem um ponto ali de >> tem uma especificação para isso.
>> Exatamente. Então aí entra a questão, >> explica isso pra gente, porque isso acho que isso é o ponto para entender de fato o que o que é Web assembly, como ele funciona, entendeu?
>> Tá? Ã, Web assembly, como ele nasceu da Mozila, o pessoal começou com essas coisas de criar os padrões, só que eles já são veiacos com isso. Eles mandaram pra W3C também, que a gente falou lá atrás.
>> Hum. Então, tem uma especificação da W3C. E todos os BRE tem Web Assembly.
Virou uma especificação.
>> Entendi.
>> Com Microsoft, com Google, com Mozilla, com Apple, com toda essa galera. Toda essa galera participa do desenvolvimento e da especificação do Web assembly.
Porque assim, eh, não é um, não é da Mozilla isso hoje, mais nasceu lá, mas externou. E, e aí é exatamente, aí virou o consórcio. Porque qual que é o detalhe do Web assembly? é você ter a compatibilidade que a gente já tinha, que a gente conseguiu conquistar dentro dos browsers com HTML, CSS, JavaScript.
Com essa tecnologia nova, todos os browsers têm que executar do mesmo jeito também, né? porque senão ia bagunçar, ia virar uma Microsoft, que é, não, o meu padrão, não, o padrão de todo mundo.
Então, com isso, o pessoal desenvolveu, é, é, querendo ou não, é um, é um, um assembly mesmo. Quando você abre lá, você tem dois tipos de arquivo. Você tem o ponto ASM, W, é, é o ASM, na verdade, né? É WASM e você tem o ponto wat.
O ASM é o compiladão mesmo, que é o que você manda pro wat.
W é o watch. Isso mesmo.
>> Foi uma piadinha.
>> Eu sei. Eu eu tentei eu tentei não rir.
Mas assim, qual que é a diferença desses dois? O ASM é o binário. É o que você manda pro browser >> executar, interpretar e fazer toda >> toda a execução e e e leitura é nesse ASM. E você tem o WAT, que é o Web Assembly Text.
Ele é um entre aspas intermediário para nós desenvolvedores podermos ver o que tem ali dentro, porque senão você vai ter que ficar abrindo o binário, o o o assembly de novo, né? Move, >> né? AD. Então, >> e cara, é isso que eu acho muito louco, porque aí talvez eu tenha esteja descendo muito no baixando o nível demais, mas nível >> o que eu entendi, peraí, fazer um resumo aqui.
>> Uhum. Vamos lá, >> tá? Vamos lá.
Eh, então eu tenho o Sandbox, >> isso >> que é o meu browser. Uhum.
>> Né?
>> Tudo que eu executo ali, seja ele JavaScript, ECMA Script, >> eh ele de alguma forma ele já é compilado em tempo real, em memória.
>> Exato.
>> E isso é executado ali dentro.
>> Isso não muda. Isso é isso é o que acontece. vida como ela é no mundo da >> examente. Exatamente. Beleza.
>> Quando eu falo de Web assembly, eu tô pegando algo que é muito mais complexo.
>> Uhum.
>> E tô fazendo, na verdade, um shift para que ele seja interpretado e compilado antes.
>> Uhum.
>> Para eu não ter essa sobrecarga aqui.
>> Uhum.
>> Para poder utilizar features que eu não utilizaria com uma com JavaScript ou com Typescript que não daria suporte para isso, certo? Uhum.
>> Posso usar outro tipo de linguagem, faço uma compilação >> Uhum.
>> E executo isso já compilado.
>> Exato. Exato. Pensa como se fosse uma JVM.
>> Isso.
>> Basicamente é um um princípio bem parecido com uma JVM.
>> O que eu tenho dificuldade para entender é quando eu penso em assembly >> Uhum.
>> Eu penso em mover dados entre os registradores, etc. Isso para mim parece uma linguagem que tá muito próxima do sistema operacional e de aplicações locais.
>> Uhum.
>> Eu não consigo imaginar como é um move para sabe para trocar a cor de uma dive, velho.
>> É, então, na verdade, então aí aí entra a questão. Você tá falando de dois mundos que para mim não se conectam, sabe?
>> Sim. Lembra, lembra que que a gente comentou uma hora que eh se você vai fazer uma aplicação, por exemplo, para perfuração de petróleo, você não vai usar JavaScript, você vai usar AC.
>> Uhum.
>> Então, qual que é a ideia do Web Assemble? É você abrir todo esse leque para coisas que realmente você vai usar.
esse leque C, Rust, Python, C#ARP, GO, você tem essas linguagens que elas são feitas para algum princípio mais paralelismo, questão de de garbage collector e por aí vai.
>> Então, o que que eles pensaram? Se eu preciso colocar alguma coisa executando que precisa de performance, eu não vou jogar no JavaScript. Eu vou externar isso para alguma linguagem que já faz essa e eh isso muito bem. pego o resultado deles e só mostro. Hum.
>> O Web assembly ele não vai mexer no seu dom. Quem mexe no seu dom continua sendo JavaScript.
>> Entendi. Eu vou usar o que eu preciso.
>> Exatamente.
>> Né? Eles eles meio que sem você criar uma linguagem nova, eles expandiram o leque de >> de possibilidades com o browser, não só no browser.
>> Agora eu te pergunta. Eu entendi, agora ficou claro. Então >> eu não vou usar isso para dentro do controle do browser, mas vou usar um processo para um processo paralelo.
>> Exato. Paralelismo é fundamental na parte do ABS >> e que não tem nada a ver com a camada de apresentação. É para outra coisa. Por exemplo, >> isso >> eu vou você me diz se o meu raciocínio tá certo, tá? E aí eu vou fazer a pergunta desafiante de 1 milhão de dólares do arquiteto.
>> Eh, vamos supor, eu tô rodando Photoshop online.
>> Perfeito. Inclusive Photoshop online usa o web assente.
>> Isso. Eu tô pergunt eu eu usei esse exemplo porque eu sei que usa.
>> Usa.
>> Então eu tô toda aquela camada de visualização, etc. Que eu que eu vis que eu que eu utilizo >> Uhum.
>> Ela é um front end básico que eu tô rodando JavaScript, TypeScript, etc.
Isso.
>> Quando eu aplico um filtro, >> quem tá fazendo isso é a sua máquina com o Web assembly que ela baixou do site da Adobe e sendo executado no na tua máquina.
>> Entendi. Agora eu entendi.
>> É isso. A manipulação daquela imagem é feito pelo web assemble, >> porque ali é processamento matemático puro, que aí eu consigo usar os moves, etc, de >> que eu rodo em paralelo.
>> [ __ ] eu entendi essa [ __ ] >> Entendeu? Então, basicamente é assim, eh, é uma via de duas mãos, tanto JavaScript chama o Web Assembly. Quanto a Absembly pode chamar o JavaScript? Ele não interfere aqui, mas ele executa as coisas e devolve pro JavaScript e pro browser.
>> Entendi. Porque da forma que a gente imagina o Web Assembly, dá a impressão que a gente tem uma aplicação inteira buildada. Uhum.
>> Inclusive a interface rodando no browser. Não é isso.
>> Não, não, não. Web assembly é só >> o G continua sendo, >> continua sendo browser.
>> Browser. Exatamente. Continua sendo o seu engine de HTML, o seu INE de JavaScript, o seu de >> Tô aplicando um filtro, algo que tem um processamento presado, alguma coisa aí.
Sim.
>> Exato. É, você fala pro o JavaScript fala: "Ó, Web Assembly, toma que é teu".
>> [ __ ] cara, esse episódio valeu uma aula.
>> Agora, eh, a pergunta de arquitetura que vale 1 milhão de dólares.
>> Por que fazer esse local se eu poderia fazer isso? Serverside, >> latência.
H, demora de processamento às vezes, porque mais, por mais que você jogue para um para um servidor, você tem a latência, você tem a demora de chegar essa informação lá, essa informação ser processada e devolvida. Quando você tem na tua máquina, você deixa o que é essencial mesmo no teu servidor, informações eh eh que sejam que não possam ser eh eh colocadas no browser, sei lá, código proprietário, alguma coisa que você não possa colocar no seu no na tua máquina ali, na máquina do usuário, que possa dar algum problema de segurança, alguma coisa. E coisas que você pode, você coloca ali na tua na tua máquina, na máquina do do usuário.
Porque pensar hoje em dia, cara, a gente tem processamento absurdo nas máquinas.
Então, por que que eu vou gastar processamento no meu servidor, na minha conta, se eu posso rodar aqui na máquina do meu usuário que já tá ali, ele já tá com browser, ele já baixou todo HTML, CSS, JavaScript. É mais um arquivo que ele vai baixar.
>> Tem tem coisa que precisa de um F Tunning, né? Que imagina o cara tá lá acertando o filtro do Photoshop.
>> Sim. E [ __ ] imagina se tu, porque >> se cada centímetro, cada pixel que ele empurrar ali, eu mandar pro servidor, volta, vai, volta.
>> Você e você colocou o ponto perfeito que é latência, né?
>> Porque se tem uma coisa que não tem no HTTP, é latência. É uma merda. Porque >> eh tudo precisa de um question response e ela dentro cai numa fila. Então, cara, não, essa latência ela não atende >> não >> processos que precisam ser eh justi na máquina do cara, né?
>> Não, um exemplo até de uso de de web assemble é a própria Netflix. O que que eles começaram a fazer? Eh, ao invés deles terem toda a a decodificação do vídeo do lado deles e mandando, eles estão decodificando na própria máquina.
>> Ah, então >> porque aí é questão de latência.
>> Entendi, >> né? Você imagina que você tem um streaming, você tá toda hora lá >> pega. Então imagina que toda hora o servidor deles lá tem que decodificar, mandar, decodificar, mandar. Não.
>> E o load que você teria lá no backend que você tá distribuindo em um [ __ ] de máquinas por aí.
>> Exato. Exato. Então você joga só o arquivo para dentro do da tua máquina que tá assistindo e a tua máquina máquina decodifica aquele vídeo, aquele trecho do vídeo.
>> Uhum.
>> Então você ganha em tempo, porque você não vai precisar desse vai e volta. Você só usa teu processador ali para decodificar. E aí você tem também a habilidade de, cara, para que que eu vou usar um formato só de vídeo dentro da máquina do cara? Eu posso botar esse web assembly e ele decodifica qualquer formato de vídeo que eu precisar. Pô, exatamente. E a gente sabe como transcoding de streaming custa um um absurdo, né, paraa internet, porque aí você tem que criar um end point que vai trazer naquela naquele formato, naquela definição. Sim, >> cara, posso trazer um bruto e o cara na máquina dele faz.
>> Exato.
Outros dois exemplos.
>> Pô, claro, por que que eu não pensei nisso antes, cara?
>> Né? A gente podia estar ganhando dinheiro.
Eh, jogo, né? Ao invés de você ter um um uma toda uma infraestrutura para você renderizar um monte de coisa do lado de um servidor, a Unity e Unreal, as duas engines usam Web assembly porque eles podem, ao invés de ficar jogando um monte de processador pro servidor, processamento pro servidor deles, eles executam muita coisa no na máquina do usuário, >> né? Então, mesmo sendo online, a questão do jogo, >> mas é um um desafio de sincronismo absurdo, né?
>> Sim. Absurdo, absurdo.
>> O Figma também usa, né, que o hoje em dia mais famoso aí de de design, né?
Então tem muita gente usando, >> cara. Isso isso faz muito sentido, inclusive para E aí sim, voltando pra inteligência artificial.
>> Uh, você tava com saudade, querido ouvinte.
Até agora você falou disso. Quem usa muito Assembly é o tensor flow. Tensor flow.
>> Tensor flow. Tensor flow GS. Porque ao invés dele tentar também ter um um GP, entre aspas, um servidor de LLM lá, >> não é um LLM, não é um LLM, né? É uma uma outra abordagem.
>> É tensor flow, é inferência estatística, né?
>> Exatamente. É uma outra abordagem, mas para quem não entende aí, é >> é é um uma parte de inteligência artificial, né? não é o LLM, mas ao invés de você jogar esse processamento todo para dentro de um servidor e esperar isso daí voltar, muita coisa ele acaba rodando no na própria máquina do usuário, né?
>> Não, eu tô pensando aqui agora juntando lé com cré do que eu aprendi hoje com que a gente sabe de de LLM.
>> Uhum.
Cara, para algumas tarefas simples, por exemplo, eh, perguntas triviais do dia a dia, eu poderia ter no browser, >> sim, >> um small language model, por exemplo, que eu poderia executar >> na própria máquina do cara com Web assembly. Ah, mas aí depende de GPU e o [ __ ] né? Não sei, mas >> mas seria viável, né? Seria viável. pod, enfim, tem alguns desafios aqui, mas eu poderia ter uma uma latência muito mais baixa, deixaria só o LLM rodando direto na no servidor. E, cara, perguntas simples assim, tipo, >> vai chover amanhã, não? Sei lá, roda na máquina do cara.
>> Sim. É, >> você poderia pré-processar aquele texto antes de mandar pro servidor.
>> Isso, exato. Você poder, >> cara, então, >> acabou o episódio.
>> É a questão do o Web assembly. Hoje em dia, eu não vejo muita gente falando, mas quando você começa a pesquisar de novo, ã, só eles falaram, cara, né?
>> E como que tá isso no mercado?
Então, e eu tenho visto, inclusive no LinkedIn pessoas pedindo para contratar desenvolvedores que entendam de Web assembly. O meu TCC na faculdade foi Web Assembly, né? E o que eu o que eu vejo é que assim virou uma coisa meio CC+ que poucas pessoas sabem que existe no dia a dia mesmo, poucas pessoas mexem, >> mas tá em tudo quanto é lugar, né? Mas é pro cara trabalhar, ele é tipo super sayajin do front end.
>> É porque na verdade nem só frontend, né?
Você tem que saber também ser mais, né?
Você vai construir aqui para poder usar aqui no browser.
>> [ __ ] tem que saber os dois lados, né?
>> Sim, sim.
>> Até porque, como você falou, tem uma especificação, não posso fazer qualquer boss em si.
>> Exato. Exato.
>> Tem uma especificação que eu preciso atender, né? E tem framework, liber?
>> Tem tem algumas algumas libs, não só para ser, mas as linguagens que eu me lembro que que você tem essa compilação pra Web assembly é C, C++, ã, C#ARP, GO, Rust é muito usado, acho que é a linguagem mais usada com Web assembly. Eh, e se eu não tiver errado também, Python. Eu sei que vai ter interpretado, pô.
>> Mas ele ele tem uma parte compilada do Python, não tem? Que você consegue fazer um um tipo um binário de Python. Eu já eu já cheguei a ler sobre isso. No meu TCC, eu usei C, >> talvez tenha, >> né? Mas o que mais usam hoje é Rust.
Você usa bastante C e tal, mas o que mais usam pra Web assembly é Rust. É, você já foi a época, já >> e para projetos mais modernos como esse, é natural que as pessoas partam direto pro Rust.
>> Sim, né? Porque provavelmente, a não ser que você precise já utilizar um um um código legado que você tem já escrito em C, na verdade você só vai adaptar um pouco ali para >> poder seguir as especificações do Web assembly e botar em produção, né, >> meu amigo? Que que aula que aula.
Obrigado. Aprendi demais aqui, né?
E você tem alguma consideração a fazer sobre toda essa aula?
>> Ah, eu acho legal que >> eu ia fazer uma piadinha, mas me perdi.
>> Eu acho que as pessoas e principalmente os desenvolvedores mais novos hoje, né, a coisa já tá tão mastigada, digamos assim, que muita gente nova ou que entrou agora na área não tem noção de todo esse caminho que foi percorrido, >> né? Então assim, a pessoa não precisa chegar e usar o que a gente usou lá atrás, tal, mas pelo menos entender e saber que isso existiu e como a gente chegou até aqui, acho que é sempre importante, né?
>> Exato.
>> Porque você saber questão de engine, questão de de árvore de dom, então, né?
Por mais que você não faça isso, por exemplo, os os frameworks e libs hoje já fazem todo esse essa >> e esse gerenciamento para você, mas é importante você saber como funciona, né?
Isso acho que melhora até a questão de qualidade do seu desenvolvimento no final das contas.
>> Não pilote só o carro, entenda como funciona o motor.
>> Exatamente, >> meu amigo. Obrigado demais, cara.Ama >> junos.
>> Visódio sensacional.
>> E bom, você é quase sócio do PPT, então você tá sempre, já estamos, já estamos em casa. E só aproveitando, quem quiser buscar alguma coisa de de web assembly, o site da Mozilla de documentação é Mozilla Developer Network, só jogar lá MDN Web assembly e os primeiros resultados já tem muita documentação lá.
>> Sim. Vai lá que tem muita coisa interessante e que você pode >> entender um pouco mais sobre o mercado que você tá envolvido, ainda mais se você for >> desenvolvedor frontendente, etc.
Entenda, porque isso pode dar um plus aí na >> Sim. na na tua carreira, né?
>> Tem mais conhecimento.
>> Sei, irmãozão. Obrigado, cara. Obrigado novamente pela você que ficou com a gente até agora. Se você ainda não deixou seu like, por favor, >> se você não deixou seu comentário, se você não está seguindo a gente ainda, caiu aqui de para-quedas.
>> Então, o momento de você fazer isso é agora. E se você quer contribuir um pouco mais com o BPT no compilo, você pode ser membro do BPT no compilo. Vai lá, botãozinho >> seja membro do lado do Na verdade ele só aparece depois que você está seguindo, né? Então você já tem que ter cumprido a primeira parte de sigue o PPT no Cupila, seja membro. Seja sendo membro do PPT no Cupila, a gente tem um incentivo financeiro do YouTube aqui, que você vai contribuir um pouquinho com a gente todos os meses. Uma cervejinha aqui para nós, né? Exato. Exato.
>> E se você, se a gente consegue trazer um pouco de acalanto, um pouco de conhecimento, >> Exato, >> né? Ou ou até uma luz, um entretenimento, né, Glob? Então, ajuda a gente lá porque dá trabalho para fazer essa bagaça aqui, né? É isso aí. Se você não pode contribuir dessa forma, você já contribui demais >> eh distribuindo, >> like, distribuindo, >> like, distribuindo, manda no Slack, >> comentando também. comenta, manda no grupo da família, sei lá, imprime um papel com a foto dele e põe no post. Não faça isso, não.
A não ser que você esteja precisando espantar mosquito. Aí, aí funciona.
>> Ajuda a gente a crescer nossa comunidade que estamos aqui para trazer conhecimento para você e fazer o nosso mundo de TI cada vez melhor. Obrigado.
>> Perfeito.
>> Obrigado, meu irmão. Obrigado você que acompanhou a gente. Valeu,
[Música]
Episódios Relacionados
1h 27minDesenvolvimento Web: Explorando Frameworks Frontend, Tendências e Melhores Práticas | PPTNC Podcast
Bruno Lins, Clauber Stipkovik
24 de jan. de 2024
1h 30minGRAPHQL NA PRÁTICA COM A BASE DIGITAL
Gustavo Bremm, Mário Klein
15 de mar. de 2023
1h 56minN8N e Lovable são o Fim do Dev Júnior? | PPT Não Compila Podcast
Felipe Kimio Nishikaku, Levi Bertolino
22 de out. de 2025
1h 58minAgentes de IA em Arquiteturas de Dados em Tempo Real | PPT Não Compila Podcast
Pedro Busko, William Leite, Daniel Takabayashi
1 de out. de 2025
