8-9 ноября в Москве состоится HolyJS 2019 Moscow — большая конференция для JavaScript-разработчиков. Раньше мы публиковали на Хабре длинные списки с формальным описанием докладов, но кажется, всё это и так можно прочитать на сайте.
Вместо этого мы собрали почти полный состав программного комитета и обсудили самые важные вещи: что сейчас интересного происходит в мире JavaScript, браузерного фронтенда, серверного бэкенда и в других областях, что про это стоит послушать и как это влияет на программу конференции. Добавили кучу интересных ссылок и красивых фотографий. Заходите под кат, располагайтесь, мы начинаем.
В разговоре участвуют:
- Евгений Кот и Артём Кобзарь из Wrike;
- Таня Денисюк и Дмитрий Махнёв из JUG Ru Group;
- Алексей Золотых из Infobip;
- Михаил Башуров из EPAM;
- Михаил Полубояринов из Health Samurai;
- Василий Ванчук;
- Интервью ведет Олег Чирухин.
Общая картина
Олег: Расскажите о программе конференции. Как темы появились, как они устроены, если в них есть какая-то внутренняя логика и почему их так много.
Дмитрий: Каждый раз, когда мы делаем конференцию, нам нужно выбирать некоторое основное направление и опираться на фидбэки. Основное направление — это обычно то, что сейчас сверхактуально, что-то очень значимое. Если взять прошлый HolyJS, мы специально пытались пригласить Ryan Dahl, потому что Deno был свежачком и хотелось услышать что-то о нём в России. Ну и плюс Ryan Dahl.
В этот раз мы особо сфокусировались на самом языке, потому что сейчас TC39 начинает работать всё более и более активно и прозрачно, и мы видим, что аудитории это интересно. Например, Telegram-канал Сергея Рубанова и Романа Дворнова читает огромное количество людей.
Во-первых, нам показалось, что это интересная тема. Во-вторых, когда мы начали ресёрчить состав TC39, мы обнаружили, что там находится огромное количество интересных людей, которые работают в интересных компаниях — Google, PayPal, Mozilla, Bloomberg. Эти люди ещё иногда делают JavaScript-движки. Очень хотелось сконцентрироваться на этих вещах.
Плюс мы всегда имеем пул заявок, в этот раз он был, как обычно: больше 200 с хорошим таким конкурсом на место, поэтому с этих заявок мы стараемся собирать программу достаточно разнообразную, чтобы открыть для слушателей что-то новое. Мы не стали в этот раз как-то сильно напирать на экспериментальные доклады, они были сами собой. Мы в этот раз взглянули в сторону soft skills, потому что их просят и считают важными.
Видно, что аудитория растёт, растёт и в компаниях, и в коммуникациях, и в управлении. Поэтому soft skills для нас важная часть. Если начать с того, что было первой целью — это был TC39. Нам удалось найти несколько делегатов TC39. И среди докладчиков будет ещё один приглашённый эксперт.
TC39 состоит из делегатов — это люди, представляющие конкретные компании, их больше 100. Ещё там есть очень небольшое количество приглашённых экспертов, около 20 человек. Управлять и координировать TC39 пытаются 3 человека, это сопредседатели комитета, 2 из них у нас будут.
TC39, фундаментальные и инсайдерские доклады
Олег: Чисто практически, как TC39 влияет на жизнь обычного человека?
Дмитрий: Очень просто! TC39 формирует язык — ваш самый базовый инструмент, который исполняется JS-движками.
Представители движков JavaScriptCore, который находится в Safai и iOS, и SpiderMonkey, который находится в Firefox, также будут выступать с докладами.
Если сделать шаг дальше и сказать, что TC39, конечно, развивает язык, но все пользуются Babel. У нас будет разработчик из Babel core team: Nicolò Ribaudo, который пилит достаточно актуальные и сложные фичи, например, такие как Optional Chaining и Nullish Coalescing. Так мы закрываем основу языка.
Артём: У нас ещё будет фундаментальный доклад в принципе по теории языков от человека, который находится в академической среде — Виталий Брагилевский.
Дмитрий: Также нам пришло достаточно много заявок, из которых мы старались выбирать актуальные темы. Мы помним, что у нас всегда просят Node.js, поэтому мы с трепетом относимся к выбору докладов по Node.js. В этот раз там много всего интересного.
Более того, мы сейчас работаем над тем, чтобы сделать Node.js Code + Learn, чтобы он был на рядом с конференцией. Как обычно, с этим нам помогают коллеги из PiterJS.
Пришло очень много разных докладов на разные темы. Отдельно из них можно выделить что-то о фреймворках, потому что про это очень сильно просят. Упор сделан на React и Angular. Нам наконец-то удалось найти ангулярный доклад про Angular Ivy, про который, мне кажется, интересно будет послушать всем.
А еще есть специфическая категория, назовём её «инсайд», куда попали доклады, которые сложно к чему-либо отнести. Ребята, которые нас очень сильно впечатлили своими мыслями.
Таня: Ещё один важный момент. У нас всегда просят практику. Помимо того, что сами доклады содержат практические кейсы, мы ещё это добиваем двумя воркшопами, которые будут проводиться в каждый из дней. Это тоже важно отметить, потому что именно посетители смогут не только чему-то научиться, но и попробовав это вживую, и им с этим помогут ребята, которые будут вести воркшопы. Ребята тоже небезызвестные и в комьюнити, и как специалисты.
Воркшопы
Дмитрий: Хотелось бы обратить внимание на темы воркшопов, потому что мы стараемся исходить из того, что первична тема, а уже потом ищем интересных людей.
Первая тема у нас в этот раз очень важная — это Node.js для людей с фронтенда. Если вы хотите потихоньку погружаться в бэкенд, этот воркшоп для вас. Андрей Мелихов расскажет, какие основные грабли там есть и как начинать.
Вторая, самая больная и любимая тема — это оптимизация React-приложений. Про это расскажет Иван Акулов, у которого есть своя консалтинговая компания по теме производительности. Ивана мы заметили, когда он вёл jsunderhood, он просто порвал наше восприятие потоком информации, после чего мы не могли его не пригласить.
Олег: Как проходят воркшопы?
Дмитрий: Воркшопы проходят, грубо говоря, четвёртым потоком. Один воркшоп в день конференции. Они входят в стоимость посещения конференции, вы просто приходите, у вас есть опция их посетить. Обычно это во второй половине дня в течение двух слотов конференции, то есть около 2,5 часов с небольшим перерывом.
Олег: Докладчик, который его ведёт, работает индивидуально или на группу?
Дмитрий: Он работает на группу, но ему может помогать его куратор. Этот формат новый для нас. Мы проводили только два воркшопа (по Svelte и по Webpack) один раз в этом году в Питере, поэтому пока точно сказать о форме сложно. Точно можно сказать, что там будет огромное количество информации и ребята точно ответят на большое количество вопросов.
А вот как кодить вместе с ними или не кодить… конечно, мы к этому будем стремиться, но здесь ещё вследствие того, что и мы зелёные, и времени не очень много на сам воркшоп, и в принципе воркшопы у нас не очень распространены… Это новая практика на уровне, я бы даже сказал, страны, а не конференций. Они редко бывают на конференциях нашей специфики. Мы учимся. Давайте оценим это на конференции.
Я думаю, что ребята сильные, у них есть опыт. Если мы говорим про Андрея Мелихова, он руководит огромной командой в Яндекс.Деньгах. А если мы говорим про Ивана Акулова, у него есть опыт воркшопов, насколько мне известно, немаленький.
Таня: Иван этим и занимается, это часть его рабочей деятельности. Ещё вопрос: почему оптимизация React — это так важно?
Дмитрий: Оптимизация React важна, потому что React становится стандартом в индустрии де-факто, но по нему всегда возникает куча вопросов, куча споров, куча вкусовщины. Хотелось бы собрать некоторый осознанный кусок информации, который был бы хорошо подготовлен и проверен перед воркшопом и дан человеком с авторитетным мнением, чтобы улучшить ваши рабочие процессы, в том числе на ревью.
В React есть наборы хороших практик, но даже по собственному опыту скажу, что если ты только начинаешь в него заходить, их не хватает. Дать ещё один авторитетный источник в этом плане выглядит хорошо.
Артём: Плюс как минимум производительность в React — это нашумевшая тема, например, недавно было issue по performance, которое переводили все кому не лень.
React в принципе — это закрытая коробка, на него можно влиять через набор практик. Надо понимать и внутренности React, чтобы создавать эти практики, и то, как эти внутренности взаимодействуют с отдельными движками. Допустим, в issue, которое недавно нашумело, штука в том, что только в Chrome и Chrome based-браузерах была эта проблема. Её сидели и искали ребята из V8.
Дмитрий: Помимо просто практик и «верьте мне, потому что я так сказал», если зайти и посмотреть описание воркшопа Ивана, у него там очень много про то, как профилировать React и ререндеры, как профилировать приложения в принципе и даже как пытаться это делать в продакшене.
Олег: А мы сейчас про один воркшоп говорим или сразу про два?
Алексей: Про оба. Первый — про серверную часть, второй про фронтенд. На это есть запрос.
Дмитрий: И что важно, это запрос двусторонний. Запрос есть и со стороны комьюнити, потому что фронтендеры начинают глубже погружаться в бэк на Node.js, и со стороны компаний, которые пишут на Node.js. Андрей в своем подкасте неоднократно упоминал, что коллеги, пришедшие с фронтенда, делают очень базовые ошибки при проектировании серверных приложений. Мне кажется, Андрей даже как работодатель заинтересован, чтобы коллеги лучше в этом разобрались.
Олег: А спикеры вообще между собой общаются, у них строятся связи и запросы между собой? Учитываются ли мнения участников?
Таня: Я помню, как ребята из Chrome DevTools пообщались с Ryan Dahl прямо на конференции и потом учли всё это.
Артём: У нас будет доклад от Ujjwal Sharma из Node.js-команды, его доклад обсуждался на прошлой HolyJS в Питере. Сначала мы с ним сидели и общались, вбросили тему, потом он подошёл к Ryan Dahl, обсудил и так получился доклад, который он рассказывает на этой HolyJS.
Дмитрий: Думаю, что спикеры учитывают то, что происходит на конференции и в дискуссионных зонах. Я бы сделал вывод об этом просто из объема времени, которое тратится в дискуссионных зонах. Например, Илью Климова там могут держать часа полтора, Michel Weststrate вышел через такое же время. И в целом, спикеры проводят там около часа.
Расширение кругозора
Олег: Зачастую, когда собирается программа, у тебя большая часть докладов о том, чего хочет аудитория, но есть и специальные разделы, которые никто не ждал, а они — есть. Которые существуют для улучшения эрудиции. Чтобы показать аудитории то, что обычно никто не слышал. Такое есть в программе это HolyJS?
Артём: Не знаю, мне кажется, Виталий Брагилевский — это такой пример. На JS-конференции рассказывать про теорию языков программирования, про то, как на JS сначала строишь машину Тьюринга, потом интерпретатор для лямбда-исчисления и потом сначала выражаешь машину тьюринга из лямбда-исчисления, а потом наоборот — мне кажется, это довольно необычный доклад для JS-конференции. Но тем не менее, он устраняет определенную инженерную неграмотность с точки зрения теоретической информатики.
Дмитрий: Также сразу можно дополнить Артёма наличием в программе Lucas da Costa.
Алексей: Он все разы занимал верхние строчки рейтингов и в целом это не так просто — рассказывать сложные штуки простым языком, тем более теоретические.
Дмитрий: В первый раз он рассказывал, как с помощью функции сделать всё, включая boolean, математику и прочее, а второй раз про Y-комбинаторы. То есть прямого запроса «расскажите нам про Y-комбинаторы» мы не получаем. Но если к нам приходят с интересной темой, и мы понимаем, что она может быть очень полезна, мы её даём. То есть если во время прочтения у вас возник вопрос «А зачем мне Y-комбинаторы», рекомендуем посмотреть доклад.
Артём: Я добавлю второй доклад от моего друга Дмитрия Пацуры, который будет опять-таки про то, можно ли компилировать JS. Первое — не каждый в комьюнити такой вопрос задает: можно ли интерпретируемый язык просто скомпилировать в нечто, и исполнять.
Но тем не менее человек задался вопросом, сделал компилятор, чтобы доказать или опровергнуть эту гипотезу и, собственно, будет рассказывать, почему современное устройство интерпретатора, которое на самом деле под полой JIT-компилятор, такое как есть. Почему они устроены именно так, как устроены, и почему мы не можем именно сам JS в чистом виде брать и компилировать в какой-нибудь бинарник.
Дмитрий: Если вам будет не хватать доклада про V8, то надо смело идти к Дмитрию, потому что во многом он будет делать его вокруг V8 и прямо показывать, как делать байткод V8 и как с ним взаимодействовать. То есть он хочет дать информацию по очень интересным инструментам вокруг всего этого.
Наверно, можно выделить доклад про образование. Никто никогда не спрашивает: «Как мне образовываться?», потому как-то живут, да и курсов куча. На тему образования будет доклад Дмитрия Волошина.
Михаил: Ещё из необычных — Anna Herlihy. Это прямо топовый доклад! Коллеги додумались взять и написать какой-то фронтенд для преобразования любого языка в MongoDB-запрос. При том, что это может быть не только существующий язык программирования, а и визуальные схемы. Может прийти какой-то менеджер, который не лезет в код, а работает с бизнес-логикой. Накидал блок-схемы, а ему сделался запрос в базу MongoDB.
Евгений: Anna работала с Mongoose для MongoDB, и за годы выстраивания ORM на разных языках она поднаторела, чтобы сделать такую систему.
Дмитрий: Ну и вишенкой на торте будут коллеги из TC39. Никто не просил как-то сильно, но мы делаем с ними много всего, включая TC39 Panel (примеры данной активности). На данный момент есть подтверждения от двух делегатов, двух сопредседателей и двух приглашённых экспертов. Вы уже можете задать им вопросы для обсуждения.
Также одна из сопредседателей, Aki Rose Braun будет открывать секцию lightning talks с докладом о том, как в TC39 работают с предложениями в язык. Можно будет не только послушать её, но подойти и задать вопросы. Я очень рекомендую ловить сопредседателей, т.к. они очень активны, и они как раз во многом занимаются коммуникациями между TC39 и комьюнити.
Node.js
Олег: Давайте перейдём к темам докладов. Например, что происходит в мире Node.js? И как это связано с докладами?
Артём: Сейчас в Node.js постепенно переходит тенденция к взрослым фреймворкам. Что я подразумеваю под взрослыми фреймворками — те, которые дают достаточную абстракцию, чтобы мы манипулировали непосредственно не какими-то элементами самого сервера вроде route, request, response и так далее, а непосредственно объектами доменной области.
И из-за этого сейчас родился и очень «на хайпе» NestJS, который походит на слишком классический enterprise с аннотациями, с классами. Такое дитя Spring и ASP.NET на минималках. И получается так, что на HolyJS 2018 Moscow у нас вообще был создатель этого фреймворка (Kamil Mysliwiec), но рассказывал он в основном о внутренностях. А на этот раз у нас будет более практический доклад, который делает Александра Калинина.
В чем его практическая ценность? В том, что большая часть Node.js-приложений на сегодняшний день написаны на довольно популярном Express, который занимал очень большую нишу в свое время, и сейчас, я думаю, тоже что-то занимает. Он использует старый способ манипуляции низкоуровневыми абстракциями — request, response, сервер, сокет, порт и так далее.
Александра расскажет о том, как они переводили своё Express-приложение на NestJS. Более того, она расскажет, почему это стоит делать, то есть, какие плюсы, причем для разных аудиторий, как для разработчика, так и для менеджера. Как компании это продать как заказчику. И они это сделали за две недели. При том, что приложение было средней сложности. По моему, там звучала число в 80 часов.
Дмитрий: Дальше по Node.js, сейчас понятно, что все еще продолжают смотреть и ждать Deno, потому что он не может не вызывать интерес. Во-первых, потому что там TypeScript, во вторых, Ryan Dahl сказал, что «я сейчас сделаю круто».
И Ujjwal Sharma будет рассматривать кейсы, в каких случаях вам лучше брать Deno, а в каких лучше брать Node.js в текущем состоянии. Он будет исследовать их event loop’ы, потому что они на самом деле разные, выдаст по этому поводу некоторое исследование, чтобы вы могли понимать, на каких практических задачах уже можете взять и потрогать Deno. Это, конечно же, тоже очень интересно. Потому что на Node.js сейчас очень много пишут на TypeScript.
Олег: Слушай, я подписан на гитхабе на Deno, коммиты читаю, и возникает ощущение, что там очень много всяких багов. Насколько этим вообще можно пользоваться, и имеет ли смысл об этом говорить?
Дмитрий: Ну вот как раз про это нам, я думаю, тоже скажет Ujjwal. Потому что он как раз должен исследовать это в рамках практических задач. Грубо говоря, если вам нужно сделать просто proxy API, то нужно вот это, а если вам нужно делать какой-нибудь server-side рендеринг, то вот это. То есть он должен отталкиваться в своем докладе от конкретных практических вещей, что ты как раз и спрашиваешь. И, грубо говоря, если там будут какие-то проблемы с event loop, например, на большом количестве запросов, то Ujjwal, мне кажется, как раз должен найти и очертить такие области, где его можно брать, с учетом багов и не багов.
Может быть он наоборот скажет, что вообще нельзя, но потенциально это будет интересно для будущих задач. Это такое исследование, которое сейчас идет. Почему я не могу сказать про финально — потому что, мне кажется, даже в последние дни перед конференцией что-то может добавляться. Потому что и Deno в активной разработке, и Ujjwal держит связь с Ryan — они прямо в WhatsApp переписываются. Ujjwal также является core member Node.js, и там тоже держит руку на пульсе, поэтому там тоже могут быть сверх-свежие апдейты.
Артём: Он core member V8, Electron, и я не знаю, где его нет среди основополагающих проектов.
Дмитрий: Ему 21 год, у него очень много энергии, поэтому мы надеемся на очень интересное исследование, которое окажется интересным сообществу.
Михаил: Опять-таки, третья и до сих пор популярная тема — быстродействие Node.js-приложения. И эту тему будет покрывать Андрей Пeчкуров. В своём докладе он показывает, как на реальном продукте, которым пользуется уже достаточно много людей, они разбирались с производительностью. Причем именно не в задачах относительно формочек, а в чем-то серьезном.
Он будет показывать, как находить проблемы, как их устранять, где они у них были. И с ним можно будет пообщаться по поводу практических моментов.
Олег: По сути этот доклад может быть интересен людям, которые считают себя 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
Олег: Давайте разбирать категорию фундаментальных докладов. Что такое вообще fundamental, потому что слово какое-то расплывчатое, и почему это важно?
Артём: Fundamental — это те темы, которые являются цементом для всех практически знаний. То есть это та база теоретическая, на которой строится большинство инструментов и решений вообще везде. Это та академическая база, которая необходима для понимания практики, понимания, почему практика сформировалась именно так.
Первым же докладом у нас идёт Виталий Брагилевский. Мало того, что он переводит книги по Haskell, мало того, что он пишет книгу по Haskell, мало того, что он является членом двух комитетов по стандартизации (один Haskell 2020, другой Haskell Glasgow Compiler), он еще и преподаватель, на текущий момент в СПбГУ. На сегодняшний день у него самый популярный русскоязычный курс по теории категорий. В принципе он делает хорошие курсы.
Он откликнулся на наши просьбы выступить у нас и решил зайти с нестандартной темой, которая раскрывает базис вычислений, того, как вообще строятся вычисления в любом языке, в любом инструменте, который что-то исполняет. Он будет нам рассказывать и про машину тьюринга, и про лямбда-исчисление, и про P-класс, и про NP-класс, и про NP-полноту.
То есть весь тот необходимый джентльменский набор в теоретической информатике, который, как ему кажется, должен присутствовать у человека, который себя называет инженером и претендует на экспертизу в области практической информатики.
Евгений: Lucas da Costa опять продолжает свою победную серию. В этот раз он решил замахнуться на тесты. Причём не просто тесты, а тесты на типы. Как это делать и с теоретической, и с практической точки зрения.
Дмитрий: И что важно, Лукаш действительно имеет полное право говорить об этом, потому что он был мейнтейнером таких известных библиотек для тестирования, как Chai.js и Sinon.js.
Евгений: Он рассказывает про Jest, про снапшоты. В прошлый раз в ряде отзывов на доклады Lucas говорили, что у него слишком много теории. И он внял просьбам, но решил сделать в своём духе: и теорию оставить, и практику добавить. Поэтому интересно будет и тем, и другим.
Олег: А Mathieu Henri?
Михаил: Ну, у него, собственно, доклад немного попроще. И если с первого взгляда смотреть, то там стандартная история. Просто большой проект, где куча зависимостей между кодом, компоненты шарятся между разными проектами. И эти компоненты нужно тестировать, чтобы при добавлении изменений в один компонент у тебя ничего не ломалось в каких-то других приложениях.
Из интересного здесь то, что это проект Microsoft. И, соответственно, у них очень большая аудитория и они заточены под большое количество браузеров и, в принципе, клиентов. Они одни из тех товарищей, которые, наверное, будут Internet Explorer 11 поддерживать до последнего, плюс им нужно заботиться о мобильном трафике, и так далее.
И, соответственно, у них стояла задача — как максимально быстро находить проблемы в случае, если ты поменял какой-то компонент, и он зааффектил все остальные приложения.
Собственно, Mathieu будет рассказывать про то, как он написал свой собственный фреймворк, позволяющий запускать только те приложения, которые аффектятся с теми компонентами, которые менялись, и делать это с помощью минимальной нагрузки на систему.
Потому что понятно, что запустить несколько клиентов и кучу виртуальных машин под каждую систему про каждый браузер не проблема, но когда таких изменений много, встаёт вопрос о том, что нагрузка будет просто класть CI и pipeline, и это то, над чем он работал.
Он будет рассказывать, как он организовывал CI и какие там есть фишки по, например визуальным diff-ам, и вообще какую систему, какой framework он нарисовал для того, чтобы решать задачи в рамках Microsoft.
Самое интересное там — это именно опыт больших компаний, потому что на это тоже был запрос, чтобы крупные компании делились тем, как у них все это устроено. В остальном задача плюс-минус типичная, но не типично то, в каких объемах она решается.
Олег: Окей. Переходим к Nicolas Belmonte.
Артём: Николас работает в Mapbox, компании, которая делает карты. Доклад будет рассказывать про те алгоритмы, опять-таки, про ту фундаментальную базу, которая лежит за построением карт.
Про отрисовку в 3D. Про отрисовку конкретных полигонов, про расчеты, про локацию, координаты и все вещи, которые являются базой при построении такого вида приложений.
Естественно, там будут скорее всего алгоритмы на графах, которые опять-таки фундаментальные для построения карт, для нахождения пути на этих графах и так далее.
Дмитрий: Вы могли видеть некоторые подобные доклады, с моей точки зрения на одной из когда-то лучших конференции в СНГ по JS, а именно на FDC, от Владимира Агафонкина. Владимир как раз работает в Mapbox и занимается картами со стороны JS.
А Nicolas отвечает за визуализацию этих карт с точки зрения и C++, и iOS, и Android, и веба тоже. То есть: он как бы на это все смотрит, наверно, на максимально верхнем уровне с точки зрения всего Mapbox, что, конечно, не может не вызывать интерес.
Олег: Кстати, вот этот Mapbox — это что-то известное или очень локальное?
Артём: Насколько я знаю, с точки зрения цены, по-моему, третье решение самое популярное среди карт, я могу ошибиться, но что-то около этих чисел.
Олег: Повторю, что он из директора Uber ушёл в Mapbox, просто так из Uber не уходят.
Дмитрий: Mapbox — это очень серьезная компания, которая на данный момент должна быть хорошо известна среднестатистическому JS-разработчику.
Frameworks
Олег: Следующий раздел — фреймворки. Самый жирный, наверное.
Евгений: Самый любимый, наверное. «Фреймворки. Фреймворки никогда не меняются».
Олег: А сохраняется тенденция, что каждый должен написать свой собственный фреймворк?
Евгений: Мне кажется, что война уже закончилась.
Дмитрий: Svelte передает тебе привет!
Артём: Нет, ну как, каждый второй не пишет фреймворк, но периодически выстреливают какие-то фреймворки как по типу Svelte. Может, что-то в ближайшее время выстрелит.
Михаил: Выстрелит не из-за того, что это не очередной какой-то фреймворк. Они выстреливают из-за того, что найден какой-то фундаментальный принцип, и это прорыв.
Олег: Вопрос, какие самые большие прорывы были последних лет?
Дмитрий: Давайте немного вспомни про Farzad YousefZadeh. Он будет рассказывать про то, как использовать FSM на примере xstate на практике. Все больше и больше внимания начинают обращать не просто на управление состоянием, а на то, как делать это более системно.
Например, чтобы можно было через конечные машины состояний понять, как будет меняться какое-то состояние в приложении. Потому что каждый раз с ними сталкиваемся, например, какой-нибудь процесс загрузки данных с сервера — это вот прям машина состояний.
Олег: Это доклад о формальной верификации?
Дмитрий: Нет, там инструмент, который позволяет описать переходы вашего состояния в виде машины состояний и чуть ли не визуально это накидать. На HolyJS 2019 Piter был один из авторов (David Khourshid) достаточно популярного решения в этой нише, который как раз сделал библиотеку xstate. И вот Farzad как раз будет показывать, как в максимально практических условиях (т.е. с React проектом) эту библиотеку использовать. Наверно, это из больших прорывов.
И опять же, Guillermo Rauch. Сейчас «server-side render is new black», как говорится. Мы возвращаемся к корням и очень много говорим про server-side рендеринг. И вообще подходы к рендерингу пытаемся максимально миксовать — и server-side, и не server-side. Guillermo является сооснователем ZEIT, конторы, которая пишет Next.js, который является сейчас одним из основных решений для динамических вещей на React, которые хотят рендериться на сервере. Соответственно, доклад обещает быть весьма интересным с точки зрения очень обширного взгляда на это все. И Guillermo, конечно, можно будет позадавать вопросы про Next.js.
Артём: Я бы хотел добавить, что мы забыли самый большой прорыв в Angular-сообществе — это Ivy. Они кардинально поменяли то представление, было внутри рендеринга. И штука в том, что доклады про Ivy в основном строятся как — человек берёт, рассказывает, показывает метрики: «Смотрите, раньше было вот так, а сейчас вот так». А доклад Eliran Eliassy заходит с другой стороны, то есть будет рассказывать не что быстро, а почему. Eliran, скорее всего, больше полезет во внутренности. В докладе будет сравнение предыдущего представления, которое присутствовало в Angular, и текущего, и так далее.
Евгений: Наши доклады про Angular упрекали, что они слишком лайтовые, ничего интересного. И в этот раз мы решили сделать доклад для тех, кто интересуется Angular глубоко и прямо чтобы было интересно и хардкорно.
Олег: У нас есть ещё доклад по React?
Василий: У нас есть и доклад, и воркшоп, и оба про performance в React.
Олег: Можно подробнее?
Василий: Окей. Собственно. В общем, я почему вспомнил workshop, потому что есть несколько вариантов того, как можно оптимизировать производительность. Ну, то есть все говорили, что React быстрый, потом оказалось, что людям нужно еще быстрее, потому что к хорошему привыкаешь быстро.
И, собственно, Miguel Angel Duran Garcia собирается рассказывать про то, как можно влиять на скорость получения контента пользователем, используя разные техники рендеринга. Причем там базово всего 4 техники, но при этом их можно еще миксовать. И он собирается рассказывать про то, в каком случае какую технику рендеринга лучше использовать.
Причем это приводится на примере React, но по факту это framework-агностик, этот же подход можно применить к Angular, к любой другой библиотеке рендеринга, просто для конкретики взят React.
И он, собственно, рассказывает, какие четыре подхода, приводит примеры с цифрами и показывает демо-сайт, на котором все подходы реализованы. То есть человек может зайти, покликать по страничкам и сравнить, какие у него с точки зрения пользователя возникают впечатления, когда используется тот или иной подход.
Ну и все это дело завязано на объяснении, каким образом это влияет на rendering pass-ы и так далее, но в целом он не будет рассказывать, как лезть в недра фреймворка. Он будет рассказывать, как можно что-то активизировать, посмотрев на рендеринг просто с другой стороны.
В целом, это не глубоко хардкорный доклад, он больше про инженерное решение стандартных проблем. Мы можем рендерить на сервере, это влияет на такие-то показатели и пользователь, когда загружает страницу, видит это следующим образом. Цифры, первый рендеринг, первое донесение информации — все по таймингу.
Мы можем рендерить информацию на клиенте, можем использовать рендеринг только видимой части экрана. Там объяснение, в каком случае какую стратегию лучше использовать и какие инструменты можно использовать для того, чтобы не реализовывать переключение между стратегиями вручную.
Олег: Ещё у нас должно быть что-то про GraphQL.
Алексей: GraphQL сейчас входит в фазу, что все начинают им пользоваться и появляется первое понимание того, как и что делать, и первые грабли. О них Павел Черторогов конкретно и расскажет.
Дмитрий: Павел расскажет на реальных практических примерах, как он показывал, как правильно с точки зрения фронта делать GraphQL на фрагментах. На прошлой HolyJS он рассказывал в общем виде, сейчас он расскажет это и с точки зрения фронта, и с точки зрения бэка, и про разницу подходов и там, и там на реальных и конкретных практических кейсах.
Алексей: Просто уже накопился в сообществе практический опыт. Нам уже не интересно слушать про то, как это все хорошо, будем слушать уже про проблемы.
Олег: Давайте посмотрим, какие у нас есть доклады про браузеры. И если можно, расскажите, насколько это вообще актуально сейчас? То есть, мы уже поговорили о JS-движках, почему браузеры — это отдельная категория?
Артём: Тут штука в том, что есть определенная функциональность, которая не касается непосредственно движков, которые исполняют JS. Такая функциональность, допустим, связана непосредственно с парсингом HTML, или с отображением стилей, или что будет в одном из докладов (с extension-ами), которые лежат где-то рядом с этим делом.
Дмитрий: Браузер сам по себе является некоторой экосистемой, в которой JS — это некоторая встроенная часть. И также JS приходится взаимодействовать как с окружением браузера, если мы говорим про extinction, dev tools и прочие вещи, так и с движком рендерера, которые, как мы знаем, живут отдельно.
То есть, если мы говорим про Chrome — это Blink, ну и так далее. Пошли по очереди — это и дом API, который к нам приезжает, и куча всяких браузерных вещей, и специфические worker-ы, сам рендер. О чём и будет рассказывать Prashant Palikhe.
Артём: Тут соль в следующем: если у нас были fundamentals от Виталия Брагилевского, Nicolas Belmonte, Mathieu Henri, касающиеся в принципе инженерных практик, то Prashant будет рассказывать про базу, которая связана именно с фронтендерской частью. Он будет подробно раскрывать вопрос, который задают в большинстве приличных компаний на собеседовании: что происходит, когда ваша страница начинает грузиться. Что происходит в браузере под полой. Здесь будет раскрыто от TCP-handshake и обмена TLS-пакетов до того, что уже происходит при парсинге HTML, при подсчете стилей, при построении блоков, которые будут отображаться в браузере, при наложении стилей на уже отстроенные блоки, и что будет происходить при взаимодействии пользователя с браузером. То есть какие стадии ваш браузер будет повторять для изменения контента внутри.
Это будет именно тот фундаментальный вопрос, который стоит для фронтендера: «Что именно происходит в браузере, когда ваше приложение рендерится?».
Дмитрий: А Никита Мостовой будет рассказывать про то, какие проблемы вас ожидают, если вы просто пользуетесь браузером или разрабатываете сайты, т.е. будет рассказывать про проблемы extension-ов.
Это вообще некоторая боль, которую Google выпустил, открыв черный ящик, сделав extension-ы без review, и в политиках Google прямо сказано, что пользователи сами решают, ставить их или не ставить.
А extension-ы имеют доступ, мягко говоря, почти ко всему в вашем браузере, и в принципе они могут прямо залезть в ваш интернет-банк и поломать вам вообще всё. Вы берете, переводите деньги маме, а они уходят в лучшем случае папе.
Евгений: На самом деле они могут сделать с вашей страницей абсолютно всё.
Дмитрий: Они могут встроиться в страницу, в рантайм, и вот буквально недавно Google всё-таки начал чуть-чуть это рубить. В некоторых моментах они могли встраиваться ещё и на сетевом уровне.
Олег: Да, весь этот скандал с блокировщиками рекламы.
Дмитрий: Да, и не только они. Блокировщики — это самая добрая часть из extensions. И Никита как раз поимел очень много опыта с этими штуками. Имел опыт того, как их пытались ломать через extensions, потому что он работает в HeadHunter, а там есть некоторое количество важной информации для рынка. И он расскажет, как с этим жить.
Design Systems
Олег: Круто. Следующая категория — дизайн-системы!
Евгений: Давай я расскажу про дизайн-системы. Когда есть у вас есть только три фронтендера, то вы можете делать что хотите. Но когда разработчиков становится больше, понятно, нужно придумать способ, чтобы люди в разных частях компании — фронтендеры и дизайнеры и все остальные говорили на одном языке. И чтобы не было такого, что у тебя здесь кнопки одни, здесь другие, здесь одни цвета, там другие — это так не работает.
Поэтому абсолютно все крупные компании, которые занимаются разработкой каких-то продуктов на вебе, имеют дизайн-системы. Про это у нас будет два доклада.
Алексей: Будут Зар Захаров и Александр Каменяр. Есть такой инструмент для дизайнеров, называется Figma. Она на самом деле работает в онлайне, она выставляет наружу HTTP API, но не суть. И вот ребята придумали, как взять и интегрировать тулу при помощи этого API для того, чтобы сделать бесшовную интеграцию между дизайном и имплементацией, конкретно имплементацией на React. Получается, что мы можем помимо цветов выгружать, например, размеры, расстояния, и всё это держать в свежем виде. Нам не нужно синхронизировать дизайн с имплементацией, мы это пытаемся сделать в автоматическом режиме, насколько это возможно.
Евгений: Ещё у нас будет Андрей Оконечников, достаточно известный спикер, который тоже будет говорить про дизайн системы, но о его докладе подробностей пока нет.
Дмитрий: Андрей имеет свою компанию по дизайн-системам, и он будет рассказывать, как их строить в целом на основе опыта построения множества систем в разных компаниях.
Евгений: В целом, по дизайн-системам всё, следующий наш раздел — это языки программирования. У нас два докладчика.
Олег: Что происходит с языками программирования, их же куча как бы.
Евгений: Да ты что!
Олег: Ну можно начать перечислять: Kotlin.js, Clojure, Elm, ReasonML…
Михаил: Вот как раз про ReasonML и будет доклад. И называется он «ReasonML for skeptics» от Eric Schaefer. Было уже похожее название, ClojureScript for skeptics, про это рассказывал другой человек. Eric будет продавать ReasonML людям, которые не верят технологию ReasonML.
Он не просто попробовал tutorial с «Hello World» и пришел на докладе рассказать, какой Reason классный, чистые функции и все такое. Он занимается этим профессионально. Он писал инструменты с этим стеком для Google, для Red Bull и прочих больших компаний в потребительской индустрии. Он будет как-то оспаривать и нивелировать аргумент, что в ReasonML мало решений, которые можно использовать, и естественно, покажет плюсы языка.
Я не курировал этот доклад, и не могу быть уверенным, но он, по крайней мере, покажет, как React с GraphQL подружить под ReasonML. Учитывая, что новый React ложится под ReasonML идеально. Ну и да, маленький нюанс, что ReasonML разрабатывает Facebook и использует внутри себя.
Михаил: Да, про Эрика ещё хочу добавить, очень важный момент, что я не уточнил, но это должно быть сказано, что человек не просто будет показывать, что «Давайте построим компонент, типа строку, которая рендерит 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.
Почему? Потому что есть вещи, которые, во-первых, 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 ноября в Москве. Полное описание программы и воркшопов можно найти на официальном сайте, там же можно приобрести билеты.
Автор: Олег Чирухин
