«Vous devez connaître à la fois la pile Web et C ++»: une interview avec Alexei Kozyatinsky sur le développement de Chrome DevTools et pas seulement

Comment développer avec Chrome DevTools, tout le monde le sait. Et à quoi ressemble le développement de Chrome DevTools eux-mêmes? Alexei Kozyatinsky a précédemment travaillé chez Google et a fait exactement cela, et maintenant il est passé à Netflix, mais il n'est pas allé loin de ses activités précédentes.

Que fait-il exactement maintenant? Est-il réaliste pour un développeur ordinaire non-Google de copier quelque chose d'utile dans DevTools? Quels ordinateurs les ingénieurs Chrome utilisent-ils?

Nous accueillons actuellement la conférence HolyJS 2019 Piter, où Alexey a déjà fait un nouveau rapport, "Chrome DevTools Protocol" (l'enregistrement peut être vu dans la diffusion gratuite ). Et à cette occasion, il a été interrogé en détail par deux membres du comité du programme HolyJS: Dmitry DmitryMakhnev Makhnev et Alexei zolotyh Zolotykh .

Dmitry Makhnev: Parlez-moi un peu de vous. Où, comment, où, que faites-vous maintenant?

Alexei Kozyatinsky: Je reviendrai un peu et je vous dirai que Chrome DevTools chez Google fonctionne depuis plus de quatre ans. Fondamentalement, j'ai fait un débogueur JavaScript et tout ce qui concerne JavaScript, Node et tout ce qui peut être imaginé autour de JavaScript en général. Maintenant, je travaille pour une autre société appelée Netflix. Et ici, je suis venu pour faire une chose très simple: ils ont leur propre moteur Web interne avec leur propre JavaScript étrange. Et le tout a besoin de ses propres outils sympas, qui peuvent être appelés "Chrome DevTools". Et, en conséquence, mon objectif était de fabriquer ces outils.
C'est toujours d'actualité, je fais quelque chose et je suis absolument responsable de tout: pour le backend de cette entreprise, pour que le frontend DevTools fonctionne normalement. Et en même temps, notre objectif est de travailler de telle manière que je continue à faire de la contrebande dans Chrome DevTools, pour mettre à niveau tous les correctifs qui sont possibles. Pour que nous ne bifurquions pas, nous nous disperserons pour toujours et perdrons le résultat du travail de mes collègues cool de Google. Je continue donc à faire la même chose qu'avant - Chrome DevTools.

Dmitry: Cool.

Alexei Zolotykh: Votre biographie sur HolyJS a la formulation suivante: "Il a dirigé la plupart des tentatives de la société pour améliorer la vie des développeurs, en commençant par les piles asynchrones et en terminant par les nouveaux objets de requête à la mode." D'abord, pourquoi essayer? Et deuxièmement, pouvez-vous nous en dire plus - est-ce probablement plus à propos de Google?

Alexei: Commençons par le mot «tentative». Très bonne question. Et j'ai une réponse. C'était à l'origine le mot «efforts». Depuis que je vis et travaille en Californie depuis quelques années, une traduction m'a échoué. Pourquoi ai-je décidé de traduire le mot «effort» par «tentative»? Ce n'est peut-être pas encore une «tentative». Bien sûr, ce sont des «tentatives», parce que nous avons essayé de faire quelque chose, mais ce sont des tentatives réussies, nous avons terminé la plupart d'entre elles.

Mais en même temps, Query Objects - c'était quelque chose de petit qui peut être lu sur Twitter ou sur le Medium, et c'est ce que nous avons terminé. Et le débogage asynchrone est ce que nous devons terminer dans Chrome DevTools. Nous avons commencé à le faire, essayé plusieurs fois, car ce n'est pas une chose triviale. Vous essayez une solution - écoutez les utilisateurs, ils viennent vers vous et vous disent: "Je ne comprends pas ce qui se passe ici, pouvez-vous faire quelque chose avec ça?" Vous essayez différemment, essayez de faire autre chose, et donc, étape par étape, quelque chose se passe. Mais il est important de dire que la plupart des tentatives ont réussi.

Chez Google, j'ai passé la majeure partie de ma vie de développement. Je suis venu une fois en tant que stagiaire. C'était de retour dans des moments merveilleux quand il y avait un bureau Google à Saint-Pétersbourg. En arrivant là-bas, j'étais condamné à m'engager dans Chrome DevTools: je n'avais pas d'autre choix, car je suis venu en tant que stagiaire dans l'équipe Chrome DevTools. On m'a dit: «Voici un projet de stagiaire très simple. Nous avons une API sympa qui nous permet de prendre tout le code JavaScript, de le traiter en quelque sorte, de le renvoyer et de dire à Chrome d'exécuter un autre JavaScript au lieu du JavaScript qui nous est venu. "

Nous avions une telle API, et sur sa base, il était possible de construire un arbre AST. Je me souviens qu'à propos des arbres AST, il y avait un excellent rapport sur HolyJS. Il était nécessaire d'analyser l'arborescence AST et d'instruire le code de manière à mesurer le temps d'exécution et à écrire un profileur d'outils. Et c'était un tel projet Internet, je l'ai toujours quelque part sur GitHub. Cela ne fonctionne pas dans Chrome depuis très longtemps, car il a été demandé à l'API qu'il utilisait de le supprimer moi-même - c'était difficile à maintenir. J'étais très triste ce jour-là, car c'était l'API sur laquelle tout le projet a été construit - «supprimez-le». Et je l'ai supprimé. Après trois mois, je suis passé de stagiaire à ingénieur - je suis resté chez Google et j'ai commencé à faire tout ce qui concernait JavaScript. Commencé par quelque chose de très simple: je devais corriger console.log (). Et puis, il s'est produit progressivement que la partie principale de l'équipe d'outils liés à JavaScript a quitté l'équipe pour une raison quelconque, et je me suis retrouvé avec presque tout le JavaScript. À ce moment-là, c'était très effrayant, mais je me suis préparé et j'ai progressivement commencé à faire quelque chose, à comprendre quelque chose.

Parallèlement, JavaScript s'est développé, comme nous le savons, comme des liens, des promesses y sont apparues. Maintenant, nous avons déjà async / wait, les fonctions fléchées sont apparues dans tous les frameworks possibles, donc nous avions besoin de points d'arrêt en ligne (il n'y avait aucun moyen sans eux) - et j'ai fait, fait, fait beaucoup de ces petites améliorations. Les piles asynchrones se sont avérées être beaucoup de travail, il s'agit d'un modèle asynchrone qui décrit l'async en JavaScript dans un langage très simple.

Et comme vous ne pouvez pas travailler dans Chrome DevTools sur le frontend JavaScript et ne rien savoir du moteur V8, au cours de tout ce travail, j'ai progressivement dû passer de plus en plus en contrebande dans V8. J'ai beaucoup de correctifs là-bas. À un moment donné, nous avons déplacé le backend JavaScript du code Chrome vers le code V8. Bien sûr, c'était logique de le faire dès le début, mais historiquement, il n'était pas là. En même temps, Node est venu vers nous, nous avons dû le supporter d'une manière ou d'une autre, et nous avons décidé que si nous pouvions déboguer la V8, et que Node semblait utiliser la V8, pourquoi ne supportions-nous pas Node avec nous? Et nous l'avons fait, dans ce projet, je n'étais pas le plus important, mais j'ai activement aidé ceux qui l'ont fait. Je fais tout cela sur Google depuis environ cinq ans.

Dmitry: Que considérez-vous comme le plus cool et le plus difficile d'entre eux?

Alexei: Pour une raison quelconque, le dernier se souvient le mieux. Et le dernier était un projet intéressant que nous avons réalisé. Ceci est maintenant dans la console Chrome DevTools, lorsque vous tapez, vous pouvez voir le résultat en direct de ce que vous tapez. Si vous voulez tester de nouvelles fonctionnalités JavaScript (à l'époque c'était BigInt), vous imprimez simplement dans la console, voyez immédiatement le résultat, et vous n'avez pas besoin d'appuyer sur "Entrée" et de boucher votre console avec un milliard de résultats. Et le faire correctement est plus difficile qu'il n'y paraît. Il était très important pour nous qu'avec l'exécution gourmande de toutes vos expressions, nous ne détruisions pas l'état de votre programme, sinon tous nos utilisateurs seraient très contrariés. Et pour ce faire, nous avons dû prendre JavaScript, prendre la V8 et y ajouter la possibilité: exécuter n'importe quelle expression, mais s'assurer qu'elle ne change pas l'état de votre programme. Et c'était difficile, depuis longtemps et personne ne l'a fait avant nous, il n'y a plus de tels moteurs JavaScript. Je ne suis pas sûr qu'il existe de tels moteurs. Peut-être qu'en Java il y en a (parce qu'en Java, comme nous le savons, tout est là), mais je ne suis pas sûr. Et à ce moment-là, nous l'avons fait.

Ce fut un processus très long, qui a impliqué de nombreuses équipes différentes, car il était important pour nous non seulement d'exécuter sans «effets secondaires», mais également de garantir que si vous commencez soudainement à exécuter une boucle while (true) sans fin, vous ne suspendrez pas tout dans le monde, car le flux JavaScript est toujours le même. Et ce fut un effort distinct: il s'est avéré que le code Chrome lui-même n'aime pas quand JavaScript se termine à un moment aléatoire, auquel cas il aime dire: "Mm ..." et planter. Il fallait le réparer. Et nous l'avons fait aussi.

Le projet de ce travail a permis à Google d'obtenir même un brevet. Google a breveté de ne pas vous poursuivre, mais, comme la plupart des autres sociétés (sauf l'ancien Oracle, probablement), de vous protéger si quelque chose se produit si quelqu'un vient à eux et dit: "Mec, tu as fait Google "Recherche, c'est mauvais, nous avons des brevets." Et pour une raison quelconque, ces mecs feront le débogueur JavaScript en même temps. Google dira: "Et nous avons ici un tel brevet pour le débogueur JavaScript." Eh bien, les conseils en brevets savent mieux ce qui se passe là-bas, mais nous l'avons breveté, c'était amusant. Google donne une petite pièce du puzzle lorsque vous obtenez un brevet. Il est très cool. Et c'était très intéressant, car personne ne l'avait fait auparavant, et nous avons réussi à le faire.

Dmitry: Et il semblerait que quelque chose soit simplement affiché dans la console.

Alexei: Oui, oui, tout est très "simple", bien sûr. Quelqu'un a dit que toute technologie bien conçue ne se distingue pas de la magie.

Dmitry: Eh bien, oui, intéressant. Et qu'est-ce que je voulais vraiment faire, ne pouvait pas être fait? Autre chose? Plus puissant?

Alexei: C'est une question très dangereuse. Vous voulez toujours tout faire et il n'y a jamais assez de temps. Bien sûr, je voudrais terminer les choses que nous avons commencées, mais je ne les ai pas terminées. Il s'agit d'un modèle asynchrone, et le débogage asynchrone devait encore être terminé, bien sûr, et rendu plus évident pour l'utilisateur, pour prendre d'autres mesures. Je ne sais pas quoi faire là-bas, mais d'après la chose importante que je voulais terminer: V8 a un mécanisme similaire à HotSwap en Java et à des technologies similaires, lorsque vous pouvez prendre un morceau de code dans votre programme qui s'exécute en ce moment et le mettre à jour avec profit. Par exemple, vous avez défini une exception et savez comment la corriger, la corriger immédiatement là, enregistrer le fichier, et tout fonctionne plus loin, et comme s'il n'y avait pas d'exceptions - tout a été corrigé en direct. Ceci est un outil très cool. Certaines personnes pensent que cela peut même dans un certain sens remplacer le débogage, parce que vous écrivez progressivement le code en petits morceaux, vous pouvez immédiatement voir ce qui se passe - il n'est pratiquement pas nécessaire de déboguer après cela.

Et pendant très longtemps, il y a environ 9 à 10 ans, nous avions un code qui faisait cela. Il a été écrit un peu dans un autre monde, dans une réalité différente - il y avait un V8 différent, il n'y avait pas tous ces Ignition, TurboFan et tout le reste. Je ne suis pas sûr qu'à cette époque même Crankshaft était là, c'est le compilateur précédent en V8. Il n'y avait rien. Et asynchroniser / attendre n'était pas là non plus, bien sûr. Le code était très ancien, il utilisait de très anciens utilitaires V8 internes qui ne prenaient en charge que ce code, car à cette époque, personne ne voulait comprendre ce code et le réécrire.

À un moment donné, je me suis assis et l'ai réécrit, et il a commencé à planter moins. Mais il dit encore très souvent qu'il ne peut pas modifier votre code, car, par exemple, il n'y a pas assez de support pour les générateurs. Lors de l'écriture de ce code, il y avait un générateur par million de lignes de code en JavaScript. Et lorsque nous avons obtenu asynchrone / attendent, chaque fonction asynchrone / attend est en fait un générateur en soi. Par conséquent, si vous demandez de modifier le code avec async / wait, vous serez déçu.

Et comme ce sont toujours des outils pour les développeurs et le débogage, il y a une caractéristique désagréable: s'ils ne fonctionnent pas deux fois sur dix lors de l'utilisation de l'outil, ils ne l'utiliseront plus. Et j'aimerais beaucoup le terminer. Peut-être que nous allons le terminer, parce que maintenant j'apporterai probablement la V8 à mon nouveau lieu de travail et pour cette raison, je peux continuer à travailler dessus.

Dmitry: Cela pourrait-il fonctionner exclusivement pendant le débogage, ou pourrait théoriquement changer une partie de l'application dans une production d'application d'une seule page?

Alexey: Du point de vue du V8, en production il est plus facile de changer, plus difficile de changer quand on est en pause. S'il est suspendu, vous disposez de la trace de pile actuelle, qui est déjà en cours d'exécution. Il est nécessaire de mettre à jour ce code et de forcer toute cette pile actuelle, qui faisait référence à certaines variables de votre code, à continuer de fonctionner. Et lorsque vous venez de produire, vous pouvez attendre le moment où JavaScript est terminé (espérons que vous n'en avez pas (vrai)), et à ce moment tout est imperceptiblement remplacé.

Et c'est beaucoup plus simple, car vous pouvez simplement remplacer le code, vous n'avez pas besoin de mettre à jour tous les liens. Et la principale difficulté est, bien sûr, de remplacer toutes les liaisons, de redémarrer toutes les trames, de redémarrer les générateurs, etc.

Alex: J'ai soudainement eu une question sur l'utilisation de Chrome DevTools comme IDE. Il existe une telle fonction lorsque vous avez modifié JavaScript et vous pouvez en quelque sorte le lier au système de fichiers, et la même chose avec les styles. Et j'ai beaucoup de questions pour lui, car ça ne marche pas. Et je suis une personne paresseuse, j'aime le réparer en un seul endroit, par exemple.

Alexei: La question, apparemment, est pourquoi cela ne fonctionne pas. Il est important de dire initialement que Chrome DevTools n'a jamais été un IDE, ils ne se sont jamais positionnés comme IDE. L'IDE est un projet d'une échelle différente, il nécessite d'autres efforts et plus de monde. Chrome DevTools a été conçu d'abord comme un outil, puis comme un éditeur. Contrairement aux IDE, qui apparaissent en tant qu'éditeur, puis ajoutent un débogueur, des plug-ins, etc.

En même temps, nous avons compris qu'il serait très agréable pour nos utilisateurs d'éditer et d'enregistrer, il y a eu plusieurs tentatives pour le faire - maintenant, probablement, la deuxième ou la troisième tentative ... Mais tout se résume au fait que sur le web, en tenant compte de l'existence de tous ces compilateurs CSS webpack et tout le reste, une tâche très non triviale consiste à appliquer les modifications en arrière. Vous modifiez le code que vous voyez à l'intérieur de la page, vous devez comprendre d'où vient ce code dans votre page et appliquer soigneusement la modification.

Par conséquent, d'un autre côté, nous pouvons dire que nous pouvons simplement le faire pour travailler pour des personnes qui n'ont pas de configurations aussi complexes, mais, malheureusement, il s'agit d'un très faible pourcentage de nos utilisateurs. Maintenant, tout le monde a un webpack, Babel et ainsi de suite. Et ils transposent facilement et font quelque chose dans une direction, mais obtenir des informations dans la direction opposée est un problème. Pour CSS et pour SASS, cela a été fait d'une manière magique, et parfois cela semble fonctionner, je ne l'ai pas utilisé.

Si cela va changer à l'avenir, vous pouvez toujours demander. Vous pouvez utiliser Visual Studio Code ou votre IDE préféré (WebStorm ou autre), y modifier le code et Chrome DevTools essaiera d'appliquer ces modifications en direct. Mais en fait, nous avons un projet distinct pour notre interface pour Node, nous en parlerons probablement encore plus tard, cela fonctionne un peu mieux là-bas, car, Dieu merci, Node a le niveau maximum de compilation et de compilation TypeScript en JavaScript. Et c'est déjà difficile là-bas, mais j'espère toujours que sur Node la plupart des packages et modules sont écrits en JavaScript pur sans étapes de construction intermédiaires. Je n'ai pas répondu à la question, mais comme j'ai pu.

Dmitry: Que pensez-vous, comment Chrome DevTools se développera-t-il en principe? Quelles sont les choses les plus cool à attendre de lui?

Alexey: C'est une question difficile. À un moment donné, une personne est apparue sur Google I / O qui a créé un autre outil pratique pour les concepteurs. Cette extension pour Chrome, malheureusement, je ne me souviens pas du nom. Et il ajoute directement en haut de votre page des éléments qui vous permettent en tant que concepteur de modifier et de tout faire plus facilement. Et il y avait des idées que Chrome DevTools pourrait être un meilleur outil pour les concepteurs. C'est déjà un outil assez pratique qui peut, par exemple, regarder CSS et ainsi de suite, mais vous pouvez toujours le rendre beaucoup plus idéal et pratique. Par exemple, une édition plus pratique des propriétés flexibles et d'autres petites améliorations.
Et il y a une partie importante du travail sur Chrome DevTools: le projet est très grand, il a beaucoup d'utilisateurs et un grand flux de bugs que n'importe qui peut déposer sur crbug.com . Ils doivent être réparés, il y en a beaucoup et beaucoup de temps est consacré à tout faire fonctionner. Pour le débogage de la modification en direct de JavaScript, dont nous avons parlé, le hotswap peut être une bonne prochaine étape, mais cela peut ou non, je ne sais pas.

Alexei: Chrome DevTools, il me semble, est objectivement le logiciel le plus sophistiqué pour aider les développeurs web. Mais il existe d'autres navigateurs - Safari, Edge est toujours là, Firefox à nouveau. Y a-t-il des outils que je voudrais faire glisser depuis d'autres navigateurs dans Chrome DevTools? Y a-t-il quelque chose que vous aimez, à quel point c'est cool?

Alexey: les développeurs Chrome DevTools examinent régulièrement d'autres navigateurs. De l'intéressant que j'ai remarqué là-bas récemment, je me souviens que Safari avait une console très pratique. Ils ont très bien structuré la sortie vers la console et ajouté une navigation en utilisant les flèches sur les résultats. Vous pouvez sélectionner un objet là-bas, appuyez sur "droite" - il s'ouvrira. C'était sacrément pratique. Par conséquent, cette fonctionnalité est désormais disponible dans Chrome DevTools.

Dans Firefox, à partir des choses intéressantes de DevTools, il me semble qu'ils supportent un peu mieux l'édition visuelle de toutes les propriétés CSS - j'entends par là des propriétés comme flex et d'autres - ils vous montrent la grille directement en haut de la page, et vous pouvez la déplacer vers le haut vers le bas. C'est cool, nous l'avons en partie, mais pas complètement. Firefox DevTools, je pense, a actuellement de loin le meilleur support pour WebAssembly. Si pour une raison quelconque, vous devez écrire du code WebAssembly, alors ils sont bien meilleurs que nous, car nous n'avions rien il y a six mois, maintenant je ne l'ai pas vérifié. Je pense qu'ils investissent beaucoup d'énergie dans ce domaine.

Quant à Safari ... d'une certaine manière, Chrome DevTools est un fork de l'inspecteur Web de Safari, nous avons donc pris tout le meilleur qu'ils avaient.

Je me suis souvenu de la chose importante! Seul Firefox a probablement le débogage dans le temps. Sur un Mac, dans les versions nocturnes de Firefox, vous pouvez vous adonner au débogage dans le temps. J'ai gardé le silence sur lui quand on m'a posé des questions sur les grandes étapes suivantes: cela semble très cool, très monumental - je ne pense toujours pas que ce soit très utile. Point de vue personnel. Mais ils l'ont, vous pouvez essayer, si cela vous aide, ce sera un nouvel outil intéressant.

: . , , -- . , ( ) , , 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 — ? Ce n'est pas un problème. , 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. , . , , - - , — , . , , - , , . C'est compliqué.

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

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

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

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

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

: : HolyJS?

: HolyJS, . , , . , , , .

: , ...

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

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