Ivan Akulov es un experto desarrollador de Google en tecnologías web y el fundador de la empresa de rendimiento PerfPerfPerf . Muy pronto, en HolyJS 2019 Moscú, realizará un taller dedicado, por extraño que parezca, al rendimiento: encontrar problemas en React, depurar aplicaciones lentas y otras cosas en tiempo de ejecución.
Para sumergir más a los lectores y visitantes de HolyJS 2019 Moscú en el tema, discutimos con Ivan:
- Los problemas de rendimiento más populares;
- Cómo medir el rendimiento y cuál puede ser el problema;
- Cómo optimizar el rendimiento;
- Buscar problemas de rendimiento en React;
- Los beneficios de cambiar a HTTP / 2 y HTTP / 3;
- Es mejor usar un marco compacto en nuevos proyectos;
- Sobre los beneficios de WebAssembly;
- Dónde buscar información útil sobre el desempeño;
- De qué se tratará su taller y quién estará interesado en asistir (y por qué ir a los talleres).
Dmitry Makhnev y Artyom Kobzar del comité del programa HolyJS hacen preguntas.
Dmitry: Cuéntame algunas palabras sobre ti.
Ivan: Soy Ivan Akulov, consultor de rendimiento, experto en desarrolladores de Google, que hace mi agencia de consultoría de rendimiento.
Dmitry: Dices que una agencia de consultoría no es el trabajo principal. Pero básicamente, ¿qué estás haciendo?
Ivan: Mi tiempo ahora se distribuye aproximadamente, de modo que estoy medio cargado de trabajo con un antiguo cliente. Trabajo con una empresa brasileña, juntos creamos una plataforma de marketing de contenido de Wordpress, administro la infraestructura allí y un poco de desarrollo de productos, y algún tipo de visión común.
El resto del tiempo lo dedico a consultoría, discursos, artículos y todo eso.
Dmitry: ¿Hay muchos recursos para la consultoría de desempeño? ¿Cómo funciona?
Ivan: En general, depende mucho del mes o algo así ...
Dmitry: ¿ Cuándo anuncian los astrólogos el mes de la actuación? :)
Ivan: ¡ Más bien, cuando los contadores anuncian un nuevo trimestre! (risas) No estoy buscando activamente clientes en este momento, la razón principal es que no hay tiempo para esto ahora, porque ya estoy cargado con lo que tengo. Pero en general, todo parece que escribo algunos artículos, hago algunos discursos y, cuando trabajo con algunos clientes, me recuerdan y me recomiendan nuevos. La mayoría de las personas vienen gracias a la red, y vienen tipos muy geniales.
Artyom: ¿Cómo llegaste al tema del rendimiento antes de crear tu propia firma de consultoría?
Ivan: En realidad, todo comenzó con el hecho de que una vez reescribimos un proyecto antiguo en Epam durante medio año en wepback. Hubo un proyecto antiguo con un montón de legado, con su propio marco front-end, la mitad de los cuales funcionaba en la pila de Java. Y como pasamos medio año haciendo webpack relativamente rápido, obtuve experiencia con webpack. Y en ese momento podría escribir una configuración webpack de complejidad media, líneas de 20 a 40, literalmente desde la memoria, sin buscar en Google nada, sin espiar e incluso sin usar IntelliSense.
Y me di cuenta de que tal experiencia podría ser útil para otra persona, decidí intentar comenzar algún tipo de consultoría en el campo de webpack. Hice un aterrizaje para mí, lo publiqué en algún lugar, vinieron un par de personas, trabajé con uno de ellos. Y de alguna manera todo comenzó.
Y más tarde, fluí sin problemas del rendimiento relacionado con el paquete web a la consultoría de rendimiento en general.
Artyom: ¿Lograste mejorar el rendimiento del ensamblaje en ese proyecto?
Ivan: Ese proyecto no funcionó perfectamente, no de la forma en que me gustaría llegar al final. Fue tal cosa que los muchachos llegaron en un momento en que realmente necesitaba dinero y todavía no entendía cómo negociar, cuidarme y tener en cuenta mis intereses en estas negociaciones. Sugerí un pequeño precio fijo con una cantidad de trabajo no segura, trabajamos, los ayudé, tomé una decisión que parecía funcionar y arreglé el rendimiento.
Luego resultó que había errores en esta solución, resultó ser demasiado complicado y aparecieron errores extraños en casos excepcionales. Comenzamos a arreglarlo, arreglé un error segundo, tercero, todo esto duró un mes. Y al final, en algún momento, los errores dejaron de suceder, pero los chicos decidieron pedirme algo más, pero como tengo un presupuesto interno para esto, todo terminó, solo dije: "Lo siento, ya estoy cargado, y no Yo puedo ayudar ".
Como resultado, hasta donde supe, en un par de meses reemplazaron esta solución por otra menos complicada y funcionaron en 100% de los casos.
Para ser honesto, no me conozco ... Parece que vine y ayudé, y la decisión final que tomaron nació en nuestras conversaciones anteriores, pero no sé cuánto ayudaron a lo que hice. Y cuán satisfechos estaban con todo esto. En resumen, no fue tan perfecto como me gustaría.
Artyom: Y hablando de hoy, ¿de alguna manera haces un seguimiento de los clientes anteriores, cómo están allí? ¿Te ayudó todo?
Ivan: Sí, definitivamente. Poco a poco desarrollé algunos enfoques. En primer lugar, al final de mi trabajo trato de obtener algunos comentarios públicos de cada cliente, que pueden publicarse en el sitio o en algún lugar.
En segundo lugar, desarrollé un enfoque para preguntar a los clientes en el proceso o al final de un trabajo la pregunta "¿Cómo está satisfecho con el proceso actual, el flujo de trabajo actual, algo actual?" con las opciones de respuesta "más que satisfecho", "satisfecho", "casi satisfecho", "no realmente satisfecho".
Y me gusta esta pregunta, porque da respuestas específicas, y no una escala tonta del 1 al 5, que todos perciben a su manera. Hasta ahora, ninguno de los clientes ha respondido "casi satisfecho" o "no realmente satisfecho". Estaba satisfecho, feliz y algo así.
Artyom: ¿Entiendo correctamente que su área de experiencia en rendimiento está dirigida principalmente al lado del cliente? ¿O tiene toda la pila web en su conjunto afectada por las consultas?
Ivan: Sí, el área de especialización está dirigida principalmente a la pila de clientes, con la optimización del rendimiento en el backend o en las bases de datos, trabajé mucho menos. Pero en la práctica, si una aplicación web se ralentiza, incluso algún artículo o estudio es, ese 80-90% de los casos, se ralentiza precisamente debido al front-end.
Si entra un cliente y algo se ralentiza, en la mayoría de los casos mi experiencia es la correcta.
Sobre los temas más populares
Artyom: ¿Y qué sucede cuando hay algunos casos extremos? Cuando tenemos un problema no con el análisis de JavaScript y su lanzamiento, sino con el transporte. Cuando se asigna la primera interacción al cliente, así como al backend. Es cursi que gzip se haya configurado incorrectamente; gira demasiado tiempo. ¿Qué haces en estos casos? Y si su análisis está principalmente en primera línea, ¿cómo encuentra estos casos?
Ivan: Bueno, esto generalmente significa que el tiempo de respuesta del servidor es demasiado largo. Si noto esto durante algún tipo de auditoría, miro en devtools, busco en la red y veo que el tiempo desde el servidor es de 800 ms; para volverse loco, lleva demasiado tiempo. Y voy, tratando de entender cómo los chicos tienen un servidor, qué hacen durante cada respuesta. Si se trata de JavaScript o PHP, lo más probable es que pueda resolverlo bien y arreglarlo todo, si algún otro idioma con el que no trabaje podría necesitar su ayuda.
Dmitry: ¿Puedes nombrar alguno de los 5 problemas de rendimiento más comunes encontrados en la práctica?
Ivan: Seguiré el camino que recuerdo. Uno de los problemas comunes que se produce no en aplicaciones web complejas, sino en sitios simples, es cuando un desarrollador o cliente coloca una gran cantidad de scripts dentro de la etiqueta principal sin los atributos asíncronos o diferidos , y esto es malo porque el navegador no puede comenzar a mostrar la página hasta no cargará y ejecutará estos scripts.
Y si hay un servidor lento o un script grande que lleva mucho tiempo ejecutar, la persona que usa el sitio no verá la página hasta el final de la ejecución.
Otro problema común son los scripts de terceros. Actualmente estoy trabajando con un cliente a quien estoy ayudando a mejorar su puntaje de faro . Inicialmente, el puntaje del faro que tenían era de aproximadamente 35-40. Vine, hice todo tipo de cosas diferentes, eliminé JavaScript innecesario, recursos de bloqueo de renderizado, optimicé de alguna manera ... Después de todo lo que hice, la puntuación solo creció en algún lugar a 55. Y resultó que si va con esta página optimizada y comenta un solo componente React que carga todos los análisis, la puntuación del faro salta en algún lugar hasta 88-90 + puntos. Esto sucede porque hay muchos JS que eliminan las métricas.
En algunas aplicaciones web complejas, un tema frecuente es cuando los desarrolladores instalan algún tipo de biblioteca grande y se agrupa en el paquete por completo, aunque no se usa por completo. A menudo, este es Moment.js , en el que hay archivos de localización enormes, 165 KB de archivos de localización minificados que casi nadie necesita, o lodash , en los que hay muchos métodos, y todos usan solo 10-20.
Con el rendimiento de representación, solía haber un problema frecuente cuando los desarrolladores colgaban algún tipo de controlador de eventos, por ejemplo, en un desplazamiento de eventos, tomaba entre 5 y 10 ms, y cada vez que intentaba desplazarse por algo, la página entera se demoraba. Ahora esto se ha vuelto menos, porque en el mismo Chrome [oyentes de eventos pasivos agregados] ( https://stackoverflow.com/questions/37721782/what-are-passive-event-listeners ).
Sobre cómo medir el rendimiento
Dmitry: En el curso de los casos, surgió una pregunta sobre Lighthouse. En mi opinión, los tres estaban en BeerJS Summit , y hubo un informe genial - (centésimo) de Alexey Kalmakov . No hay entrada , pero vi un artículo similar sobre Habré , y esas cosas comprometen un poco a Lighthouse. Si lo toma simplemente como una herramienta para evaluar el trabajo de un ingeniero de rendimiento, puede hacer algunos trucos allí.
¿Tiene alguna herramienta, tal vez incluso auto-escrita, con la que evalúe claramente si tuvo éxito o no? Por ejemplo, firma un contrato y le dicen que necesita hacer un rendimiento x2. ¿Qué conjunto de herramientas usarás para esto?
Ivan: Bueno, en primer lugar, si concluimos un contrato y acordamos x2, entonces acordaremos algún tipo de instrumento. Pero en general, además de Lighthouse, realmente me gusta WebPageTest . Esta es una herramienta avanzada de rendimiento web muy buena que le permite probar su aplicación desde una ubicación arbitraria real, por ejemplo, Brasil o Australia, en un dispositivo real, por ejemplo, muy débil, como Moto G.
Esto es más genial que Lighthouse, porque emula todo esto, y solo después de las pruebas en un dispositivo real sabes que el sitio se está procesando durante 15 segundos. El segundo beneficio: proporciona un montón de métricas súper detalladas de todo tipo de gráficos, como la carga. Lo uso regularmente para ver algunas cosas.
Dmitry: ¿Has escrito alguna de tus herramientas, por ejemplo, sobre el protocolo Chrome DevTools ? ¿Qué te falta en las herramientas?
Ivan: Escribí mi instrumento encima del faro. Para trabajar con uno de los clientes, necesitaba una configuración que me permitiera medir el rendimiento de una página con el Faro en un entorno bastante estable, considerarlo como el puntaje del faro y copiarlo en la tabla. Hay un problema con él: el Faro en PageSpeed Insights no es muy estable. Si mide la misma página tres veces, puede obtener tres medidas diferentes. Además, necesitaba medir no las páginas que estaban listas y publicadas en la red, sino la página local. Y la única opción es ejecutar Lighthouse localmente, lo que también afecta en gran medida la puntuación del faro, porque el puntaje comienza a depender de lo que funcione en su computadora portátil. Por ejemplo, lanzó Docker, el puntaje cayó 2 veces.
Para este caso, necesitaba medir Lighthouse de manera predecible. Escribí un guión que ejecutó Lighthouse tres veces, una puntuación, tomó el valor medio de las tres veces y lo hice por muchas páginas con muchas configuraciones. Alquilé un servidor DigitalOcean para esto y ejecuté todo lo que estaba allí para que estuviera lo más aislado posible de factores externos.
Artyom: Mencionaste un caso interesante sobre diferentes métricas de Lighthouse. Hubo un artículo reciente, Una introducción al percentil 99 para programadores , en el que concluyeron que las herramientas modernas de evaluación comparativa y, en principio, la micro evaluación comparativa por sí sola no prueban nada.
Con las herramientas modernas puede resultar que hice un punto de referencia, usted escribió, escribió Dima, y todos dirán cosas completamente diferentes. Y ahora, en un mundo sin un conocimiento más o menos profundo en teoría y estadística, la evaluación comparativa no parece muy plausible. Usted mencionó a Lighthouse, pero ¿hay alguna evidencia que recibió en el punto de referencia, alguna confirmación adicional?
Dmitry: ¿ Quizás mezclar Lighthouse con algo? Usted mencionó WebPageTest. Los tomamos, tal vez incluso observaciones de Chrome DevTools, y de alguna manera los mezclamos.
Ivan: En realidad, idealmente, si hay algo en un proyecto que le permita rastrear RUM (métricas de usuarios reales): cuán real se está cargando el sitio para algunos usuarios, y si podemos implementarlo para usuarios reales y ver cómo funcionó para ellos, es el caso perfecto.
Pero, en general, sí, si uso algún tipo de herramienta, realmente ejecuto más de una prueba para obtener el valor medio, pero en general, el artículo plantea el problema real de que hay algún tipo de percentil 99 de usuarios que tienen todo muy es malo y no sabemos si solo usamos Lighthouse, pero esto no dice que Lighthouse sea inútil, continúa funcionando y muestra la temperatura promedio en el hospital. Si en general hemos mejorado el rendimiento, Lighthouse lo mostrará.
Dmitry: Tocaste las métricas de usuarios reales. Acabo de trabajar en Odnoklassniki y tuvimos problemas con cómo rastrear esto, porque no está claro cómo hacerlo, y los volúmenes son grandes. Escribimos los nuestros y los recopilamos de los usuarios, y fue solo una especie de caos. Y si todavía es algún tipo de proyecto promedio, ¿qué se puede tomar para medir en el lado del usuario? ¿Solo window.performance o algo más recomendado? ¿O utiliza algunas tácticas engañosas, bombardeos en cuentas de usuarios reales?
Ivan: En primer lugar, probablemente hay bibliotecas o servicios listos para usar que le permiten configurar RUM. Por ejemplo, agregue una línea a la página y comenzará a seguir. En segundo lugar, en los navegadores modernos, ha aparecido algo como PerformanceObserver : esta es una API que mide todo tipo de cosas en los navegadores y le permite descubrir las métricas que el navegador generalmente contiene, incluida la primera pintura con contenido , la primera pintura significativa y todo eso. Y para descubrir esta métrica, solo unas pocas líneas de código son suficientes, no necesita escribir algo demasiado complicado. Me suscribí a los eventos, los recibí y los reprendí.
Dmitry: ¿Y qué es lo más importante a lo que prestar atención en primer lugar? First Paint , tiempo para interactuar , tiempo para el primer byte , ¿algo más?
Ivan: Tengo justo al respecto [hay un informe] ( https://www.youtube.com/watch?v=-H1l9XBXH6Q ) y te digo que las cosas más importantes a tener en cuenta son la primera pintura significativa y el tiempo para interactuar. Y son tan importantes como muestran exactamente para qué vino el usuario por primera vez. Vino para leer o ver algo, luego esta es la primera pintura significativa, o para trabajar con la aplicación, entonces es hora de interactuar. Si está creando algún tipo de página de destino o sitio de noticias, optimice la primera pintura significativa y, si tiene una aplicación compleja, optimice la primera pintura significativa y el tiempo para interactuar.
Artyom: Mencionamos los casos más populares en su práctica. ¿Y qué casos son los más raros o más interesantes, en los que tuvo que profundizar en alguna parte?
Ivan: Creo que tengo un caso bastante interesante ahora. Actualmente estoy trabajando con Framer . Estos chicos tienen una herramienta de diseño de moda, un análogo de Figma y Sketch . Y les ayudo a mejorar el rendimiento en tiempo de ejecución; en general, esta es una zona súper interesante para mí. Usan el navegador súper específico. Los navegadores no fueron diseñados originalmente para escribir aplicaciones tan complejas, por lo que tanto Figma como Framer vuelven a implementar muchas piezas del navegador. Y hay muchos de sus desarrollos, que no están en otros proyectos, y que son súper interesantes. Disfruto trabajando con todo esto. Esto es realmente algo interesante, algo nuevo y muy genial.
Dmitry: Hablamos sobre los matices básicos del navegador, y antes de pasar a los frameworks, me gustaría aprender sobre la optimización del rendimiento utilizando la arquitectura, algunas estructuras de datos. ¿Tuviste que cambiar algo tan completo en la aplicación, por ejemplo, agregar una lista de prefijos para la búsqueda o algo más que no es muy habitual para la interfaz? ¿Esto pasa?
Ivan: Prácticamente no trabajé a nivel de estructuras de datos o complejidad algorítmica, porque hay que hacer muchas cosas para que la aplicación se ralentice en esto, y no otra cosa. Entonces, con respecto a las piezas grandes, recomiendo a todos cuando creen un nuevo proyecto o si el proyecto acaba de comenzar y aún es bastante pequeño, hágalo en un marco como Next.js o Gatsby .
Tanto eso como otro es un marco para React que está construido de manera que simplemente escribiste la aplicación usando un par de enfoques de este marco, y automáticamente se volvió rápido. Y estos son marcos muy populares, hacen su trabajo perfectamente, yo mismo los uso en mis proyectos de producción y lo recomiendo a todos.
Artem: Justo aquí, recientemente tuvimos un incidente relacionado con la reacción del V8 desoptimizado debido al dispositivo Number dentro del V8. ¿Sintió este problema o hubo alguna búsqueda por la que la aplicación se ralentiza?
Ivan: No sentí y no leí este artículo sobre desoptimización. ¿Hubo alguna operación específica o ralentizó todo el React en su conjunto?
Artyom: En general, porque en React, hay una marca de tiempo dentro de FiberNode, y se configuró inicialmente en 0 e impidió la extensión (preventExtension), y para esto, se asignó una forma con un número entero pequeño para optimizar las operaciones en los números. Y cuando la marca de tiempo se llenó con un valor real, que superó los 128, resultó que era necesario cambiar la estructura de un número entero pequeño a un número de montón mutable, y como se llamó a preventExtension, se construyeron formas completamente nuevas para cada nodo de fibra. Y hay decenas y cientos de miles.
Ivan: No me he dado cuenta de esto, y apenas me habría dado cuenta, porque cuando depuro, no tengo uno en mi memoria de que esta operación debería tomar solo 10 ms en React, y toma 20. Solo depuro, miro el seguimiento del rendimiento, Selecciono un cuello de botella donde algo se ralentiza. Si se distribuye el rendimiento, hay algunos retrasos en V8 y se distribuyen de manera uniforme en toda la aplicación, entonces si no voy a depurar muy profundamente, entonces no lo notaré.
Si esto sucede en una operación V8 des-optimizada y lleva mucho tiempo, lo notaré y realizaré una depuración profunda.
Artyom: ¿Realmente hubo algún problema de React en sí mismo, o de otros marcos en los que tuviste que crear un problema, para llegar al fondo de algo?
Ivan: En mi opinión, informé un par de errores, pero no recuerdo los detalles ... No creo que esto sea relevante para este problema, pero recientemente encontré un caso interesante cuando las variables css resultaron ser más lentas que el cambio de aplicaciones por React prop. Y para mí se siente extraño, porque solíamos decir que css es superrápido, y de repente funciona mucho más lento que React.
Estoy tratando de agregar un artículo sobre esto, y en general funciona así porque no hay optimización en los navegadores: si cambia la variable css en un elemento que tiene muchos hijos, entonces el navegador, al menos Chrome, no recuerda cuáles. los niños usan esta variable y va y calcula todos los niños y estilos para ellos. Si hay muchos estilos y nodos, es mucho tiempo y si reemplaza alguna variable con React, entonces tal vez el cálculo de los estilos no suceda y todo sucederá rápidamente.
Estoy 80% seguro de que esto es así de acuerdo con lo que entendí del código V8, pero puedo estar equivocado. Pero esto es algo que podría registrarse y repararse en los navegadores, pero esto no es un microbug, quizás haya mucho trabajo. Todavía no lo he informado y no sé cuánto tiempo pasaré reparándolo si lo soluciono.
Artyom: ¿ Tuviste que ver el bytecode resultante? Con las mismas vistas de desoptimización, observa el bytecode V8 y ¿hay alguna operación adicional que se inserte?
Ivan: No, probablemente nunca haya investigado el código de bytes, pero aprendí bastante bien a leer JavaScript minificado. (risas)
Dmitry: Y a la respuesta anterior, ¿de alguna manera te comunicas con los desarrolladores del navegador para aclarar tales cosas? Y si es así, ¿cómo responden? ¿Y responden ellos?
: 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: No tuve tantos talleres en cantidad absoluta, pero de lo que estoy más orgulloso es de mi taller webpack , que hice como introducción a webpack a finales de 2017. Desafortunadamente, ya está desactualizado, pero resultó genial, porque planeaba realizar una transmisión en línea, pero ese día comencé a retrasar mucho Internet.
Comencé a liderar, después de 10 minutos me caí, me reconecté, me caí nuevamente y tuve que cancelarlo urgentemente, disculparme y decir que grabaría todo el material en video y lo pondría todo así. Lo hice todo, presentado, resultó una serie de videos como en egghead.io , y con la excepción del problema de que había un sonido muy silencioso, porque no había un micrófono normal. Escuché muchas críticas, lo cual fue muy bueno y realmente ayudó a la gente.
Dmitry: ¿Qué piensas, por qué vale la pena ir a talleres? Por ejemplo, si fue a un taller en un navegador, a menudo escucho que la gente quiere ver cómo se destripa el V8 o algo más. Y en Occidente, por el contrario, si recuerdas la genial entrevista de Michel Weststrate, dijo: “Voy a aprender de ellos. Si no conozco a Docker en absoluto, entonces voy allí y obtengo información rápidamente ". ¿Cómo ve los talleres y en qué casos recomienda asistir a sus talleres? ¿Aprender, profundizar el conocimiento, ver las agallas?
Ivan: Diría esto: si la descripción te pareció interesante, entonces ven. Cuando hago talleres, siempre trato de dar algún tipo de base para que las personas que vienen a trabajar con él por primera vez no se pierdan. Me imagino que algunos de los chicos que trabajan en super avanzado vinieron a escuchar, tal vez el comienzo es aburrido. Es posible que no permanezcan hasta el final donde se puede plantear un tema avanzado. Por otro lado, no puedo prometer que mostraré algunas agallas, porque todas las personas tienen una comprensión diferente de las "agallas". Vendré y mostraré algunos casos súper raros que he encontrado en mi experiencia, y alguien más puede venir y esperar que debute el V8 o compile Chromium, pero no lo haré.
Dmitry: ¿Y qué espera usted, en principio, de un taller?
Ivan: Recuerdo que solo fui a un par de talleres en mi vida. En ambas ocasiones, era un tema nuevo para mí, que aún no podía resolver por mí mismo. Y los talleres fueron una especie de introducción para mí, y fue muy útil.
En mi taller no haré una introducción al rendimiento y en React, espero que la gente que venga escuche algo al respecto, pero trate de cubrir algunos temas básicos y muestre alguna depuración avanzada tanto como Lo conozco y me encontré con él.
Dmitry: ¿Qué esperas de HolyJS en su conjunto? ¿Tal vez noté algunos informes o oradores con los que me gustaría hablar?
Ivan: No planeo nada para mí con más de un mes de anticipación, por lo que aún no he planeado nada. Hay preparación, y el resto sucederá. (risas)
Dmitry: Eso es todo. Muchas gracias por la entrevista. Estamos esperando a todos en su taller .