Ivan Akulov est un développeur Google Expert en technologies Web et le fondateur de la société de performance PerfPerfPerf . Très bientôt, à HolyJS 2019 Moscou, il organisera un atelier dédié, curieusement, aux performances - trouver des problèmes dans React, déboguer des applications lentes et d'autres choses d'exécution.
Pour plonger davantage les lecteurs et les visiteurs de HolyJS 2019 Moscou dans le sujet, nous avons discuté avec Ivan:
- Les problèmes de performances les plus courants;
- Comment mesurer les performances et quel peut être le problème;
- Comment optimiser les performances;
- Rechercher des problèmes de performances dans React;
- Les avantages de passer Ă HTTP / 2 et HTTP / 3;
- Il est préférable d'utiliser un cadre compact sur de nouveaux projets;
- À propos des avantages de WebAssembly;
- OĂą chercher des informations utiles sur les performances;
- De quoi parlera son atelier et qui sera intéressé à y participer (et pourquoi aller aux ateliers).
Les questions sont posées par Dmitry Makhnev et Artyom Kobzar du comité du programme HolyJS.
Dmitry: Parlez-moi de vous.
Ivan: Je suis Ivan Akulov, consultant en performances, Google Developer Expert, qui travaille pour mon agence de conseil en performances.
Dmitry: Vous dites qu'une agence de conseil n'est pas la tâche principale. Mais qu'est-ce que tu fais?
Ivan: Mon temps est maintenant réparti approximativement de sorte que je suis à moitié chargé de travail avec un ancien client. Je travaille avec une entreprise brésilienne, ensemble nous créons une plateforme de marketing de contenu Wordpress, j'y gère l'infrastructure et un peu de développement de produits, et une sorte de vision commune.
Le reste du temps je me consacre à la consultation, aux discours, aux articles et tout ça.
Dmitry: Y a-t-il beaucoup d'appels pour le conseil en performance? Comment ça marche même?
Ivan: En général, cela dépend beaucoup du mois ou quelque chose comme ça ...
Dmitry: Quand les astrologues annoncent-ils le mois de la performance? :)
Ivan: Au contraire, lorsque les comptables annoncent un nouveau trimestre! (rires). Je ne recherche pas activement de clients en ce moment, la principale raison est que nous n'avons pas le temps pour cela maintenant, car je suis déjà chargé de ce que j'ai. Mais en général, tout se passe comme si j'écrivais des articles, prononçais des discours et lorsque je travaillais avec certains clients, ils se souvenaient de moi et m'en recommandaient de nouveaux. La plupart du temps, les gens viennent grâce au réseau et des mecs plutôt cool viennent.
Artyom: Comment en êtes-vous arrivé au thème de la performance avant de créer votre propre cabinet de conseil?
Ivan: En fait, tout a commencé avec le fait que nous avons réécrit une fois un vieux projet dans Epam pendant six mois sur wepback. Il y avait un vieux projet avec un tas d'héritage, avec son propre framework frontal, dont la moitié fonctionnait dans la pile java. Et comme nous avons passé six mois à fabriquer des webpack relativement rapidement, j'ai acquis de l'expérience avec webpack. Et à ce moment-là , je pouvais écrire une configuration Webpack de complexité moyenne, des lignes de 20 à 40, littéralement de la mémoire, sans rien googler, sans regarder et même sans utiliser IntelliSense.
Et j'ai réalisé qu'une telle expérience pouvait être utile à quelqu'un d'autre, j'ai décidé d'essayer de démarrer une sorte de conseil dans le domaine du webpack. Je me suis fait un atterrissage, je l'ai posté quelque part, quelques personnes sont venues, j'ai travaillé avec l'une d'elles. Et en quelque sorte, tout a commencé.
Et plus tard, je suis passé en douceur des performances liées au webpack au conseil en performance en général.
Artyom: Avez-vous réussi à améliorer les performances d'assemblage de ce projet?
Ivan: Ce projet n’a pas fonctionné parfaitement, pas comme je le souhaiterais finalement. C'était une telle chose que les gars sont venus à un moment où j'avais vraiment besoin d'argent et je ne comprenais toujours pas comment négocier, prendre soin de moi et tenir compte de mes intérêts dans ces négociations. J'ai suggéré un petit prix fixe avec une quantité de travail non garantie, nous avons travaillé, je les ai aidés, pris une décision qui semblait fonctionner et fixé la performance.
Ensuite, il s'est avéré qu'il y avait des bogues dans cette solution, il s'est avéré être trop compliqué et des bogues étranges sont apparus dans de rares cas. Nous avons commencé à le réparer, j'ai corrigé un, deuxième, troisième bug, tout cela a duré un mois. Et à la fin, à un moment donné, les bugs ont cessé de se produire, mais les gars ont décidé de me demander autre chose, mais comme j'ai un budget interne pour cela, c'est complètement terminé, je viens de dire: "Désolé, je suis déjà chargé, et pas Je peux aider. "
En conséquence, pour autant que je le sache, en quelques mois, ils ont remplacé cette solution par une autre solution moins compliquée et ont fonctionné à 100%.
Pour être honnête, je ne me connais pas ... Il semble que je sois venu aider et la décision finale qu'ils ont prise est née dans nos conversations précédentes, mais je ne sais pas combien ils ont aidé ce que j'ai fait. Et comme ils étaient satisfaits de tout cela. Bref, ce n'était pas aussi parfait que je le souhaiterais.
Artyom: Et en parlant d'aujourd'hui, suivez-vous en quelque sorte les anciens clients, comment vont-ils là -bas, tout cela a-t-il aidé?
Ivan: Oui, certainement. J'ai progressivement développé quelques approches. Premièrement, à la fin de mon travail, j'essaie d'obtenir des commentaires du public de chaque client, qui peuvent être publiés sur le site ou publiés quelque part.
Deuxièmement, j'ai développé une approche pour poser aux clients au cours ou à la fin d'un travail la question «Comment êtes-vous satisfait du processus actuel, du flux de travail actuel, de quelque chose d'actuel?» avec les options de réponse «plus que satisfait», «satisfait», «presque satisfait», «pas vraiment satisfait».
Et j'aime cette question, car elle donne des réponses spécifiques, et non une échelle stupide de 1 à 5, que tout le monde perçoit à sa manière. Jusqu'à présent, aucun des clients n'a répondu «presque satisfait» ou «pas vraiment satisfait». C'était Satisfait, Heureux et quelque chose comme ça.
Artyom: Ai -je bien compris que votre domaine d'expertise en performance s'adresse principalement au client? Ou avez-vous l'ensemble de la pile Web dans son ensemble touché par les consultations?
Ivan: Oui, le domaine d'expertise est principalement destiné à la pile client, avec l'optimisation des performances dans le backend ou dans les bases de données, j'ai beaucoup moins travaillé. Mais dans la pratique, si une application Web ralentit, même un article ou une étude, 80 à 90% des cas - elle ralentit précisément en raison du front-end.
Si un client arrive et que quelque chose ralentit, dans la plupart des cas, mon expertise est parfaite.
À propos des problèmes les plus courants
Artyom: Et que se passe-t-il quand il y a des cas marginaux? Quand nous avons un problème non pas avec l'analyse de JavaScript et son lancement, mais des problèmes de transport. Lorsque la première interaction est affectée au client, ainsi qu'au backend. Il est ringard que gzip soit mal configuré, il tourne trop longtemps. Que faites-vous dans ces cas? Et si votre analyse est principalement en première ligne, comment trouvez-vous de tels cas?
Ivan: Eh bien, cela signifie généralement que le temps de réponse du serveur devient trop long. Si je remarque cela lors d'une sorte d'audit, je regarde dans devtools, regarde dans le réseau et vois que le temps du serveur est de 800 ms - pour devenir fou, cela prend trop de temps. Et je vais, essayant de comprendre comment les gars ont un serveur, ce qu'ils font à chaque réponse. S'il s'agit de JavaScript ou de PHP, je serai très probablement en mesure de le comprendre correctement et de tout réparer, si un autre langage avec lequel je ne travaillais pas avait besoin de leur aide.
Dmitry: Pouvez-vous nommer l'un des 5 problèmes de performances les plus courants rencontrés dans la pratique?
Ivan: Je vais suivre la façon dont je me souviens. L'un des problèmes courants qui ne se produit pas dans les applications Web complexes, mais sur les sites simples, est lorsqu'un développeur ou un client place de nombreux scripts à l'intérieur de la balise head sans les attributs async ou defer , et cela est mauvais car le navigateur ne peut pas commencer à afficher la page avant ne chargera pas et n'exécutera pas ces scripts.
Et s'il y a un serveur lent ou un gros script qui prend beaucoup de temps à exécuter, la personne qui utilise le site ne verra pas la page jusqu'à la fin de l'exécution.
Un autre problème courant concerne les scripts tiers. Je travaille actuellement avec un client que j'aide à améliorer son score au phare . Initialement, le score du phare qu'ils avaient était d'environ 35-40. Je suis venu, j'ai fait toutes sortes de choses différentes, supprimé JavaScript inutile, bloqué les ressources, optimisé d'une manière ou d'une autre ... Après tout ce que j'ai fait, le score n'a augmenté que quelque part pour atteindre 55. Et il s'est avéré que si vous allez avec cette page optimisée et commentez un seul composant React qui charge toutes les analyses, le score du phare grimpe quelque part jusqu'à 88-90 + points. Cela se produit car il y a tellement de JS qui suppriment les métriques.
Dans certaines applications Web complexes, un sujet fréquent est lorsque les développeurs installent une sorte de grande bibliothèque et l'intègrent entièrement dans l'ensemble, bien qu'elle ne soit pas entièrement utilisée. Il s'agit souvent de Moment.js , dans lequel il existe d'énormes fichiers de localisation, 165 Ko de fichiers de localisation minifiés dont presque personne n'a besoin, ou lodash , dans lequel il existe de nombreuses méthodes, et tous n'utilisent que 10-20.
Avec les performances de rendu, il y avait un problème fréquent lorsque les développeurs suspendaient une sorte de gestionnaire d'événements, par exemple, sur un défilement d'événement, cela prenait 5 à 10 ms, et chaque fois que vous tentiez de faire défiler quelque chose, la page entière était en retard. Maintenant, cela est devenu moins, parce que dans le même Chrome [ajouté écouteurs d'événements passifs] ( https://stackoverflow.com/questions/37721782/what-are-passive-event-listeners ).
Comment mesurer les performances
Dmitry: Au fil des cas, une question sur le phare est apparue. À mon avis, tous les trois étaient au Sommet BeerJS , et il y avait un rapport sympa - (centième) d' Alexey Kalmakov . Il n'y a pas d' entrée , mais j'ai vu un article similaire sur Habré , et de telles choses un peu compromis Lighthouse. Si vous le prenez uniquement comme un outil pour évaluer le travail d'un ingénieur de performance, vous pouvez y faire quelques astuces.
Avez-vous des outils, peut-être même auto-écrits, avec lesquels vous pouvez clairement évaluer si vous avez réussi ou non. Par exemple, vous signez un contrat et on vous dit que vous devez faire des performances x2. Quel ensemble d'outils utiliserez-vous pour cela?
Ivan: Eh bien, premièrement, si nous concluons un contrat et convenons de x2, alors nous nous mettrons d'accord sur une sorte d'instrument. Mais en général, outre Lighthouse, j'aime vraiment WebPageTest . Il s'agit d'un outil de performance Web avancé très cool qui vous permet de tester votre application à partir d'un emplacement réel arbitraire, par exemple, le Brésil ou l'Australie, sur un appareil réel, par exemple, très faible, tel que Moto G.
C'est plus cool que Lighthouse, car il émule tout cela, et ce n'est qu'après des tests sur un véritable appareil que vous savez que le site est rendu pendant 15 secondes. Le deuxième avantage - il donne un tas de métriques super détaillées de toutes sortes de graphiques, tels que le chargement. Je l'utilise régulièrement pour regarder certaines choses.
Dmitry: Avez-vous Ă©crit l'un de vos outils, par exemple, en plus du protocole Chrome DevTools ? Qu'est-ce qui vous manque dans les outils?
Ivan: J'ai écrit mon instrument au-dessus du phare. Pour travailler avec l'un des clients, j'avais besoin d'une configuration qui me permettrait de mesurer les performances d'une page avec le phare dans un environnement assez stable, de le considérer comme le score du phare et de le copier dans le tableau. Il y a un problème avec lui: le phare de PageSpeed ​​Insights n'est pas très stable. Si vous mesurez la même page trois fois, vous pouvez obtenir trois mesures différentes. De plus, je devais mesurer non pas les pages prêtes et publiées sur le réseau, mais la page locale. Et la seule option consiste à exécuter Lighthouse localement, ce qui affecte également considérablement le score du phare, car le score commence à dépendre de ce qui fonctionne sur votre ordinateur portable. Par exemple, a lancé Docker, le score a chuté 2 fois.
Pour ce cas, j'avais besoin de mesurer le phare de façon prévisible. J'ai écrit un script qui a exécuté Lighthouse trois fois, une partition, a pris la valeur médiane des trois fois, et je l'ai fait pour de nombreuses pages avec de nombreuses configurations. J'ai loué un serveur DigitalOcean pour cela et j'ai tout géré pour le rendre aussi isolé que possible des facteurs externes.
Artyom: Vous avez mentionné un cas intéressant concernant différentes mesures Lighthouse. Il y avait récemment un article Une introduction au 99 centile pour les programmeurs , dans lequel ils venaient de conclure que les outils de benchmarking modernes et, en principe, le micro-benchmarking seul ne prouvent rien.
Avec des outils modernes, il se pourrait bien que j'aie fait une référence, vous avez écrit, Dima a écrit, et ils diront tous des choses complètement différentes. Et maintenant, dans un monde sans connaissances plus ou moins approfondies en théorie et en statistique, l'analyse comparative ne semble pas très plausible. Vous avez mentionné Lighthouse, mais y a-t-il des preuves que vous avez reçues dans l'indice de référence, une confirmation supplémentaire?
Dmitry: Peut - être mélanger Lighthouse avec quelque chose? Vous avez mentionné WebPageTest. Nous les prenons, peut-être même des observations de Chrome DevTools, et les mélangons en quelque sorte?
Ivan: En fait, idéalement, s'il y a quelque chose sur un projet qui vous permet de suivre les RUM (métriques d'utilisateurs réels) - la façon dont le site se charge pour certains utilisateurs, et si nous pouvons le déployer pour de vrais utilisateurs et voir comment cela a fonctionné pour eux - c'est le cas parfait.
Mais en général, oui, si j'utilise une sorte d'outil, je lance vraiment plus d'un test pour obtenir la valeur médiane, mais en général, l'article soulève le vrai problème qu'il y a une sorte de 99e centile d'utilisateurs qui ont tout très c'est mauvais et nous ne savons pas si nous utilisons simplement Lighthouse, mais cela ne veut pas dire que Lighthouse est inutile, il continue de fonctionner et montre la température moyenne à l'hôpital. Si dans l'ensemble nous avons amélioré les performances, Lighthouse le montrera.
Dmitry: Vous avez abordé les mesures réelles des utilisateurs. Je viens de travailler chez Odnoklassniki et nous avons eu des problèmes avec la façon de suivre cela, car il n'est pas clair comment le faire, et les volumes sont importants. Nous avons écrit les nôtres et collectés auprès des utilisateurs, et ce n'était qu'une sorte de chaos. Et s'il s'agit encore d'une sorte de projet moyen, que peut-on prendre sur mesure côté utilisateur? Juste window.performance ou autre chose recommandé? Ou utiliser des tactiques délicates, bombarder sur de vrais comptes d'utilisateurs?
Ivan: Tout d'abord, il existe probablement des bibliothèques ou des services prêts à l'emploi qui vous permettent de configurer RUM. Par exemple, ajoutez une ligne à la page et le suivi commencera. Deuxièmement, dans les navigateurs modernes, une chose telle que PerformanceObserver est apparue - il s'agit d'une API qui mesure toutes sortes de choses dans les navigateurs et vous permet de découvrir les mesures que le navigateur contient généralement à l'intérieur, y compris la première peinture enrichissante , la première peinture significative et tout cela. Et pour découvrir cette métrique, quelques lignes de code suffisent, vous n'avez pas besoin d'écrire quelque chose de trop compliqué. Je me suis abonné aux événements, l'ai reçu et réprimandé.
Dmitry: Et quelle est la chose la plus importante Ă laquelle vous devez prĂŞter attention en premier lieu? First Paint , le temps de l'interactif , le temps du premier octet , autre chose?
Ivan: J'en ai à peu près [il y a un rapport] ( https://www.youtube.com/watch?v=-H1l9XBXH6Q ) et je vous dis que les choses les plus importantes à regarder sont la première peinture significative et le temps d'interactivité. Et ils sont aussi importants qu'ils montrent exactement ce pour quoi l'utilisateur est venu en premier. Il est venu soit pour lire ou voir quelque chose, alors c'est la première peinture significative, soit pour travailler avec l'application, puis il est temps d'interagir. Si vous créez une sorte de page de destination ou de site d'actualités, optimisez la première peinture significative et si vous avez une application complexe, optimisez la première peinture significative et le temps d'interaction.
Artyom: Nous avons mentionné les cas les plus populaires dans votre pratique. Et quels sont les cas les plus rares ou les plus intéressants, dans lesquels vous avez dû creuser quelque part dans les tripes?
Ivan: Je pense que j'ai un cas assez intéressant maintenant. Je travaille actuellement avec Framer . Ces gars-là ont un outil de conception à la mode, un analogue de Figma et Sketch . Et je les aide à améliorer les performances d'exécution - c'est généralement une zone super intéressante pour moi. Ils utilisent le navigateur super spécifique. Les navigateurs n'étaient pas conçus à l'origine pour écrire des applications aussi complexes, donc Figma et Framer réimplémentent eux-mêmes de nombreuses pièces de navigateur. Et il y a beaucoup de leurs développements, qui ne sont pas sur d'autres projets, et qui sont super intéressants. J'aime travailler avec tout cela. C'est vraiment quelque chose d'intéressant, quelque chose de nouveau et de très cool.
Dmitry: Nous avons parlé des nuances de base du navigateur, et avant de passer aux frameworks, j'aimerais en savoir plus sur l'optimisation des performances en utilisant l'architecture, certaines structures de données. Avez-vous dû modifier quelque chose de si complet dans l'application, par exemple, ajouter une liste de préfixes pour la recherche ou autre chose qui n'est pas très courante pour le frontend? Est-ce que cela se produit?
Ivan: Je n'ai pratiquement pas travaillé au niveau des structures de données ou de la complexité algorithmique, car beaucoup de choses doivent être faites pour que l'application ralentisse dans ce domaine, et pas autre chose. Et donc, en ce qui concerne les gros morceaux, je recommande fortement à tout le monde lors de la création d'un nouveau projet ou si le projet vient de commencer et qu'il est encore assez petit, faites-le sur un framework comme Next.js ou Gatsby .
À la fois cela et un autre est un cadre pour React qui est construit de telle sorte que vous ayez simplement écrit une application en utilisant une paire d'approches de ce cadre, et il est automatiquement devenu rapide. Et ce sont des frameworks très populaires, ils font parfaitement leur travail, je les utilise moi-même dans mes projets de production et le recommande vivement à tout le monde.
Artem: Juste ici, nous avons récemment eu un incident lié à la façon dont le V8 s'est désoptimisé en raison du dispositif numérique à l'intérieur du V8. Avez-vous ressenti ce problème ou y a-t-il eu des recherches pour lesquelles l'application ralentit?
Ivan: Je n'ai pas ressenti et je n'ai pas lu cet article sur la désoptimisation. Y a-t-il eu une opération spécifique ou ralenti l'ensemble du React dans son ensemble?
Artyom: En général, parce que dans React, il y a un horodatage à l'intérieur de FiberNode, et il était initialement défini sur 0 et empêchait l'extension (preventExtension), et pour cela, une forme avec un petit entier a été allouée pour optimiser les opérations sur les nombres. Et lorsque l'horodatage a été rempli avec une valeur réelle, qui a dépassé 128, il s'est avéré qu'il était nécessaire de changer la structure d'un petit entier en un nombre de tas modifiable, et depuis que preventExtension a été appelé, des formes complètement nouvelles ont été construites pour chaque nœud de fibre. Et il y en a des dizaines et des centaines de milliers.
Ivan: Je ne l'ai pas remarqué, et je l'aurais à peine remarqué, car lorsque je débogue, je n'en ai pas en mémoire que cette opération ne devrait prendre que 10 ms dans React, et elle devrait en prendre 20. Je débogue, je regarde la trace des performances, Je sélectionne un goulot d'étranglement où quelque chose ralentit. Si les performances sont distribuées, il y a quelques décalages dans la V8 et sont répartis uniformément dans toute l'application, alors si je ne vais pas à des débogages très profonds, je ne le remarquerai pas.
Si cela se produit dans une opération V8 désoptimisée et que cela prend beaucoup de temps, je le remarquerai et entrerai dans un débogage en profondeur.
Artyom: Y avait-il vraiment un problème de React lui-même, ou d'autres cadres où vous deviez créer un problème, pour aller au fond des choses?
Ivan: À mon avis, j'ai signalé quelques bugs, mais je ne me souviens pas des détails ... Je ne pense pas que cela soit pertinent pour ce problème, mais j'ai récemment rencontré un cas intéressant où les variables css se sont avérées plus lentes que de changer d'applications par React prop. Et pour moi, cela semble étrange, car nous avions l'habitude de dire que css est ultra-rapide, puis soudain, cela fonctionne beaucoup plus lentement que React.
J'essaie d'ajouter un article à ce sujet, et en général cela fonctionne comme ça car il n'y a pas d'optimisation dans les navigateurs - si vous changez la variable css sur un élément qui a beaucoup d'enfants, alors le navigateur, au moins Chrome, ne se souvient pas lesquels les enfants utilisent cette variable et elle va calculer tous les enfants et les styles pour eux. S'il y a beaucoup de styles et de nœuds, c'est beaucoup de temps, et si vous remplacez une variable par React, alors le calcul des styles peut ne pas se produire et tout se fera rapidement.
Je suis sûr à 80% que c'est le cas selon ce que j'ai compris du code V8, mais je peux me tromper. Mais c'est une chose qui pourrait être enregistrée et réparée dans les navigateurs, mais ce n'est pas une microbogue, peut-être qu'il y a beaucoup de travail. Je ne l'ai pas encore signalé et je ne sais pas combien de temps sera consacré à le réparer si je le répare.
Artyom: Avez-vous dû regarder le bytecode résultant? Avec les mêmes vues de désoptimisation, vous regardez le bytecode V8, et y a-t-il des opérations supplémentaires qui sont insérées?
Ivan: Non, je n’ai probablement jamais étudié le bytecode, mais j’ai assez bien appris à lire du code JavaScript réduit. (rires)
Dmitry: Et à la réponse précédente - communiquez-vous en quelque sorte avec les développeurs de navigateurs pour clarifier ces choses? Et si oui, comment réagissent-ils? Et répondent-ils?
: 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: Je n'avais pas autant d'ateliers en quantité absolue, mais ce dont je suis le plus fier, c'est mon atelier webpack , que j'ai fait en introduction au webpack fin 2017. Malheureusement, il est déjà dépassé, mais il s'est avéré cool, car j'avais l'intention de mener une diffusion en ligne, mais ce jour-là , j'ai commencé à traîner follement sur Internet.
J'ai commencé à diriger, après 10 minutes, je suis tombé, je me suis reconnecté, je suis retombé et j'ai dû annuler tout cela de toute urgence, m'excuser et dire que j'enregistrerais tout le matériel sur vidéo et le mettrais comme ça. J'ai tout fait, présenté, il s'est avéré une série de vidéos comme sur egghead.io , et à l'exception du problème qu'il y avait un son très silencieux, car il n'y avait pas de microphone normal. J'ai entendu beaucoup de critiques, ce qui était très bien et cela a vraiment aidé les gens.
Dmitry: Que pensez-vous, pourquoi cela vaut-il la peine d'aller aux ateliers? Par exemple, si vous êtes allé à un atelier sur un navigateur, j'entends souvent que les gens veulent voir comment le V8 est vidé ou autre chose. Et en Occident, au contraire, si vous vous souvenez de la cool interview de Michel Weststrate, il a dit: «Je vais apprendre d'eux. Si je ne connais pas du tout Docker, alors j'y vais et j'obtiens rapidement des informations. » Comment voyez-vous les ateliers et dans quels cas recommandez-vous d'assister à vos ateliers? Apprendre, approfondir les connaissances, voir les tripes?
Ivan: Je dirais ceci - si la description vous a semblé intéressante, alors venez. Quand je fais des ateliers, j'essaie toujours de donner une sorte de base pour que les gens qui viennent travailler avec lui pour la première fois ne soient pas perdus. Je peux imaginer que certains des gars qui travaillent en super avancé sont venus écouter, peut-être que le début est ennuyeux. Ils peuvent ne pas rester jusqu'à la fin où un sujet avancé peut être soulevé. D’un autre côté, je ne peux pas promettre que je montrerai des tripes, car tout le monde a une compréhension différente des «tripes». Je vais venir montrer quelques cas super rares que j'ai rencontrés au cours de mon expérience, et quelqu'un d'autre peut venir et espérer que je ferai mes débuts avec le V8 ou que je compilerai Chromium, mais je ne le ferai pas.
Dmitry: Et qu'attendez-vous vous-mĂŞme, en principe, d'un atelier?
Ivan: Je me souviens que je n'ai assisté qu'à quelques ateliers de ma vie. Les deux fois, c'était un nouveau sujet pour moi, que je n'arrivais toujours pas à comprendre moi-même. Et les ateliers ont été une sorte d'introduction pour moi, et c'était super utile.
Dans mon atelier, je ne ferai pas du tout d'introduction à la performance et dans React, j'espère que les gens qui viendront en entendront parler, mais essayez de couvrir certains sujets de base et de montrer un débogage avancé autant que Je le connais et je l'ai rencontré.
Dmitry: Qu'attendez-vous de HolyJS dans son ensemble? J'ai peut-être remarqué des rapports ou des orateurs avec lesquels j'aimerais parler?
Ivan: Je ne planifie rien pour moi plus d'un mois à l'avance, donc je n'ai encore rien prévu. Il y a de la préparation et le reste arrivera. (rires)
Dmitry: C'est tout. Merci beaucoup pour l'interview. Nous attendons tout le monde Ă votre atelier .