Ivan Akulov é um especialista em desenvolvedores do Google em tecnologias da Web e fundador da empresa de desempenho PerfPerfPerf . Muito em breve, no HolyJS 2019 Moscou, ele realizará um workshop dedicado, curiosamente, ao desempenho - encontrando problemas no React, depurando aplicativos lentos e outras coisas em tempo de execução.
Para leitores e visitantes mais imersos do HolyJS 2019 Moscow no tópico, discutimos com Ivan:
- Os problemas de desempenho mais populares;
- Como medir o desempenho e qual pode ser o problema;
- Como otimizar o desempenho;
- Procure por problemas de desempenho no React;
- Os benefícios de mudar para HTTP / 2 e HTTP / 3;
- É melhor usar uma estrutura compacta em novos projetos;
- Sobre os benefícios do WebAssembly;
- Onde procurar informações úteis sobre desempenho;
- Qual será o workshop e quem estará interessado em participar (e por que participar de workshops)?
Dmitry Makhnev e Artyom Kobzar fazem perguntas do comitê do programa HolyJS.
Dmitry: Diga-me algumas palavras sobre você.
Ivan: Sou Ivan Akulov, consultor de desempenho, especialista em desenvolvedores do Google, da minha agência de consultoria de desempenho.
Dmitry: Você diz que uma agência de consultoria não é o trabalho principal. Mas basicamente o que você está fazendo?
Ivan: Meu tempo agora está distribuído aproximadamente, de modo que estou meio carregado com o trabalho com um cliente antigo. Trabalho com uma empresa brasileira, juntos criamos uma plataforma de marketing de conteúdo Wordpress, gerencio a infraestrutura e um pouco de desenvolvimento de produtos e algum tipo de visão comum.
O resto do tempo dedico a consultoria, discursos, artigos e tudo mais.
Dmitry: Há muitos apelos para consultoria de desempenho? Como isso funciona?
Ivan: Em geral, depende muito do mês ou algo assim ...
Dmitry: Quando os astrólogos anunciam o mês da performance? :)
Ivan: Antes, quando os contadores anunciam um novo trimestre! (risos) Não estou procurando ativamente clientes no momento, o principal motivo é que não há tempo para isso agora, porque já estou carregado com o que tenho. Mas, em geral, tudo parece que eu escrevo alguns artigos, faço alguns discursos e, ao trabalhar com alguns clientes, eles se lembram de mim e me recomendam novos. Principalmente as pessoas vêm graças à rede, e caras bem legais vêm.
Artyom: Como você chegou ao tema da performance antes de criar sua própria empresa de consultoria?
Ivan: Na verdade, tudo começou com o fato de reescrevermos um projeto antigo no Epam por meio ano no Wepback. Havia um projeto antigo com um monte de legados, com sua própria estrutura de front-end, metade dos quais trabalhava na pilha java. E como passamos meio ano tornando o webpack relativamente rápido, obtive experiência com o webpack. Naquele momento, eu podia escrever um webpack-config de média complexidade, linhas de 20 a 40, literalmente da memória, sem pesquisar nada, sem espiar, sem espiar e até sem usar o IntelliSense.
E percebi que essa experiência poderia ser útil para outra pessoa. Decidi tentar iniciar algum tipo de consultoria no campo do webpack. Fiz uma aterrissagem para mim, coloquei em algum lugar, duas pessoas vieram, trabalhei com uma delas. E de alguma forma tudo começou.
E mais tarde, passei suavemente do desempenho relacionado ao webpack para o consultoria de desempenho em geral.
Artyom: Você conseguiu melhorar o desempenho da montagem nesse projeto?
Ivan: Esse projeto não funcionou perfeitamente, não da maneira que eu gostaria de terminar no final. Era uma coisa que os caras chegaram em um momento em que eu realmente precisava de dinheiro e ainda não entendia como negociar, cuidar de mim mesma e levar meus interesses em consideração nessas negociações. Sugeri um pequeno preço fixo com uma quantidade insegura de trabalho, trabalhamos, ajudei-os, tomei uma decisão que parecia funcionar e corrigi o desempenho.
Depois, verificou-se que havia erros nessa solução, que eram muito complicados e erros estranhos surgiam em casos raros. Começamos a consertar, consertei um, segundo, terceiro bug, tudo isso durou um mês. E no final, em algum momento, os bugs pararam de acontecer, mas os caras decidiram me pedir outra coisa, mas como eu tenho um orçamento interno para isso, acabou completamente, eu apenas disse: "Desculpe, eu já estou carregado, e não Eu posso ajudar. "
Como resultado, até onde eu descobri, em alguns meses eles substituíram esta solução por outra menos complicada e funcionaram em 100% dos casos.
Para ser sincero, não me conheço ... Parece que vim e ajudei, e a decisão final que eles tomaram nasceu em nossas conversas anteriores, mas não sei o quanto eles ajudaram o que fiz. E quão satisfeitos eles estavam com tudo isso. Em suma, não foi tão perfeito quanto eu gostaria.
Artyom: E por falar em hoje, de alguma forma você rastreia clientes anteriores, como eles estão indo lá, tudo isso ajudou?
Ivan: Sim, definitivamente. Eu gradualmente desenvolvi algumas abordagens. Em primeiro lugar, no final do meu trabalho, tento obter algum feedback público de cada cliente, que pode ser publicado no site ou em algum lugar.
Em segundo lugar, desenvolvi uma abordagem para perguntar aos clientes no processo ou no final de um trabalho a pergunta "Como você está satisfeito com o processo atual, o fluxo de trabalho atual, algo atual?" com as opções de resposta "mais do que satisfeito", "satisfeito", "quase satisfeito", "não muito satisfeito".
E eu gosto dessa pergunta, porque ela fornece respostas específicas, e não uma escala tola de 1 a 5, que todos percebem à sua maneira. Até agora, nenhum dos clientes respondeu "quase satisfeito" ou "realmente não satisfeito". Foi satisfeito, feliz, e algo assim.
Artyom: Entendo corretamente que sua área de especialização em desempenho é voltada principalmente para o lado do cliente? Ou você tem toda a pilha da Web afetada pelas consultas?
Ivan: Sim, a área de especialização é voltada principalmente para a pilha de clientes, com a otimização de desempenho no back-end ou nos bancos de dados, trabalhei muito menos. Mas, na prática, se um aplicativo da Web desacelera, até mesmo algum artigo ou estudo, 80-90% dos casos - desacelera precisamente por causa do front-end.
Se um cliente entra e algo fica mais lento, na maioria dos casos, minha experiência é perfeita.
Sobre os problemas mais populares
Artyom: E o que acontece quando há alguns casos extremos? Quando temos um problema, não com a análise do JavaScript e seu lançamento, mas com o transporte. Quando a primeira interação é atribuída ao cliente, bem como ao back-end. É brega que o gzip foi configurado incorretamente; ele gira muito tempo. O que você faz nesses casos? E se sua análise está principalmente na linha de frente, como você encontra esses casos?
Ivan: Bem, isso geralmente significa que o tempo de resposta do servidor se torna muito longo. Se eu notar isso durante algum tipo de auditoria, procuro devtools, procuro na rede e vejo que o tempo do servidor é de 800 ms - para enlouquecer, leva muito tempo. E vou tentar entender como os caras têm um servidor, o que fazem durante cada resposta. Se for JavaScript ou PHP, provavelmente poderei descobrir tudo bem e corrigir tudo, se alguma outra linguagem com a qual eu não trabalhei precisar de ajuda.
Dmitry: Você pode citar algum dos 5 principais problemas de desempenho mais comuns encontrados na prática?
Ivan: Vou seguir o caminho que me lembro. Um dos problemas comuns que não ocorre em aplicativos Web complexos, mas em sites simples, é quando um desenvolvedor ou cliente coloca muitos scripts dentro da tag head sem os atributos assíncronos ou diferidos , e isso é ruim porque o navegador não pode iniciar a renderização da página até não carregará e executará esses scripts.
E se houver um servidor lento ou um script grande que demore muito para ser executado, a pessoa que usa o site não verá a página até o final da execução.
Outro problema comum são scripts de terceiros. Atualmente, estou trabalhando com um cliente a quem estou ajudando a melhorar a pontuação dos faróis . Inicialmente, a pontuação do farol era de 35 a 40. Eu vim, fiz todo tipo de coisa diferente, excluí JavaScript desnecessário, recursos de bloqueio de renderização, otimizei de alguma forma ... Depois de tudo o que fiz, a pontuação só aumentou para 55. E aconteceu que, se você for com esta página otimizada e comentar um único componente React que carrega todas as análises, a pontuação do farol saltará para algo em torno de 88-90 + pontos. Isso acontece porque existem muitas JSs que removem métricas.
Em alguns aplicativos da Web complexos, um tópico frequente é quando os desenvolvedores instalam algum tipo de biblioteca grande e o empacotam totalmente no pacote, embora não seja totalmente utilizado. Geralmente, é o Moment.js , no qual existem enormes arquivos de localização, 165 KB de arquivos de localização minificados que quase ninguém precisa, ou lodash , nos quais existem muitos métodos, e todos usam apenas de 10 a 20.
Com o desempenho da renderização, costumava haver um problema frequente quando os desenvolvedores desligavam algum tipo de manipulador de eventos, por exemplo, em uma rolagem de eventos, levava de 5 a 10 ms e, toda vez que você tentava rolar por algo, a página inteira ficava em atraso. Agora isso se tornou menor, porque no mesmo Chrome [adicionados ouvintes de eventos passivos] ( https://stackoverflow.com/questions/37721782/what-are-passive-event-listeners ).
Sobre como medir o desempenho
Dmitry: No decorrer dos casos, surgiu uma pergunta sobre o Lighthouse. Na minha opinião, todos os três estavam no BeerJS Summit , e houve um relatório interessante - (centésimo) de Alexey Kalmakov . Não há entrada , mas vi um artigo semelhante sobre Habré , e essas coisas um pouco comprometem o farol. Se você a usar apenas como uma ferramenta para avaliar o trabalho de um engenheiro de desempenho, poderá fazer alguns truques.
Você tem alguma ferramenta, talvez até auto-escrita, com a qual avalie claramente se foi bem-sucedida ou não. Por exemplo, você assina um contrato e é informado que precisa fazer o desempenho x2. Que conjunto de ferramentas você usará para isso?
Ivan: Bem, primeiro, se concluirmos um contrato e concordarmos com x2, concordaremos com algum tipo de instrumento. Mas, em geral, além do Lighthouse, eu realmente gosto do WebPageTest . Essa é uma ferramenta avançada de desempenho na Web muito legal que permite testar seu aplicativo a partir de um local arbitrário real, por exemplo, Brasil ou Austrália, em um dispositivo real, por exemplo, muito fraco, como o Moto G.
Isso é mais legal que o Lighthouse, porque emula tudo isso e somente após testes em um dispositivo real você sabe que o site está sendo renderizado por 15 segundos. O segundo benefício - fornece várias métricas super detalhadas de todos os tipos de gráficos, como carregamento. Eu o uso regularmente para ver algumas coisas.
Dmitry: Você escreveu alguma de suas ferramentas, por exemplo, sobre o Chrome DevTools Protocol ? O que falta em ferramentas?
Ivan: Eu escrevi meu instrumento em cima do Lighthouse. Para trabalhar com um dos clientes, eu precisava de uma configuração que me permitisse medir o desempenho de uma página com o Farol em um ambiente razoavelmente estável, considere a pontuação do farol e copie-a para a mesa. Há um problema com ele: o farol no PageSpeed Insights não é muito estável. Se você medir a mesma página três vezes, poderá obter três medidas diferentes. Além disso, eu precisava medir não as páginas que estavam prontas e publicadas na rede, mas a local. E a única opção é executar o Lighthouse localmente, o que também afeta muito a pontuação do farol, porque A pontuação começa a depender do que funciona no seu laptop. Por exemplo, lançou o Docker, a pontuação caiu 2 vezes.
Para este caso, eu precisava medir o Lighthouse previsivelmente. Escrevi um roteiro que rodava o Lighthouse três vezes, uma pontuação, pegava o valor mediano das três vezes e o fazia por muitas páginas com muitas configurações. Aluguei um servidor DigitalOcean para isso e executei tudo lá para torná-lo o mais isolado possível de fatores externos.
Artyom: Você mencionou um caso interessante sobre diferentes métricas do Lighthouse. Houve um artigo recente, Uma introdução ao percentil 99 para programadores , no qual eles concluíram que as ferramentas modernas de benchmarking e, em princípio, apenas o micro-benchmarking não provam nada.
Com ferramentas modernas, pode ser que eu tenha feito uma referência, você escreveu, escreveu Dima, e todos dirão coisas completamente diferentes. E agora em um mundo sem um conhecimento mais ou menos profundo em teoria e estatística, o benchmarking não parece muito plausível. Você mencionou o Farol, mas há alguma evidência que você recebeu no benchmark, alguma confirmação adicional?
Dmitry: Talvez misture Lighthouse com alguma coisa? Você mencionou o WebPageTest. Nós as pegamos, talvez até as observações do Chrome DevTools, e de alguma forma as misturamos?
Ivan: Na verdade, idealmente, se houver algo em um projeto que permita rastrear o RUM (métricas reais de usuário) - quão real o site está carregando para alguns usuários e se podemos lançá-lo para usuários reais e ver como funcionou para eles - é o caso perfeito.
Mas, em geral, sim, se eu usar algum tipo de ferramenta, eu realmente executo mais de um teste para obter o valor mediano, mas, em geral, o artigo traz o problema real de que existe algum tipo de percentil 99 de usuários que têm tudo muito é ruim e não sabemos se usamos apenas o Lighthouse, mas isso não diz que o Lighthouse é inútil, continua a funcionar e mostra a temperatura média no hospital. Se no geral melhorarmos o desempenho, o Lighthouse o mostrará.
Dmitry: Você tocou nas métricas reais do usuário. Acabei de trabalhar no Odnoklassniki e tivemos problemas em como rastrear isso, porque não está claro como fazê-lo e os volumes são grandes. Nós escrevemos nossos próprios e coletamos dos usuários, e foi apenas um tipo de caos. E se ainda é algum tipo de projeto médio, o que pode ser levado para medir no lado do usuário? Apenas window.performance ou algo mais recomendado? Ou usar algumas táticas complicadas, bombardear contas de usuários reais?
Ivan: Primeiro de tudo, provavelmente existem bibliotecas ou serviços prontos que permitem configurar o RUM. Por exemplo, adicione uma linha à página e ela começará a rastrear. Em segundo lugar, nos navegadores modernos, apareceu o PerformanceObserver - essa é uma API que mede todos os tipos de coisas nos navegadores e permite descobrir as métricas que o navegador normalmente contém, incluindo a primeira pintura com conteúdo , a primeira pintura significativa e tudo mais. E para descobrir essa métrica, apenas algumas linhas de código são suficientes, você não precisa escrever algo muito complicado. Assinei os eventos, recebi e repreendi.
Dmitry: E qual é a coisa mais importante para prestar atenção antes de tudo? First Paint , tempo para interativo , tempo para primeiro byte , outra coisa?
Ivan: Eu tenho apenas isso [há um relatório] ( https://www.youtube.com/watch?v=-H1l9XBXH6Q ) e digo que as coisas mais importantes a serem observadas são a primeira pintura significativa e o tempo de interação. E são tão importantes quanto mostram exatamente o que o usuário procurou pela primeira vez. Ele veio para ler ou ver algo, então esta é a primeira pintura significativa, ou para trabalhar com o aplicativo, então é hora de interagir. Se você estiver criando algum tipo de página de destino ou site de notícias, otimize a primeira pintura significativa e, se tiver um aplicativo complexo, otimize a primeira pintura significativa e o tempo para interagir.
Artyom: mencionamos os casos mais populares em sua prática. E quais casos são os mais raros ou mais interessantes, nos quais você teve que cavar as entranhas em algum lugar?
Ivan: Eu acho que tenho um caso bastante interessante agora. Atualmente, estou trabalhando com o Framer . Esses caras têm uma ferramenta de design elegante, um análogo de Figma e Sketch . E eu os ajudo a melhorar o desempenho em tempo de execução - essa geralmente é uma zona super interessante para mim. Eles usam o navegador super específico. Os navegadores não foram projetados originalmente para escrever aplicativos tão complexos, portanto o Figma e o Framer reimplementam muitas partes do navegador. E há muitos desenvolvimentos, que não estão em outros projetos e são super interessantes. Gosto de trabalhar com tudo isso. Isso é realmente algo interessante, algo novo e muito legal.
Dmitry: Falamos sobre as nuances básicas do navegador e, antes de passar para estruturas, eu gostaria de aprender sobre otimização de desempenho usando a arquitetura, algumas estruturas de dados. Você teve que alterar algo tão minucioso no aplicativo, por exemplo, adicionar uma lista de prefixos para a pesquisa ou outra coisa que não seja muito comum no frontend? Isso acontece?
Ivan: Eu praticamente não trabalhei no nível de estruturas de dados ou complexidade algorítmica, porque muitas coisas precisam ser feitas para que o aplicativo fique mais lento, e não outra coisa. Portanto, no que diz respeito a peças grandes, recomendo a todos ao criar um novo projeto ou se o projeto apenas começou e ainda é muito pequeno, faça-o em uma estrutura como o Next.js ou o Gatsby .
Essa e outra é uma estrutura para o React, construída para que você simplesmente escreva o aplicativo usando um par de abordagens dessa estrutura, e ela se tornou automaticamente rápida. E essas estruturas são muito populares, elas fazem seu trabalho perfeitamente, eu mesmo as uso em meus projetos de produção e recomendo a todos.
Artem: Aqui, recentemente, tivemos um incidente relacionado a como o V8 desoptimizou o React devido ao dispositivo Number dentro do V8. Você sentiu esse problema ou houve alguma pesquisa por que o aplicativo fica mais lento?
Ivan: Eu não senti e não li este artigo sobre desoptimização. Houve alguma operação específica ou desacelerou o React como um todo?
Artyom: Em geral, porque no React, existe um carimbo de data / hora no FiberNode, que foi inicialmente definido como 0 e extensão impedida (preventExtension) e, para isso, uma forma com um número inteiro pequeno foi alocada para otimizar operações em números. E quando o registro de data e hora preencheu o valor real, que ultrapassou 128, descobriu-se que era necessário alterar a estrutura de número inteiro pequeno para número de heap mutável e, desde que preventExtension foi chamado, formas completamente novas foram construídas para cada nó de fibra. E existem dezenas e centenas de milhares.
Ivan: eu não percebi isso, e dificilmente teria percebido, porque quando estou depurando, não tenho na memória um lembrete de que essa operação deva levar apenas 10 ms no React, e deve levar 20. Eu apenas debito, estou observando o rastreamento do desempenho Eu seleciono algum gargalo onde algo diminui a velocidade. Se o desempenho for distribuído, existem alguns atrasos na V8 e são distribuídos uniformemente por todo o aplicativo; se eu não for para depurações muito profundas, não notarei.
Se isso acontecer em uma operação V8 des otimizada e demorar muito, notarei e entrarei em uma depuração profunda.
Artyom: Havia realmente algum problema no React em si, ou em outras estruturas em que você precisava criar um problema, para chegar ao fundo de alguma coisa?
Ivan: Na minha opinião, relatei alguns erros, mas não me lembro dos detalhes ... não acho que isso seja relevante para esse problema, mas recentemente deparei-me com um caso interessante em que variáveis css se mostraram mais lentas do que alterar aplicativos pelo React prop. E para mim parece estranho, porque costumávamos dizer que o css é super rápido e, de repente, funciona muito mais devagar que o React.
Estou tentando adicionar um artigo sobre isso e, em geral, funciona assim porque não há otimização nos navegadores - se você alterar a variável css em um elemento que tem muitos filhos, o navegador, pelo menos o Chrome, não se lembra quais. as crianças usam essa variável e ela calcula todos os filhos e estilos para eles. Se houver muitos estilos e nós - é muito tempo e se você substituir alguma variável por React, talvez o cálculo dos estilos possa não ocorrer e tudo acontecerá rapidamente.
Tenho 80% de certeza de que isso é verdade, de acordo com o que entendi no código V8, mas posso estar errado. Mas isso pode ser registrado e reparado nos navegadores, mas isso não é um microbug; talvez haja muito trabalho. Ainda não relatei e não sei quanto tempo será gasto em consertá-lo, se eu consertar.
Artyom: Você teve que assistir o código de código resultante? Com as mesmas visualizações de desoptimização, você assiste o bytecode da V8 e há alguma operação extra inserida?
Ivan: Não, provavelmente nunca procurei por código de código, mas aprendi muito bem a ler JavaScript minificado. (risos)
Dmitry: E para a resposta anterior - você de alguma forma se comunica com os desenvolvedores de navegadores para esclarecer essas coisas? E se sim, como eles respondem? E eles respondem?
: GDE (Google Developer Expert), Google- Slack-, Google-, Chrome. - , . , . . .
: ! .
: , Google, GDE ().
: :)
: , , , .
: , Moment.js. , , Day.js -, bundlephobia . , , , Angular, .
, , , , , , , , . ? , issue , ? , ?
: … . - , , . - , , userspace- .
, .
, , , - . webpack - . React, , API Preact , Inferno .
: ? , , , , Vue.js, , , . -?
: , . , , Angular, Angular. Angular, , . … , , . - Ext JS .
, . , . , .
WebAssembly
: , - JS, , high computation . WebAssembly, computational ?
: , WebAssembly - , .
: , , WASM. Figma, Blazor, C# WebAssembly, - . ?
: , - WebAssembly . , c WebAssembly , . .
: ?
: , . -, JavaScript - , WebAssembly , , 10 .
, , JavaScript, C++ Rust — WebAssembly . , , .
: . scroll, , . - - ? , Chrome iOS - ChromeOS - , - ? , , «.»?
: , performance IE11. , - , , IE11. , . IE11.
. «.» Chrome iOS , «.» Chromium, Chrome iOS — WebKit, iOS
: , … ()
HTTP/3
: , , . . HTTP/2, HTTP/3, QUIC . , : HTTP/2 , ?
, HTTP/3 ?
: HTTP/3 ?
: , Chrome , cURL, .
: , . , , , , HTTP/3 . Google , HTTP/3, , HTTP/3.
, , HTTP/2 , , , 2-3 , , HTTP/2 . HTTP/3 . , - , .
: , , ? , , - ?
: -, Twitter, (, []( https://twitter.com/slightlylate ), []( https://twitter.com/zachleat ), []( https://twitter.com/csswizardry ), []( https://twitter.com/igrigorik ), []( https://twitter.com/philwalton )). - Google GDE , - - performance-. .
, Calibre ( performance-) Perf.email , performance-.
: GDE! , - , . , , , ? , .
: , Service License Agreement , 95% . , performance . Juliarderity , , , . , .
: « », , . ? React, Angular .. — framework-specific , , ? TC39?
: (). , — , — .
: ?
: - . proposal, , . proposal, - . — .
: , RSS? - .
: RSS.
: , Habr, « Chrome», RSS . RSS , .
: , -, , , DevTool-, , - , , , .
: , ?
: Twitter, , -, Twitter, 20-30 . , « @vkozula ?».
, « , ». - . . , . , . Facebook- , - 50 , , .
: jsunderhood - ?
: underhood. - , . underhood, — jsunderhood 2017 , , , , , , .
: , , HolyJS jsunderhood, .. . ? , ?
: , , . , , , … , , . 10—20 .
: , ?
: , , , , , , , , . , , , Twitter , , . - Twitter Telegram , , .
: , . , . , , ?
Ivan: Eu não tinha tantos workshops em quantidade absoluta, mas o que mais me orgulha é o meu workshop sobre webpack , que fiz como introdução ao webpack no final de 2017. Infelizmente, ele já está desatualizado, mas ficou legal, porque eu planejava realizar uma transmissão on-line, mas naquele dia comecei a ficar muito atrasado na Internet.
Comecei a liderar, depois de 10 minutos caí, reconectei, caí novamente e tive que cancelar urgentemente tudo, pedir desculpas e dizer que gravaria todo o material em vídeo e colocaria tudo assim. Fiz tudo isso, esquematizei , resultou em uma série de vídeos como no egghead.io , e com a exceção do problema de que havia um som muito silencioso, porque não havia microfone normal. Ouvi muitas críticas, o que foi muito bom e realmente ajudou as pessoas.
Dmitry: O que você acha, por que vale a pena ir para as oficinas? Por exemplo, se você foi a uma oficina em um navegador, ouço muitas vezes que as pessoas querem ver como o V8 é destruído ou algo mais. E no Ocidente, pelo contrário, se você se lembra da entrevista interessante de Michel Weststrate, ele disse: “Eu vou aprender com eles. Se eu não conheço o Docker, vou para lá e obtenho informações rapidamente. ” Como você vê as oficinas e em quais casos você recomenda participar das oficinas? Aprender, aprofundar o conhecimento, ver coragem?
Ivan: Eu diria isso - se a descrição lhe parecer interessante, então venha. Quando faço workshops, sempre tento dar algum tipo de base para que as pessoas que o acompanham pela primeira vez não se percam. Eu posso imaginar que alguns dos caras que trabalham em super avançado vieram ouvir, talvez o começo seja chato. Eles podem não permanecer até o fim, onde um tópico avançado pode ser levantado. Por outro lado, não posso prometer que mostrarei algumas entranhas, porque todas as pessoas têm um entendimento diferente de "entranhas". Eu irei mostrar alguns casos super raros que encontrei em minha experiência e outra pessoa pode esperar que eu estrear o V8 ou compilar o Chromium, mas não o farei.
Dmitry: E o que você, em princípio, normalmente espera de uma oficina?
Ivan: Lembro que só participei de algumas oficinas na minha vida. Nas duas vezes, foi um novo tópico para mim, que eu ainda não consegui descobrir. E as oficinas foram um tipo de introdução para mim e foram super úteis.
No meu workshop, não farei uma introdução ao desempenho e, no React, espero que as pessoas que vierem ouçam algo sobre isso, mas tentem abordar alguns tópicos básicos e mostrar algumas depurações avançadas, tanto quanto Eu o conheço e me deparei com ele.
Dmitry: O que você espera do HolyJS como um todo? Talvez tenha notado alguns relatos ou palestrantes com quem gostaria de conversar?
Ivan: eu não planejo nada para mim com mais de um mês de antecedência, então ainda não planejei nada. Existe preparação e o resto vai acontecer. (risos)
Dmitry: Isso é tudo. Muito obrigado pela entrevista. Estamos aguardando todos na sua oficina .