Presque tout sur le futur HolyJS 2019 Moscou

HolyJS 2019 Moscou se tiendra du 8 au 9 novembre à Moscou - une grande conférence pour les développeurs JavaScript. Auparavant, nous avions publié de longues listes sur Habré avec une description formelle des rapports, mais il semble que tout cela puisse être lu de toute façon sur le site .

Au lieu de cela, nous avons rassemblé une composition presque complète du comité de programme et discuté des choses les plus importantes: ce qui se passe actuellement dans le monde de JavaScript, le front-end du navigateur, le serveur principal et d'autres domaines, ce qui mérite d'être écouté et comment cela affecte le programme de la conférence. Ajout d'un tas de liens intéressants et de belles photos. Venez sous le chat, installez-vous, nous commençons.

La conversation implique:

• Eugene Kot et Artyom Kobzar de Wrike;
• Tanya Denisyuk et Dmitry Makhnev du groupe JUG Ru;
  
• Alexey Zolotykh d'Infobip;
• Mikhail Bashurov de l'EPAM;
• Mikhail Poluboyarinov de Health Samurai;
• Vasily Vanchuk;
• L'interview est menée par Oleg Chirukhin.

Image globale

Oleg: Parlez-nous du programme de la conférence. Comment les thèmes sont apparus, comment ils sont organisés, s'ils ont une sorte de logique interne, et pourquoi ils sont si nombreux.

Dmitry: Chaque fois que nous organisons une conférence, nous devons choisir une direction principale et nous fier aux retours d'expérience. La direction principale est généralement ce qui est maintenant super pertinent, quelque chose de très important. Si nous prenons le dernier HolyJS , nous avons spécifiquement essayé d'inviter Ryan Dahl , car Deno était frais et voulait entendre parler de lui en Russie . Eh bien, plus Ryan Dahl.

Cette fois, nous nous sommes particulièrement concentrés sur la langue elle-même, car maintenant TC39 commence à travailler de plus en plus activement et de manière transparente, et nous voyons que le public est intéressé. Par exemple, la chaîne Telegram de Sergei Rubanov et Roman Dvornov est lue par un grand nombre de personnes.

Premièrement, il nous a semblé que c'était un sujet intéressant. Deuxièmement, lorsque nous avons commencé à revoir la composition de TC39 , nous avons constaté qu'il y avait un grand nombre de personnes intéressantes qui travaillent dans des entreprises intéressantes - Google, PayPal, Mozilla, Bloomberg. Ces personnes font encore parfois des moteurs JavaScript. Je voulais vraiment me concentrer sur ces choses.

De plus, nous avons toujours un pool d'applications, cette fois c'était, comme d'habitude: plus de 200 avec une si bonne compétition pour une place, donc à partir de ces applications, nous essayons d'assembler un programme suffisamment diversifié pour ouvrir quelque chose de nouveau pour les étudiants. Cette fois, nous n'avons pas poussé d'une manière ou d'une autre fortement sur les rapports expérimentaux, ils l'étaient par eux-mêmes. Cette fois, nous nous sommes tournés vers les compétences générales, car elles sont demandées et considérées comme importantes .

On peut voir que le public augmente, grandit dans les entreprises, dans les communications et dans la gestion. Par conséquent, les compétences non techniques sont une partie importante pour nous. Pour commencer avec ce qui était le premier but, c'était le TC39. Nous avons réussi à trouver des délégués au TC39. Et parmi les orateurs, il y aura un autre expert invité.

TC39 est composé de délégués - ce sont des personnes représentant des entreprises spécifiques, il y en a plus de 100. Il y a aussi un très petit nombre d'experts invités, environ 20 personnes. 3 personnes tentent de gérer et de coordonner le TC39, ce sont les coprésidents du comité, 2 d'entre eux nous aurons.

Rapports fondamentaux et initiés du TC39

Oleg: Purement, comment le TC39 affecte-t-il la vie d'une personne ordinaire?

Dmitry: Très simple! TC39 forme un langage - votre outil le plus élémentaire exécuté par les moteurs JS.

Des représentants des moteurs JavaScriptCore , qui sont situés dans Safai et iOS, et SpiderMonkey , qui est situé dans Firefox, feront également des présentations.

Si vous allez plus loin et dites que TC39, bien sûr, développe le langage, mais tout le monde utilise Babel . Nous aurons un développeur de l' équipe de base de Babel : Nicolò Ribaudo , qui coupe des fonctionnalités assez pertinentes et complexes, par exemple, comme le chaînage optionnel et la coalescence nulle . Nous fermons donc l'épine dorsale de la langue.

Artyom: Nous aurons toujours un rapport fondamental , en principe, sur la théorie des langues d'une personne qui est dans le milieu universitaire - Vitaly Bragilevsky .

Dmitry: Nous avons également reçu de nombreuses candidatures, parmi lesquelles nous avons essayé de choisir des sujets d'actualité. Nous nous souvenons que l'on nous demande toujours Node.js, par conséquent, nous tremblons avec le choix des rapports sur Node.js. Cette fois, il y a beaucoup de choses intéressantes.

De plus, nous travaillons actuellement sur la création de Node.js Code + Learn afin qu'il soit à côté de la conférence. Comme d'habitude, des collègues de PiterJS nous aident avec cela.

De nombreux rapports différents sont venus sur différents sujets. Séparément, on peut distinguer quelque chose au sujet des cadres, car ils le demandent beaucoup. L'accent est mis sur React et Angular. Nous avons finalement réussi à trouver un reportage angulaire sur Angular Ivy , sur lequel, il me semble, il sera intéressant d'écouter tout le monde.

Et il existe une catégorie spécifique, appelons-la «initiée», qui comprend des rapports difficiles à attribuer à quoi que ce soit. Les gars qui nous ont beaucoup impressionnés par leurs pensées.

Tanya: Un autre point important. On nous demande toujours de pratiquer. Outre le fait que les rapports eux-mêmes contiennent des cas pratiques, nous y parvenons également avec deux ateliers qui se tiendront chaque jour. Ceci est également important à noter, car ce sont les visiteurs qui peuvent non seulement apprendre quelque chose, mais aussi l'essayer en direct, et les gars qui animeront les ateliers les aideront. Les gars sont également connus dans la communauté et en tant que spécialistes.

Ateliers

Dmitry: Je voudrais attirer l'attention sur les sujets des ateliers , parce que nous essayons de supposer que le thème est primaire, et alors seulement nous recherchons des personnes intéressantes.

Le premier sujet que nous avons cette fois est très important - c'est Node.js pour les gens du front-end. Si vous souhaitez plonger lentement dans le backend, cet atelier est fait pour vous. Andrey Melikhov vous dira quel est le râteau principal et comment commencer.

Le deuxième sujet, le plus douloureux et préféré, est l'optimisation des applications React. Ivan Akulov , qui possède sa propre société de conseil en productivité, en parlera . Nous avons remarqué Ivan lorsqu'il dirigeait jsunderhood , il a simplement brisé notre perception par le flux d'informations , après quoi nous ne pouvions pas l'inviter.

Oleg: Comment se déroulent les ateliers?

Dmitry: Les ateliers sont, en gros, le quatrième volet. Un atelier le jour de la conférence. Ils sont inclus dans le prix de la participation à la conférence, vous venez de venir, vous avez la possibilité de les visiter. Habituellement, c'est l'après-midi pendant deux heures de conférence, soit environ 2,5 heures avec une courte pause.

Oleg: L'orateur qui le dirige travaille-t-il individuellement ou en groupe?

Dmitry: Il travaille pour un groupe, mais son conservateur peut l'aider. Ce format est nouveau pour nous. Nous avons organisé seulement deux ateliers ( sur Svelte et sur Webpack ) une fois cette année à Saint-Pétersbourg, il est donc difficile de dire exactement sur le formulaire. Nous pouvons dire avec certitude qu'il y aura une énorme quantité d'informations et les gars répondront certainement à un grand nombre de questions.

Mais comment coder avec eux ou ne pas coder ... bien sûr, nous nous efforcerons de le faire, mais ici, étant donné que nous sommes verts et que nous n'avons pas beaucoup de temps pour l'atelier lui-même, et en principe, les ateliers ne sont pas très courants ici ... nouvelle pratique au niveau, je dirais même, du pays, et non des conférences. Ils assistent rarement aux conférences de nos spécificités. Nous apprenons. Évaluons-le lors de la conférence.

Je pense que les gars sont forts, ils ont de l'expérience. Si nous parlons d'Andrei Melikhov, il dirige une énorme équipe à Yandex.Money. Et si nous parlons d'Ivan Akulov, il a l'expérience des ateliers, à ma connaissance, assez gros.

Tanya: Ivan le fait, cela fait partie de son travail. Autre question: pourquoi l'optimisation React est-elle si importante?

Dmitry: L' optimisation de React est importante parce que React devient la norme dans l'industrie de facto, mais il y a toujours beaucoup de questions, beaucoup de controverses, beaucoup de goût. Je voudrais collecter des informations informées qui seraient bien préparées et vérifiées avant l'atelier et fournies par une personne ayant une opinion faisant autorité afin d'améliorer vos processus de travail, y compris l'examen.

Il existe des ensembles de bonnes pratiques dans React, mais même d'après ma propre expérience, je dirai que si vous commencez tout juste à y entrer, ils ne suffisent pas. Écrire une autre source faisant autorité à cet égard semble bon.

Artyom: De plus, au moins la performance dans React est un sujet sensationnel, par exemple, récemment, il y avait un problème de performance , qui a été traduit par tout le monde.

React, en principe, est une boîte fermée, il peut être influencé par un ensemble de pratiques. Vous devez comprendre à la fois les composants internes de React afin de créer ces pratiques et la façon dont ces composants internes interagissent avec les moteurs individuels. Supposons que, dans un problème récemment sensationnel, le problème est que ce soit uniquement dans les navigateurs Chrome et Chrome. Elle était assise et cherchait des gars du V8.

Dmitry: En plus de simplement pratiquer et "croyez-moi parce que je l'ai dit", si vous entrez et voyez la description de l'atelier d'Ivan , il a beaucoup de choses sur la façon de profiler React et les rediffuseurs, comment profiler les applications en principe, et même comment essayer de le faire en production.

Oleg: Parlons -nous d'un atelier ou seulement deux à la fois?

Alexey: À propos des deux. Le premier concerne la partie serveur, le second concerne le frontend. Il y a une demande pour cela.

Dmitry: Et ce qui est important, c'est une demande à double sens. Il y a également une demande de la communauté, car les fournisseurs frontaux commencent à approfondir le backend sur Node.js et les entreprises qui écrivent à Node.js. Andrei a mentionné à plusieurs reprises dans son podcast que ses collègues issus du front-end commettaient des erreurs très basiques lors de la conception d'applications serveur. Il me semble qu'Andrei, même en tant qu'employeur, souhaite que ses collègues comprennent mieux cela.

Oleg: Les intervenants communiquent-ils généralement les uns avec les autres, établissent-ils des liens et des demandes entre eux? Les opinions des participants sont-elles prises en compte?

Tanya: Je me souviens comment les gars de Chrome DevTools ont parlé à Ryan Dahl lors de la conférence, puis ont pris tout cela en compte.

Artyom: Nous aurons un rapport d' Ujjwal Sharma de l'équipe Node.js, son rapport a été discuté lors du dernier HolyJS à Saint-Pétersbourg. Au début, nous nous sommes assis et avons parlé avec lui, avons abordé un sujet, puis il est allé voir Ryan Dahl, a discuté, et nous avons donc obtenu le rapport qu'il raconte sur ce HolyJS.

Dmitry: Je pense que les intervenants tiennent compte de ce qui se passe à la conférence et dans les zones de discussion. Je conclurais cela simplement du temps passé dans les zones de discussion. Par exemple, Ilya Klimova peut y rester une heure et demie, Michel Weststrate est parti après la même heure. Et en général, les intervenants y passent environ une heure.

Élargir les horizons

Oleg: Souvent, lorsque le programme est en cours de montage, vous avez la plupart des rapports sur ce que le public veut, mais il y a des sections spéciales auxquelles personne ne s'attendait, et ils le font. Qui existent pour améliorer l'érudition. Pour montrer au public ce que personne n'entendait habituellement. Existe-t-il un tel programme dans ce HolyJS?

Artyom: Je ne sais pas, il me semble que Vitaly Bragilevsky en est un exemple. Lors d'une conférence JS, parlez de la théorie des langages de programmation, de la façon dont vous construisez d'abord une machine Turing sur JS, puis un interprète pour le calcul lambda, puis exprimez d'abord une machine Turing à partir du calcul lambda, puis vice versa - cela me semble un rapport plutôt inhabituel pour Conférences JS. Néanmoins, elle élimine un certain analphabétisme du point de vue de l'informatique théorique.

Dmitry: Vous pouvez également compléter immédiatement Artyom avec la présence de Lucas da Costa dans le programme.

Alexei: Il a toujours occupé les meilleures notes et en général ce n'est pas si simple - de dire des choses complexes dans un langage simple, en particulier théorique.

Dmitry: Pour la première fois, il a expliqué comment utiliser la fonction pour tout faire, y compris booléen, mathématiques, etc., et la deuxième fois sur les combinateurs Y. Autrement dit, nous ne recevons pas de demande directe «parlez-nous des combinateurs Y». Mais si les gens viennent à nous avec un sujet intéressant et que nous comprenons qu'il peut être très utile, nous le leur donnons. Autrement dit, si lors de la lecture, vous aviez une question «Pourquoi ai-je besoin de combinateurs Y», nous vous recommandons de consulter le rapport.

Artyom: J'ajouterai un deuxième rapport de mon ami Dmitry Patsura , qui portera à nouveau sur la possibilité de compiler JS. Tout d'abord, tout le monde dans la communauté ne pose pas une telle question: est-il possible d'interpréter simplement le langage interprété en quelque chose et de l'exécuter.

Néanmoins, la personne s'est demandée si le compilateur avait fait pour prouver ou infirmer cette hypothèse et, en fait, dirait pourquoi le dispositif d'interprétation moderne, qui se trouve en fait sous le compilateur JIT creux, est tel qu'il est. Pourquoi ils sont disposés exactement de la façon dont ils sont organisés, et pourquoi nous ne pouvons pas prendre JS dans sa forme pure et le compiler dans une sorte de binaire.

Dmitry: Si vous ne manquez pas le rapport sur V8, alors vous devriez aller en toute sécurité à Dmitry, car à bien des égards, il le fera autour de V8 et montrera directement comment faire du bytecode V8 et comment interagir avec. Autrement dit, il veut donner des informations sur des outils très intéressants autour de tout cela.

Nous pouvons probablement mettre en évidence un rapport sur l'éducation. Personne ne demande jamais: "Comment puis-je me former?", Parce qu'en quelque sorte ils vivent, et il y a beaucoup de cours. Sur le thème de l'éducation sera un rapport de Dmitry Voloshin .

Michael: Un autre de l'insolite est Anna Herlihy . Ceci est juste un excellent rapport ! Les collègues ont pensé à prendre et à écrire une sorte de frontend pour convertir n'importe quelle langue en une requête MongoDB. Malgré le fait que cela peut être non seulement un langage de programmation existant, mais aussi des schémas visuels. Un gestionnaire peut venir, qui ne rentre pas dans le code, mais travaille avec la logique métier. J'ai jeté les organigrammes et il a reçu une demande à la base de données MongoDB.

Eugene: Anna a travaillé avec Mongoose pour MongoDB, et au fil des années de construction d'ORM dans différentes langues, elle est devenue habile à créer un tel système.

Dmitry: Eh bien, les collègues de TC39 seront la cerise sur le gâteau. Personne n'a demandé quelque chose de fort, mais nous faisons beaucoup de choses avec eux, y compris le panel TC39 ( exemples de cette activité ). Pour le moment, il y a confirmation de deux délégués, deux coprésidents et deux experts invités. Vous pouvez déjà leur poser des questions pour discussion.

En outre, l'un des coprésidents, Aki Rose Braun ouvrira la section des discussions éclair avec un rapport sur la façon dont le TC39 traite les phrases dans la langue . Vous pouvez non seulement l'écouter, mais aussi venir poser des questions. Je recommande fortement d'attraper les coprésidents ils sont très actifs et participent à bien des égards aux communications entre TC39 et la communauté.

Node.js

Oleg: Passons aux sujets des rapports. Par exemple, que se passe-t-il dans le monde de Node.js? Et comment cela se rapporte-t-il aux rapports?

Artyom: Maintenant dans Node.js, la tendance vers les frameworks pour adultes évolue progressivement. Qu'est-ce que j'entends par des cadres adultes - ceux qui fournissent une abstraction suffisante pour que nous ne manipulions pas directement certains éléments du serveur lui-même comme la route, la demande, la réponse, etc., mais directement les objets de domaine de domaine.

Et pour cette raison, NestJS , qui est comme une entreprise trop classique avec des annotations, avec des classes, est également née très hype. Un tel enfant de Spring et ASP.NET au minimum. Et il s'avère qu'à HolyJS 2018 Moscou, nous avions généralement le créateur de ce cadre ( Kamil Mysliwiec ), mais il a principalement parlé de l'intérieur. Et cette fois, nous aurons un rapport plus pratique, qui est fait par Alexander Kalinin .

Quelle est sa valeur pratique? Le fait que la plupart des applications Node.js aujourd'hui soient écrites sur l' Express plutôt populaire, qui occupait une très grande niche à l'époque, et maintenant, je pense, prend également quelque chose. Il utilise l'ancienne façon de manipuler les abstractions de bas niveau - demande, réponse, serveur, socket, port, etc.

Alexandra expliquera comment ils ont transféré leur application Express vers NestJS. De plus, elle vous expliquera pourquoi cela vaut la peine, c'est-à-dire quels sont les avantages, et pour différents publics, à la fois pour le développeur et pour le gestionnaire. En tant qu'entreprise, c'est vendre en tant que client. Et ils l'ont fait en deux semaines. Malgré le fait que l'application était de complexité moyenne. À mon avis, il a sonné le nombre de 80 heures.

Dmitry: Plus loin sur Node.js, il est maintenant clair qu'ils continuent de chercher et d'attendre Deno , car cela ne peut que susciter l'intérêt. Premièrement, parce que TypeScript est là, et deuxièmement, Ryan Dahl a dit: "Je vais le faire cool maintenant."

Et Ujjwal Sharma examinera les cas, dans quels cas vous feriez mieux de prendre Deno, et dans lesquels il est préférable d'obtenir Node.js dans l'état actuel. Il enquêtera sur leurs boucles d'événements, car elles sont en fait différentes, il fera des recherches sur ce sujet, afin que vous puissiez comprendre quelles tâches pratiques vous pouvez déjà effectuer et toucher Deno. Ceci, bien sûr, est également très intéressant. Parce que maintenant sur Node.js, beaucoup de choses sont écrites sur TypeScript.



Oleg: Écoutez, je me suis inscrit à Deno github, j'ai lu les commits et on a l'impression qu'il y a beaucoup de bugs . Dans quelle mesure cela peut-il être utilisé du tout et est-il sensé d'en parler?

Dmitry: Eh bien, c'est à peu près tout, je pense qu'Ujjwal nous le dira également. Parce qu'il n'a qu'à enquêter sur cela dans le cadre de tâches pratiques. En gros, si vous avez juste besoin de créer une API proxy, vous en avez besoin, et si vous devez faire un rendu côté serveur, alors ceci. Autrement dit, il doit s'appuyer sur son rapport à partir de choses pratiques spécifiques, que vous venez de demander. Et, grosso modo, s'il y a des problèmes avec la boucle d'événements, par exemple, sur un grand nombre de requêtes, alors Ujjwal, il me semble, a juste besoin de trouver et de décrire les zones où il peut être pris, en tenant compte des bogues et non des bogues.

Peut-être au contraire dira-t-il que c'est impossible du tout, mais potentiellement ce sera intéressant pour les tâches futures. C'est le genre de recherche en cours. Pourquoi ne puis-je pas parler de la finale - car, il me semble, même dans les derniers jours avant la conférence, quelque chose peut être ajouté. Parce que Deno est en développement actif et Ujjwal reste en contact avec Ryan - ils correspondent directement dans WhatsApp. Ujjwal est également un membre principal de Node.js, et il garde également le doigt sur le pouls, il peut donc y avoir également des mises à jour ultra-fraîches.

Artyom: Il est un membre essentiel du V8, Electron, et je ne sais pas où il ne fait pas partie des projets fondamentaux.

Dmitry: Il a 21 ans, il a beaucoup d'énergie, donc nous espérons une étude très intéressante, qui sera intéressante pour la communauté.

Michael: Encore une fois, le troisième sujet, toujours d'actualité, concerne les performances des applications Node.js. Et ce thème sera couvert par Andrei Pecchurov . Dans son rapport, il montre comment sur un vrai produit, qui est utilisé par beaucoup de gens, ils ont compris la performance. Et ce n'est pas dans les tâches concernant les moules, mais dans quelque chose de sérieux.

Il vous montrera comment trouver des problèmes, comment les résoudre, où ils les avaient. Et il sera possible de lui parler de questions pratiques.

: , performance-?

: . , , , C#, Java - Node.js, - , , , - .

Engines

: JS-. -, ? , , TC39.

: -, … React, c , . , .

, - , , , . 2012 . , Crankshaft . CrankshaftScript — , , .

: .

: --, Ignition TurboFan , -. , , , .

, , Yulia Startsev Mozilla SpiderMonkey Firefox. Firefox Quantum -, , .. SpiderMonkey . , — ! Yulia TC39, developer tools Mozilla. , proposal-: Nullish Coalescing . , - . -. , , SpiderMonkey . , Hermes QuickJS .

— JavaScriptCore. WebKit, , JS, V8. Michael Saboff Apple. WebKit 9 , TC39. , - Apple , Apple, . , . , . Safari, , , , . Michael , .. .

: , , , V8, - . -, .

: , JS . .

: .

: . : JS ? , , . , . C 2 JIT-. , — . .

Facebook . , ahead of time . intermediate representation .

React Native, , - overhead , , intermediate language, runtime.

: « ?». , - , LLVM , . , , , . TypeScript LLVM, , , JS .

Soft Skills

: — . , !

: . , HolyJS — JavaScript-, - Soft Skills. , XIX , XXI.

, , -, ( ), , .

- , soft skills. HolyJS 2018 Piter soft skills ( ), . , , . — .

: soft skills , soft skills , , , . , , , soft skills .

: , . , , soft skills.

: soft skills — , , . , - . .

: , Mail.ru, : , , , , .

, Otus , Middle+. , Middle+ JavaScript, - , . , .

: , , , , . , «» , ? .

Fundamentals

Oleg: Analysons la catégorie des rapports fondamentaux. Qu'est-ce qui est généralement fondamental, parce que le mot est en quelque sorte vague, et pourquoi est-il important?

Artyom: Les sujets fondamentaux sont le ciment de toutes les connaissances pratiques. Autrement dit, c'est la base théorique sur laquelle la majorité des outils et des solutions sont construits généralement partout. C'est la base académique qui est nécessaire pour comprendre la pratique, comprendre pourquoi la pratique s'est formée de cette façon.

Le premier rapport que nous avons est Vitaly Bragilevsky . Non seulement il traduit des livres sur Haskell, non seulement il écrit un livre sur Haskell , non seulement il est membre de deux comités de normalisation (l'un Haskell 2020, l'autre Haskell Glasgow Compiler), il est également enseignant, actuellement à l'Université d'État de Saint-Pétersbourg. À ce jour, il a le cours de langue russe le plus populaire en théorie des catégories . En principe, il fait de bons cours.

Il a répondu à nos demandes de nous parler et a décidé de proposer un sujet non standard qui révèle la base des calculs, comment les calculs sont généralement construits dans n'importe quelle langue, dans n'importe quel instrument qui accomplit quelque chose. Il nous parlera de la machine de turing, du calcul lambda, de la classe P, de la classe NP et de la complétude NP.

C'est-à-dire tout ce qu'il faut gentiment dans l'informatique théorique, qui, comme il lui semble, devrait être présent chez une personne qui se dit ingénieur et prétend être un expert en informatique pratique.

Eugene: Lucas da Costa poursuit à nouveau sa séquence de victoires. Cette fois, il a décidé de passer les tests. Et pas seulement des tests, mais des tests de type. Comment faire cela d'un point de vue théorique et pratique.

Dmitry: Et ce qui est important, Lukash a vraiment le droit d'en parler, car il était le mainteneur de bibliothèques de test bien connues comme Chai.js et Sinon.js .

Eugene: Il parle de Jest , de clichés. La dernière fois, dans une série d'examens des rapports de Lucas, on lui a dit qu'il avait trop de théorie. Et il a tenu compte des demandes, mais a décidé de le faire dans son propre esprit: quitter la théorie et ajouter de la pratique. Ce sera donc intéressant pour les deux.



Oleg: Et Mathieu Henri ?

Michael: Eh bien, il a en fait un rapport légèrement plus simple. Et si vous regardez d'un coup d'œil, il y a une histoire standard. C’est juste un gros projet, où il y a beaucoup de dépendances entre le code, les composants sont partagés entre différents projets. Et vous devez tester ces composants afin que lorsque vous ajoutez des modifications à un composant, rien ne se casse dans les autres applications.

Ce qui est intéressant ici, c'est qu'il s'agit d'un projet Microsoft. Et, par conséquent, ils ont une très large audience et se concentrent sur un grand nombre de navigateurs et, en principe, de clients. Ils font partie de ces camarades qui prendront probablement en charge Internet Explorer 11 jusqu'au dernier, et ils doivent également gérer le trafic mobile, etc.

Et, en conséquence, ils avaient une tâche - comment trouver les problèmes le plus rapidement possible au cas où vous changeriez un composant et cela affecterait toutes les autres applications.

En fait, Mathieu parlera de la façon dont il a écrit son propre framework, qui vous permet d'exécuter uniquement les applications qui affectent les composants qui ont changé, et de le faire avec une charge minimale sur le système.

Parce qu'il est clair que le lancement de plusieurs clients et d'un tas de machines virtuelles pour chaque système sur chaque navigateur n'est pas un problème, mais quand il y a beaucoup de telles modifications, la question se pose que la charge mettra simplement CI et pipeline, et c'est ce sur quoi il a travaillé.

Il dira comment il a organisé CI et quelles puces il y a, par exemple, les différences visuelles, et en général quel système, quel cadre il a dessiné afin de résoudre les problèmes au sein de Microsoft.

La chose la plus intéressante est précisément l'expérience des grandes entreprises, car il y avait également une demande à ce sujet, afin que les grandes entreprises partagent la façon dont elles ont tout organisé. Pour le reste, la tâche plus ou moins est typique, mais pas typique, dans quels volumes elle est résolue.



Oleg: D'accord. Nous passons à Nicolas Belmonte .

Artyom: Nicholas travaille chez Mapbox , une entreprise qui fabrique des cartes. Le rapport parlera de ces algorithmes, encore une fois, de cette base fondamentale, qui se trouve derrière la construction de cartes.

A propos du rendu en 3D. A propos du dessin de polygones spécifiques, des calculs, de l'emplacement, des coordonnées et de tout ce qui est à la base de la construction de ce type d'application.

Naturellement, il y aura très probablement des algorithmes sur les graphiques, qui sont encore une fois fondamentaux pour construire des cartes, pour trouver un chemin sur ces graphiques, etc.

Dmitry: Vous pouvez voir certains de ces rapports , de mon point de vue, à l'une des meilleures conférences de la CEI sur la JS, à savoir au FDC , de Vladimir Agafonkin . Vladimir fonctionne uniquement dans Mapbox et traite les cartes du côté de JS.

Et Nicolas est également responsable du rendu de ces cartes en termes de C ++, iOS, Android et du Web. C'est-à-dire: il semble regarder tout cela, probablement au plus haut niveau possible du point de vue de toute la Mapbox, qui, bien sûr, ne peut que susciter l'intérêt.

Oleg: Au fait, cette Mapbox est-elle quelque chose de célèbre ou de très local?

Artyom: Pour autant que je sache, en termes de prix, à mon avis, la troisième solution est la plus populaire parmi les cartes, je peux me tromper, mais quelque chose sur ces chiffres.

Oleg: Je répète qu'il a laissé le directeur d'Uber dans Mapbox, juste parce qu'ils ne quittent pas Uber.

Dmitry: Mapbox est une entreprise très sérieuse, qui pour le moment devrait être bien connue du développeur JS moyen.

Cadres

Oleg: La section suivante est les cadres. Le plus gros, probablement.

Eugene: Le plus aimé, probablement. «Cadres. Les cadres ne changent jamais. »

Oleg: Mais y a-t-il une tendance à ce que chacun écrive son propre cadre?

Eugene: Il me semble que la guerre est déjà terminée.

Dmitry: Svelte vous envoie ses salutations!

Artyom: Non, eh bien, une personne sur deux n’écrit pas de framework, mais certains frameworks sont tournés périodiquement comme Svelte. Peut-être que quelque chose se déclenchera bientôt.

Michael: Ce n'est pas dû au fait qu'il ne s'agit pas simplement d'un autre cadre. Ils tirent parce qu'un principe fondamental est trouvé, et c'est une percée.

Oleg: La question est, quelles ont été les plus grandes percées de ces dernières années?

Dmitry: Souvenons-nous un peu de Farzad YousefZadeh . Il expliquera comment utiliser FSM en utilisant l'exemple de xstate dans la pratique. Ils commencent à prêter de plus en plus d'attention non seulement à la gestion de l'État, mais à la manière de le faire de manière plus systématique.

Par exemple, afin de pouvoir comprendre comment l'état va changer dans une application via des machines à états finis. Parce que chaque fois que nous les rencontrons, par exemple, un processus de chargement de données depuis le serveur est une machine à états directe.

Oleg: Ceci est un rapport sur la vérification formelle?

Dmitry: Non, il existe un outil qui vous permet de décrire les transitions de votre état sous la forme d'une machine à états et de la distribuer presque visuellement. À HolyJS 2019, Piter était l' un des auteurs ( David Khourshid ) d'une solution plutôt populaire dans ce créneau, qui vient de faire la bibliothèque xstate. Et Farzad va juste montrer comment utiliser cette bibliothèque dans les conditions les plus pratiques (c'est-à-dire avec un projet React). Il s'agit peut-être de grandes percées.

Et encore une fois, Guillermo Rauch . Maintenant, "le rendu côté serveur est un nouveau noir", comme on dit. Nous remontons aux racines et parlons beaucoup du rendu côté serveur. En général, nous essayons de mélanger autant que possible les approches de rendu - côté serveur et non côté serveur. Guillermo est un co-fondateur de ZEIT , un bureau qui écrit Next.js , qui est maintenant l'une des principales solutions pour les choses dynamiques sur React qui veulent rendre sur le serveur. En conséquence, le rapport promet d'être très intéressant du point de vue d'une vision très large de tout cela. Et Guillermo, bien sûr, vous pouvez poser des questions sur Next.js.

Artyom: Je voudrais ajouter que nous avons oublié la plus grande percée dans la communauté angulaire - c'est Ivy . Ils ont radicalement changé cette vue, c'était à l'intérieur du rendu. Et le fait est que les rapports sur Ivy sont essentiellement construits comme - une personne prend, raconte, montre des métriques: "Écoutez, c'était comme ça, maintenant c'est comme ça." Et le rapport Eliran Eliassy vient de l'autre côté, c'est-à-dire qu'il ne vous dira pas cela rapidement, mais pourquoi. Eliran est plus susceptible de monter à l'intérieur. Le rapport comparera la vue précédente, qui était présente dans Angular, et la vue actuelle, etc.

Eugene: Nos rapports sur Angular ont reproché qu'ils soient trop légers, rien d'intéressant. Et cette fois, nous avons décidé de faire un reportage pour ceux qui s'intéressent à Angular profondément et directement afin qu'il soit intéressant et hardcore.



Oleg: Avons-nous un autre rapport sur React?

Vasily: Nous avons un rapport, un atelier et les deux sur la performance dans React.

Oleg: Pourriez-vous donner plus de détails?

Basil: D'accord. En fait. En général, pourquoi me suis-je souvenu de l'atelier, car il existe plusieurs options pour optimiser les performances. Eh bien, tout le monde a dit que React est rapide, puis il s'est avéré que les gens en ont besoin encore plus rapidement, car on s'habitue rapidement au bien.

Et, en fait, Miguel Angel Duran Garcia va parler de la façon dont vous pouvez influencer la vitesse de réception du contenu par l'utilisateur, en utilisant différentes techniques de rendu. De plus, il n'y a que 4 équipements de base, mais en même temps ils peuvent encore être mélangés. Et il va parler dans quel cas quelle technique de rendu est préférable d'utiliser.

De plus, cela est donné par l'exemple de React, mais en fait c'est un framework agnostique, la même approche peut être appliquée à Angular, à n'importe quelle autre bibliothèque de rendu, juste pour la spécificité de React.

Et lui, en fait, raconte quelles quatre approches, donne des exemples avec des chiffres et montre un site de démonstration sur lequel toutes les approches sont mises en œuvre. C'est-à-dire qu'une personne peut entrer, cliquer sur les pages et comparer ses impressions du point de vue de l'utilisateur lorsque telle ou telle approche est utilisée.

Eh bien, le tout est lié à l'explication de la façon dont cela affecte le passage du rendu et ainsi de suite, mais en général, il ne dira pas comment monter dans les entrailles du cadre. Il vous expliquera comment activer quelque chose en regardant le rendu juste de l'autre côté.

En général, ce n'est pas un rapport profondément hardcore, il s'agit plutôt de la solution d'ingénierie aux problèmes standard. On peut rendre sur le serveur, cela affecte tel ou tel indicateur et l'utilisateur, lorsqu'il charge la page, la voit comme suit. Les chiffres, le premier rendu, la première livraison d'informations - le tout dans le temps.

Nous pouvons restituer des informations sur le client, nous pouvons utiliser le rendu uniquement la partie visible de l'écran. Il y a une explication dans quel cas quelle stratégie est préférable d'utiliser et quels outils peuvent être utilisés afin de ne pas basculer manuellement entre les stratégies.

Oleg: Nous devons également avoir quelque chose à propos de GraphQL.

Alexey: GraphQL entre maintenant dans la phase où tout le monde commence à l'utiliser et la première compréhension de comment et quoi faire et le premier râteau apparaissent. Pavel Chertorogov en parlera spécifiquement.

Dmitry: Pavel racontera sur de vrais exemples pratiques comment il a montré comment faire GraphQL sur des fragments correctement du point de vue du front. Lors du dernier HolyJS, il a parlé d'une manière générale, maintenant il va le dire à la fois du point de vue du front et du point de vue du back-up, et de la différence d'approche ici et là sur des cas pratiques réels et concrets.

Aleksey: C'est juste que l'expérience pratique s'est déjà accumulée dans la communauté. Nous ne sommes plus intéressés à savoir à quel point cela est bon, nous écouterons déjà les problèmes.



Oleg: Voyons quels rapports nous avons sur les navigateurs. Et si possible, dites-moi à quel point est-ce pertinent maintenant? Autrement dit, nous avons déjà parlé des moteurs JS, pourquoi les navigateurs sont-ils une catégorie distincte?

Artyom: Le problème ici est qu'il existe une certaine fonctionnalité qui ne s'applique pas directement aux moteurs qui exécutent JS. Une telle fonctionnalité, par exemple, est directement liée à l'analyse HTML, à l'affichage des styles, ou à ce qui se passera dans l'un des rapports (avec extensions) qui se trouvent quelque part à côté de ce cas.

Dmitry: Le navigateur lui-même est un écosystème dans lequel JS fait partie intégrante. Et JS doit également interagir avec l'environnement du navigateur, si nous parlons d'extinction, les outils de développement et d'autres choses, ainsi qu'avec le moteur de rendu, qui, comme nous le savons, vivent séparément.

Autrement dit, si nous parlons de Chrome - c'est Blink , et ainsi de suite. Prenons à tour de rôle - c'est la maison de l'API qui nous vient, et un tas de toutes sortes de choses sur le navigateur, et des travailleurs spécifiques, le rendu lui-même. De quoi Prashant Palikhe va parler .

Artyom: Ici, le sel est le suivant: si nous avions des fondamentaux de Vitaly Bragilevsky, Nicolas Belmonte, Mathieu Henri, concernant en principe les pratiques d'ingénierie, alors Prashant parlera de la base, qui est spécifiquement liée à la partie frontale. Il révélera en détail la question que la plupart des entreprises décentes posent lors de l'entretien: que se passe-t-il lorsque votre page commence à se charger. Ce qui se passe dans le navigateur sous le creux. Ici, il sera révélé à partir de la négociation TCP et de l'échange de paquets TLS à ce qui se passe déjà lors de l'analyse HTML, lors du comptage des styles, lors de la création de blocs qui seront affichés dans le navigateur, lors de la superposition de styles sur des blocs déjà construits, et ce qui se passera pendant l'interaction utilisateur avec un navigateur. C'est-à-dire, quelles étapes votre navigateur va répéter pour changer le contenu à l'intérieur.

Ce sera la question fondamentale que le front-end pose: "Que se passe-t-il exactement dans le navigateur lorsque votre application est rendue?"

Dmitry: Et Nikita Mostovoi parlera des problèmes qui vous attendent si vous utilisez simplement un navigateur ou développez des sites Web, c'est-à-dire parlera de problèmes d'extension.

C'est généralement une douleur que Google a publiée en ouvrant une boîte noire, en créant des extensions sans examen, et les politiques de Google indiquent explicitement que les utilisateurs décident de les installer ou non.

Et les extensions ont accès, pour le moins, à presque tout dans votre navigateur, et en principe, elles peuvent directement entrer dans votre banque Internet et tout casser. Vous prenez, transférez de l'argent à maman, et ils partent au mieux à papa.

Eugene: En fait, ils peuvent absolument tout faire avec votre page.

Dmitry: Ils peuvent être intégrés dans la page, lors de l'exécution, et tout récemment, Google a encore commencé à le couper un peu. À certains moments, ils pourraient également être intégrés au niveau du réseau.

Oleg: Oui, tout ce scandale avec des bloqueurs de publicités.

Dmitry: Oui, et pas seulement eux. Les bloqueurs sont la partie la plus gentille des extensions. Et Nikita avait juste beaucoup d'expérience avec ces choses. J'ai eu de l'expérience en essayant de les casser à travers les extensions, car cela fonctionne dans HeadHunter, et il y a des informations importantes pour le marché. Et il vous dira comment vivre avec.

Systèmes de conception

Oleg: Cool. La catégorie suivante est celle des systèmes de conception!

Eugene: Permettez-moi de parler du système de conception. Lorsque vous n'avez que trois frontaux, vous pouvez faire ce que vous voulez. Mais quand il y a plus de développeurs, il est clair que vous devez trouver un moyen pour les personnes dans différentes parties de l'entreprise - les fournisseurs frontaux et les concepteurs, et tout le monde de parler le même langage. Et pour qu'il n'y ait pas tel que vous ayez un bouton ici, un autre ici, une couleur ici, d'autres là-bas - ça ne marche pas comme ça.

Par conséquent, absolument toutes les grandes entreprises qui développent des produits sur le Web ont un système de conception. À ce sujet, nous aurons deux rapports.

Alexey: Il y aura Zar Zakharov et Alexander Kamenyar . Il existe un tel outil pour les concepteurs appelé Figma . Cela fonctionne réellement en ligne, il expose l'API HTTP, mais pas le point. Les gars ont donc compris comment prendre et intégrer l'outil à l'aide de cette API afin de réaliser une intégration transparente entre la conception et la mise en œuvre, en particulier la mise en œuvre sur React. Il s'avère qu'en plus des couleurs, nous pouvons décharger, par exemple, les tailles, les distances et garder tout cela frais. Nous n'avons pas besoin de synchroniser la conception avec l'implémentation, nous essayons de le faire en mode automatique, dans la mesure du possible.

Eugene: Nous aurons également Andrey Okonechnikov , un conférencier bien connu qui parlera également de la conception du système, mais il n'y a pas encore de détails sur son rapport.

Dmitry: Andrey a sa propre entreprise pour les systèmes de conception, et il expliquera comment les construire dans leur ensemble sur la base de l'expérience de la construction de nombreux systèmes dans différentes entreprises.

Eugene: En général, tout concerne les systèmes de conception, notre prochaine section est consacrée aux langages de programmation. Nous avons deux intervenants.

Oleg: Qu'advient-il des langages de programmation, il y en a beaucoup, pour ainsi dire.

Eugene: Que faites-vous!

Oleg: Eh bien, vous pouvez commencer à lister: Kotlin.js, Clojure, Elm, ReasonML ...

Michael: C'est à peu près ReasonML et il y aura un rapport. Et ça s'appelle " ReasonML for sceptics " par Eric Schaefer . Il y avait déjà un nom similaire, ClojureScript pour les sceptiques , dont une autre personne a parlé. Eric vendra ReasonML à des personnes qui ne croient pas à la technologie ReasonML.

Il n'a pas simplement essayé le didacticiel avec "Hello World" et est venu parler de ce que Reason est de cool, des fonctions propres et tout ça. Il le fait professionnellement. Il a écrit des outils avec cette pile pour Google, pour Red Bull et d'autres grandes entreprises du secteur de la consommation. Cela contestera et nivellera en quelque sorte l'argument selon lequel dans ReasonML il y a peu de solutions qui peuvent être utilisées, et naturellement, cela montrera les avantages du langage.

Je n'ai pas supervisé ce rapport, et je ne suis pas sûr, mais il montrera au moins comment faire de React avec GraphQL des amis avec ReasonML. Étant donné que le nouveau React tombe parfaitement sous ReasonML. Eh bien et oui, une petite nuance que ReasonML développe Facebook et utilise en interne.

: , , , , , , « , , Hello World», , React- ReasonML. ReasonML, . .

: — Nicolò Ribaudo . core team member Babel , Babel, proposal, , , , - .

, Babel, , , , - proposal. , 20 . ! .

: , WebAssembly.

, WebAssembly - . , . - , JavaScript , - . . Emscripten ? ? Yandex-. .

: CSS. , definition syntax, , , Houdini . CSS , CCS. CSSTree . CSS , .

Insiders

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

: , , , .

: Romulo Cintra.

: Romulo Cintra . : « TC39 ?», — , TC39 , . , - . - , , JS , , , , -.

— , , , , , , .

, , . , TC39 , , , , .

, namespace Intl , , , ( ). , , . , , , , , , , — , .

, , — . , .

, Romulo TC39 , TC39 MessageFormat Working Group . , , , , , .

, - - stage — , , , , JS , .

, , , . - Fluent , , , Node.js — . , .

: -, , .



: ?

: -, . : JavaScript . , , , , State of JavaScript . TypeScript, , . : , TypeScript TypeError.

Pourquoi? , , -, TypeScript , , , . — , ahead of time. — .

, , , , Cannot read property of undefined , , . , .

: runtime-, runtime- . , TypeScript, - runtime . , , — . .

, - runtime, type guards, 15 if-, , property response. , , , , . , .

: Anna Herlihy .

: Anna ongoose MongoDB, . , ORM Mongo, . !

: , ?

: - . , , , , , . , .

, . , , , , , .

: ?

: : Guillermo Rauch, .

: , HolyJS — lightning talks. , lightning talk . lightning talk TC39 Aki Rose Braun, , , . .

, — . — , , , , , , MC. . , , 100%, , .

— BOF- . , . , . , , , - , .

: HolyJS Honeypot Ember . . Honeypot, , GraphQL. - GraphQL.

: , , -, FrontSpot . MC — , .

: TCXX , TC39 . TC39 Daniel Ehrenberg . , TC39, , . .

HolyJS 2019 Moscow 8-9 . , .