“Você precisa conhecer a pilha da web e o C ++”: uma entrevista com Alexei Kozyatinsky sobre o desenvolvimento do Chrome DevTools e não apenas

Como desenvolver usando o Chrome DevTools, todo mundo sabe. E como é o desenvolvimento do Chrome DevTools? Alexei Kozyatinsky trabalhou anteriormente no Google e fez exatamente isso, e agora ele se mudou para a Netflix, mas não se afastou muito de suas atividades anteriores.

O que exatamente ele está fazendo agora? Quão realista é para um desenvolvedor comum que não seja do Google copiar algo útil no DevTools? Quais computadores os engenheiros do Chrome usam?

Atualmente, estamos realizando a conferência HolyJS 2019 Piter, onde Alexey já fez um novo relatório, “Chrome DevTools Protocol” (a gravação pode ser vista na transmissão gratuita ). E nessa ocasião, ele foi interrogado em detalhes por dois membros do comitê do programa HolyJS: Dmitry DmitryMakhnev Makhnev e Alexei zolotyh Zolotykh .

Dmitry Makhnev: Conte-me um pouco sobre você. Onde, como, onde, o que você está fazendo agora?

Alexei Kozyatinsky: Volto um pouco e digo que o Chrome DevTools no Google trabalha há mais de quatro anos. Basicamente, fiz um depurador JavaScript e tudo relacionado a JavaScript, Node e tudo o que pode ser imaginado em torno do JavaScript em geral. Agora trabalho para outra empresa chamada Netflix. E aqui eu vim para fazer uma coisa muito simples: eles têm seu próprio mecanismo interno da web com seu próprio JavaScript estranho. E a coisa toda precisa de suas próprias ferramentas legais, que podem ser chamadas de "Chrome DevTools". E, consequentemente, meu objetivo era fazer essas ferramentas.
Ainda é relevante, faço algo e sou absolutamente responsável por tudo: para o back-end deste negócio, para o front-end do DevTools funcionar normalmente. E, ao mesmo tempo, nosso objetivo é trabalhar de forma a continuar contrabandeando no Chrome DevTools, para atualizar todos os patches possíveis. Para não sermos forçados, dispersaremos para sempre e perderemos o resultado do trabalho de meus colegas legais do Google. Então continuo fazendo o mesmo de antes - Chrome DevTools.

Dmitry: Legal.

Alexei Zolotykh: Sua biografia sobre o HolyJS tem a seguinte redação: "Ele liderou a maioria das tentativas da empresa de melhorar a vida dos desenvolvedores, começando com pilhas assíncronas e terminando com os novos objetos de consulta da moda". Primeiro, por que tentar? E, em segundo lugar, você pode nos dizer mais - isso provavelmente é mais sobre o Google?

Alexei: Vamos começar com a palavra "tentativa". Muito boa pergunta. E eu tenho uma resposta para isso. Essa era originalmente a palavra "esforços". Desde que vivo e trabalho na Califórnia há alguns anos, uma tradução me falhou. Por que decidi traduzir a palavra "esforço" como "tentativa"? Talvez isso ainda não seja uma "tentativa". Obviamente, foram “tentativas”, porque tentamos fazer algo, mas foram tentativas bem-sucedidas, concluímos a maioria delas.

Mas, ao mesmo tempo, Query Objects - era algo pequeno que pode ser lido no Twitter ou no Medium, e é isso que concluímos. E a depuração assíncrona é o que precisamos concluir no Chrome DevTools. Começamos a fazer isso, tentamos várias vezes, porque isso não é uma coisa trivial. Você tenta uma solução - ouça os usuários, eles chegam até você e dizem: "Eu não entendo o que está acontecendo aqui, você pode fazer algo com isso?" Você tenta diferente, tenta fazer outra coisa e, passo a passo, algo acontece. Mas é importante dizer que a maioria das tentativas foram bem-sucedidas.

No Google, passei a maior parte da minha vida de desenvolvimento. Eu vim lá uma vez como estagiário. Foi em tempos maravilhosos quando havia um escritório do Google em São Petersburgo. Chegando lá, eu estava fadado a participar do Chrome DevTools: não tinha outra escolha, porque vim como estagiário da equipe do Chrome DevTools. Me disseram: “Aqui está um projeto interno muito simples. Temos uma API legal que nos permite pegar todo o código JavaScript, processá-lo de alguma forma, devolvê-lo e dizer ao Chrome para executar outro JavaScript em vez do JavaScript que veio até nós. ”

Nós tínhamos essa API e, com base nisso, era possível construir uma árvore AST. Lembro-me de que nas árvores AST havia um excelente relatório sobre o HolyJS. Era necessário analisar a árvore AST e instruir o código de forma a medir o tempo de execução e, na verdade, escrever um perfilador de ferramentas. E era um projeto da Internet, eu ainda o tenho em algum lugar no GitHub. Ele não funciona no Chrome há muito tempo, porque a API usada foi solicitada a cortá-la - era difícil de manter. Fiquei muito triste naquele dia, porque era a API na qual todo o projeto foi construído - "exclua-o". E eu apaguei. Depois de três meses, fui de estagiários a engenheiros - fiquei no Google e comecei a fazer tudo relacionado ao JavaScript. Começou com algo muito simples: eu tinha que consertar console.log (). E, gradualmente, aconteceu que a parte principal da equipe de ferramentas relacionadas ao JavaScript deixou a equipe por algum motivo, e eu fiquei com quase todo o JavaScript. Naquele momento, foi muito assustador, mas me preparei e gradualmente comecei a fazer alguma coisa, a entender alguma coisa.

Ao mesmo tempo, o JavaScript desenvolvido, como sabemos, aspira, promessas apareceram lá. Agora já temos assíncrono / aguardar, as funções de seta apareceram em todas as estruturas possíveis, por isso precisávamos de pontos de interrupção em linha (não havia maneira sem eles) - e eu fiz, fiz, fiz muitas dessas pequenas melhorias. As pilhas assíncronas acabaram dando muito trabalho; este é um modelo assíncrono que descreve a assíncrona no JavaScript em uma linguagem muito simples.

E como você não pode trabalhar no Chrome DevTools no front-end JavaScript e não sabe nada sobre o mecanismo V8, no decorrer de todo esse trabalho, gradualmente tive que entrar cada vez mais no V8. Eu tenho muitos patches lá. Em algum momento, movemos o back-end JavaScript do código do Chrome para o código V8. É claro que isso era lógico desde o começo, mas historicamente ele não estava lá. Ao mesmo tempo, o Node veio até nós, tivemos que suportá-lo de alguma forma e decidimos que, se podemos depurar o V8, e o Node parece usar o V8, por que não fazemos o Node nos apoiar? E fizemos, neste projeto eu não era o mais importante, mas ajudei ativamente aqueles que o fizeram. Faço tudo isso no Google há cerca de cinco anos.

Dmitry: O que você considera o mais legal e o mais difícil deles?

Alexei: Por alguma razão, o último é lembrado melhor. E o último foi um projeto interessante que fizemos. Agora, no console do Chrome DevTools, quando você digita, pode ver o resultado ao vivo de fazer o que digita. Se você quiser testar os novos recursos JavaScript (na época era o BigInt), basta imprimir no console, ver imediatamente o resultado e não precisar pressionar “Enter” e obstruir o console com um bilhão de resultados. E fazer o certo é mais difícil do que parece. Era muito importante para nós que, com a execução gananciosa de todas as suas expressões, não destruíssemos o estado do seu programa, caso contrário, todos os nossos usuários ficariam muito chateados. E para fazer isso, tivemos que pegar o JavaScript, pegar a V8 e adicionar a capacidade: executar qualquer expressão, mas garantir que ela não mude o estado do seu programa. E foi difícil, por um longo tempo e ninguém fez isso antes de nós, não existem mais mecanismos JavaScript desse tipo. Não tenho certeza de que existem esses mecanismos. Talvez em Java exista (porque em Java, como sabemos, está tudo lá), mas não tenho certeza. E naquele momento nós fizemos.

Foi um processo muito longo, que envolveu muitas equipes diferentes, porque era importante para nós não apenas executar sem “efeitos colaterais”, mas também garantir que, se de repente você começasse a executar um loop infinito enquanto (verdadeiro), não pendurasse tudo. no mundo, porque o fluxo JavaScript ainda é o mesmo. E esse foi um esforço separado: o código do Chrome não gosta quando o JavaScript termina em um momento aleatório; nesse caso, ele gosta de dizer: "Hum ..." e falha. Tinha que ser consertado. E nós fizemos isso também.

O projeto deste trabalho resultou na obtenção de uma patente do Google. O Google patenteou para não perseguir você, mas, como a maioria das outras empresas (exceto a antiga Oracle, provavelmente), para se proteger se algo acontecer se alguém vier até eles e disser: “Cara, você criou o Google "Pesquisa, isso é ruim, temos patentes." E por algum motivo, esses caras farão o depurador JavaScript ao mesmo tempo. O Google dirá: "E aqui temos uma patente para o depurador JavaScript". Bem, os advogados de patentes sabem melhor o que está acontecendo lá, mas nós o patenteamos, foi divertido. O Google distribui um pequeno pedaço do quebra-cabeça quando você obtém uma patente. Ele é muito legal. E foi muito interessante, porque ninguém havia feito isso antes, e conseguimos fazê-lo.

Dmitry: E parece que algo é simplesmente exibido no console.

Alexei: Sim, sim, é tudo muito "simples", é claro. A citação de alguém foi que qualquer tecnologia bem feita é indistinguível da mágica.

Dmitry: Bem, sim, interessante. E o que realmente queria fazer, não podia ser feito? Mais alguma coisa? Mais poderoso?

Alexei: Essa é uma pergunta muito perigosa. Você sempre quer fazer tudo, e nunca há tempo suficiente. É claro que gostaria de terminar as coisas que começamos, mas não terminei. Este é um modelo assíncrono, e a depuração assíncrona ainda precisava ser concluída, é claro, e tornado mais óbvio para o usuário a execução de mais algumas etapas. Não tenho certeza do que fazer lá, mas pelo importante que eu queria concluir: na V8, existe um mecanismo semelhante ao HotSwap em Java e com tecnologias semelhantes, quando você pode pegar um pedaço de código em seu programa em execução no momento e atualizar o ganho. Por exemplo, você resolveu uma exceção e sabe como corrigi-la, corrigi-la imediatamente, salvar o arquivo e tudo funciona mais além, e como se não houvesse exceções - tudo foi corrigido ao vivo. Esta é uma ferramenta muito legal. Algumas pessoas pensam que ele pode até de algum modo substituir a depuração, porque, gradualmente, você escreve o código em pequenos pedaços e pode ver imediatamente o que acontece - praticamente não há necessidade de depurar depois disso.

E por muito tempo, cerca de 9 a 10 anos atrás, tivemos um código que fazia isso. Foi escrito um pouco em outro mundo, em uma realidade diferente - havia um V8 diferente, não havia todos esses Ignition, TurboFan e tudo mais. Não tenho certeza de que naquele momento, até o Crankshaft estava lá, é o compilador anterior no V8. Não havia nada. E async / waitit também não estava lá, é claro. O código era muito antigo, usava alguns utilitários V8 internos muito antigos que suportavam apenas esse código, porque naquela época ninguém queria entender esse código e reescrevê-lo.

Em algum momento, sentei-me e reescrevi-o, e ele começou a falhar menos. Mas ele ainda costuma dizer que não pode editar seu código, porque, por exemplo, não há suporte suficiente para geradores. Ao escrever esse código, havia um gerador por milhão de linhas de código em JavaScript. E quando obtivemos assíncrono / espera, cada função assíncrona / espera é realmente um gerador em si. Portanto, se você pedir para editar o código com async / waitit, ficará desapontado.

E como essas ainda são ferramentas para desenvolvedores e depuração, há um recurso desagradável: se elas não funcionarem duas vezes em cada dez ao usar a ferramenta, não a usarão mais. E eu gostaria muito de terminar. Talvez terminemos, porque agora eu provavelmente levarei o V8 para o meu novo local de trabalho e, por isso, posso continuar trabalhando nele.

Dmitry: Isso poderia funcionar exclusivamente durante a depuração ou teoricamente poderia alterar uma parte do aplicativo em alguma produção de aplicativo de página única?

Alexey: Do ponto de vista da V8, na produção, é mais fácil mudar, mais difícil mudar quando você faz uma pausa. Se estiver em pausa, você terá o rastreamento de pilha atual, que já está em execução. É necessário atualizar esse código e forçar toda essa pilha atual, que se refere a algumas variáveis ​​em seu código, a continuar trabalhando. E quando você acaba de produzir, pode esperar o momento em que o JavaScript termina (vamos torcer para que você não tenha um tempo (verdadeiro) lá), e nesse momento tudo é imperceptivelmente substituído.

E é muito mais simples, porque você pode simplesmente substituir o código, não é necessário atualizar todos os links. E a principal dificuldade é, obviamente, substituir todos os links, reiniciar todos os quadros, reiniciar geradores e assim por diante.

Alex: De repente, tive uma pergunta sobre o uso do Chrome DevTools como um IDE. Existe uma função assim quando você edita o JavaScript e, de alguma forma, pode vinculá-lo ao sistema de arquivos, e a mesma coisa com os estilos. E eu tenho muitas perguntas para ele, porque não funciona. E sou uma pessoa preguiçosa, gosto de consertar em um só lugar, por exemplo.

Alexei: A questão, aparentemente, é por que não funciona. É importante dizer inicialmente que o Chrome DevTools nunca foi um IDE, nunca se posicionou como um IDE. O IDE é um projeto de uma escala diferente, requer outros esforços e mais pessoas. O Chrome DevTools foi criado primeiro como ferramenta e depois como editor. Diferentemente dos IDEs, que aparecem como um editor e, em seguida, adicionam um depurador, plug-ins e assim por diante.

Ao mesmo tempo, entendemos que seria muito agradável para nossos usuários editar e salvar, houve várias tentativas para fazer isso - agora, provavelmente, a segunda ou terceira tentativa ... Mas tudo se resume ao fato de que na web, levando em consideração a existência de todos esses compiladores CSS do webpack e tudo o mais, uma tarefa não trivial é aplicar as alterações novamente. Você altera o código que vê dentro da página, precisa entender de onde esse código veio na sua página e aplicar cuidadosamente a alteração novamente.

Portanto, por outro lado, podemos dizer que podemos simplesmente fazê-lo funcionar para pessoas que não possuem configurações tão complexas, mas, infelizmente, essa é uma porcentagem muito pequena de nossos usuários. Agora todo mundo tem webpack, Babel e assim por diante. E eles facilmente transpõem e fazem algo em uma direção, mas obter informações na direção oposta é um problema. Para CSS e SASS, isso foi feito de alguma maneira mágica e, às vezes, parece funcionar, eu não o usei.

Se isso vai mudar no futuro, você ainda pode perguntar. Você pode usar o Código do Visual Studio ou seu IDE favorito (WebStorm ou algo mais), editar o código lá e o Chrome DevTools tentará aplicar essas alterações ao vivo. Mas, na verdade, temos um projeto separado para o frontend do Node, provavelmente falaremos sobre isso mais tarde, funciona um pouco melhor lá, porque, graças a Deus, o Node tem o nível máximo de compilação e a compilação TypeScript em JavaScript. E já é difícil lá, mas ainda espero que no Node a maioria dos pacotes e módulos seja escrita em JavaScript puro, sem etapas intermediárias de compilação. Eu não respondi a pergunta, mas como pude.

Dmitry: O que você acha, como o Chrome DevTools se desenvolverá mais em princípio? Quais são as coisas mais legais que você pode esperar dele?

Alexey: Essa é uma pergunta difícil. Em algum momento, uma pessoa apareceu no Google I / O que criou outra ferramenta conveniente para designers. Esta extensão para o Chrome, infelizmente, não me lembro do nome. E adiciona diretamente na parte superior da sua página alguns elementos que facilitam a edição e a execução de tudo como designer. E havia idéias de que o Chrome DevTools poderia ser uma ferramenta melhor para designers. Essa já é uma ferramenta bastante conveniente que pode, por exemplo, observar CSS e assim por diante, mas você ainda pode torná-la muito mais ideal e conveniente. Por exemplo, edição mais conveniente das propriedades flex e outras pequenas melhorias.
E há uma parte importante do trabalho no Chrome DevTools: o projeto é muito grande, possui muitos usuários e um grande fluxo de bugs que qualquer pessoa pode arquivar no crbug.com . Eles precisam ser reparados, existem muitos deles e muito tempo é gasto apenas para fazer tudo funcionar. Para depurar a edição ao vivo do JavaScript, sobre a qual falamos, o hotswap pode ser um bom próximo passo, mas pode ou não, não sei.

Alexei: O Chrome DevTools, ao que me parece, é objetivamente o software mais sofisticado para ajudar os desenvolvedores da web. Mas existem outros navegadores - Safari, Edge ainda está lá, Firefox novamente. Há alguma ferramenta que eu gostaria de arrastar de outros navegadores no Chrome DevTools? Existe algo que você gosta, como é legal?

Alexey: os desenvolvedores do DevTools do Chrome consultam regularmente outros navegadores. Pelo interessante que notei recentemente, lembro que o Safari tinha um console muito conveniente. Eles estruturaram muito bem a saída para o console e adicionaram navegação usando as setas nos resultados. Você pode selecionar um objeto lá, pressione "right" - ele será aberto. Era malditamente conveniente. Como resultado, agora esse recurso está no Chrome DevTools.

No Firefox, pelas coisas interessantes do DevTools, parece-me que elas suportam um pouco melhor a edição visual de todas as propriedades CSS - com isso quero dizer propriedades como flex e outras - elas mostram a grade diretamente na parte superior da página e você pode mudar tudo para baixo. Isso é legal, temos parcialmente, mas não completamente. Acho que o Firefox DevTools atualmente tem de longe o melhor suporte para o WebAssembly. Se, por algum motivo, você precisar escrever o código do WebAssembly, eles serão muito melhores do que nós, porque não tínhamos nada há seis meses, agora eu não o verifiquei. Eu acho que eles estão investindo muita energia nisso.

Quanto ao Safari ... de certa forma, o Chrome DevTools é uma bifurcação do Web Inspector do Safari, por isso aproveitamos o melhor que eles tinham.

Lembrei-me do importante! Provavelmente apenas o Firefox possui Depuração de Viagem no Tempo. Em um Mac, no Nightly Builds do Firefox, você pode entrar na Depuração de viagens no tempo. Fiquei calado sobre ele quando me perguntaram sobre os seguintes grandes passos: parece muito legal, muito monumental - ainda não acredito que seja muito útil. Ponto de vista pessoal. Mas eles têm, você pode tentar, se ajudar, será uma nova ferramenta interessante.

: . , , -- . , ( ) , , CSS. , - , .

, , . ? , ? , - ?

: . ? , , crbug.com , feature request. feature request', , : , , . , . : Chrome DevTools, Chrome DevTools, , . , , , .

, , , — , , Chrome. , , , Chrome DevTools , . , -, , Chrome . -, - , , , - , , … , , .

: Google? :)

: Google , , . - , layers panel, -. , , . , , , , . , , .

? Cmd/Ctrl + Shift + P, Show layers — . Discoverability Chrome DevTools — , , , . - , . , - . , , , .

: , , , .

: .

: , - . . , , .

: HolyJS. .

: - , , - , . , - . , : - , - . - .



: , - Chrome, , , . . — , . — . - - , ?

: . , Chrome . -, Chrome, .

GitHub Chrome DevTools ( ), , DevTool' Chrome, . , , - Chrome DevTools, . , - , -, . - . , cookies.

, DevTool' , , . , JavaScript', CSS, HTML . single-page application. , - - , , , .

— - , (, - ), Chrome, , , . cs.chromium.org , .

, , « », Chrome , good first bug — , .

, , JavaScript — V8 , Chrome. , , , . - , - , - Chrome, Node. , - Node, Node, Chrome. , , .

, V8 - , - DevTool' . Chrome, , - , 15 Chrome.

: , Chrome?

: , Lenovo , Google Chrome . Xeon, 64 128 — . , 32 . , . , GTA 2 .

, - . - — Google , , Google , . , , . Chrome C++, . , .

: .

: , SSH - , , . - , SSH. Mac, : « ». Mac', , , - , -, , , .

: . , ?

: -, . Cessna, , 17 . - 17 Chrome DevTools.

: , -, , . , , . -, ndb ( - ), . , , Chrome DevTools, - V8 Node. ndb, - Node? - ?

: ndb — . Chrome DevTools Node . : Node URL, , . dedicated — Node. chrome://inspect, «open dedicated frontend», - . , , . - , , , . , , , — . value, , , .

, , . -, npm — «npm install -g ndb» — . Chrome, . Chrome, . 2,6 Chrome DevTools . . .

, - value: child-, , . ndb .

, Node Node. , , , - Node, , .

- Visual Studio Code, Node. . - IDE , Python, , . Node. : Chrome DevTools — , ndb — Node.

, , Google Chrome Labs — GitHub- , . , , 15 Hacker News - . , ( , ), - . .

, , Node . , Node Windows, Linux Mac, — , , .

, , , , n . - , , . , environment- Windows , Linux — , . . Windows-, - .

, . - , , , . , . , — , Node, , , . , , , , . ndb, , Carlo . Carlo — Electron. Electron , , Electron .

: Google, Chrome?

: , ndb. , , ndb.

: , . Chrome DevTools, , , ? , , ?

: Chrome DevTools? . , , , Chrome DevTools, , JavaScript. , , , , Java, JavaScript, , - . , .

: -, . -. , , C++. , Chrome DevTools , . , , - -, , , . Chrome DevTools , - C++, -.

C++, JavaScript, CSS… HolyJS, , CSS — , , . , , ! .

, C++, -, . - , , , , . , careers.google.com , , , Chrome DevTools, , , software engineer-, . software- , , : « Chrome DevTools».

: ++? - .

: . , , — , , , . : - , , , - .

, C++ - , . , «Hello, world!», . , , Chrome. C++ Chrome, C++ 11, . Boost .

: . , - 239, ? - ? single page application.

: , , , , . , computer science- . : — , — , .

, . Google , Google . , , . , . computer science- , …

239, , , , , . , , - . , JavaScript — ? Isto não é um problema. , a, b c, JavaScript, , JavaScript . JavaScript — , .

, CS- , . , - , , . , , , , -. , , computer science- — , , must have, . , , , , . , .

: , - JavaScript, -, , - ?

: . , , , - , , , Stack Overflow, , . , , . , async- , garbage collector .

: . : ? , , ? ? .

: . , CSS . , , . — Google-, - . , , , , , . , , . .

, — . . , , DeepMind StarCraft (. .: Zest, soO Stats ) — Reinforcement Machine Learning. Reinforcement Machine Learning . youtube, 15 , , .

, --, - , , . , , . , CSS.

: ?

: , . , . , . , YouTube — CSS. , , . , , — .

: . ? ?

: , , . Node.js, Node. , . , , - - , — , . , , - , , . Isso é complicado.

, — « Node.js» — , , , , Node.js, . , , , . , .

: . , . , -, ? - , , - — , . ?

: , . , , . , , - . , - , , - , -. . — DevTools: — , , — .

. , , . , , , JavaScript-, , . . , , , — .

, (« , CSS -») . , (diversity, CSS ), . , , . . — . — , . — .

: : HolyJS?

: HolyJS, . , , . , , , .

: , ...

: , . — . . . HolyJS , , , . , , . , , , , , — . . - .

« Chrome DevTools» ( ) HolyJS, 24 . YouTube , , .