Как я побывала на HolyJS Moscow и нужно ли туда ходить

В минувшее воскресенье, 11 декабря, мне представилась возможность поучаствовать в HolyJS Moscow ^[1], грандиозном мероприятии, целиком и полностью посвящённом JavaScript. Количество информации на конференции поражало воображение (не обошлось даже без упоминания других технологий, хотя это логично: в мире веб-разработки всё взаимосвязано), однако из всего массива лично мне запомнилось четыре доклада. Сразу оговорюсь: дело не в том, что другие были лучше или хуже, просто именно эти привлекли моё внимание больше остальных. И здесь я поясню подробно, почему это так.

Для начала — небольшое лирическое отступление. Одна из причин моего переезда в Москву заключалась как раз в том, чтобы иметь возможность участвовать в подобных мероприятиях, находиться в центре последних новостей и технологий, всегда быть на гребне волны и в курсе модных тенденций в мире frontend. Я даже не помню, когда именно меня охватила мания к изучению всей информации, которая меня окружает, но так было не всегда. Уверена, что в этом стремлении я не одинока. Многие из вас пытались или даже пытаются в данный момент изучить 16 фреймворков и 23 библиотеки за неделю и за одну ночь выкатить шесть проектов. Откуда это берётся? С одной стороны, интуитивно понятно, что, если не успевать за новыми технологиями, можно оказаться невостребованным. Так что, возможно, всеми нами движет страх. Но с другой — задайте себе вопрос: так ли это на самом деле? Останутся ли ребята без знания webpack, например, или изоморфного рендеринга не у дел? Ведь ирония гонок за технологиями заключается в том, что можно напороться на фреймворк, о котором все говорят, начать его изучать, убить -дцать ночей и однажды проснуться вместе с релизом новой, несовместимой с обратной, версии этого же фреймворка. Более того, эта версия будет с новым синтаксисом, терминами и абсолютно другим подходом.

Эту историю мы все знаем либо по собственному опыту, либо по чужим рассказам. Мы начинаем говорить: «За технологиями не угонишься», «Это сегодня модно, завтра уже нет» или «Пока я буду разбираться с этой библиотекой, выйдет ещё семь». Однако даже зная, что такое произойдет, всё равно спешим собрать новый проект на модных инструментах хотя бы в песочнице, чтобы избавиться от страха, что мы в не теме. Я вовсе не хочу сказать, будто изучать новое — это плохо! Но что именно изучать? Сколько времени тратить? Иными словами, как остаться востребованным frontend-разработчиком, чтобы не умереть от недосыпа и стресса к 30 годам?

Совсем недавно я пришла к выводу, что жизнь в формате ночного кодинга и круглосуточной работы над изучением технологий — это не жизнь. Подводит здоровье, рано или поздно накрывает депрессия, а самое ужасное — ты начинаешь думать, что у тебя ничего не получается, да и как разработчик ты, в принципе, так себе. Это называется фрустрация. Знакомо? А ведь главная её причина кроется в банальной усталости. Поэтому в моей жизни появилось лимитированное время на работу. Оно постоянно пытается вырваться из рамок и захватить всю жизнь, но я держусь. Именно по этим причинам меня так зацепил доклад Дениса Мишунова под названием «Debugger».

Первым делом Денис указал на симптом, по которому можно выявить у себя эту «болезнь», приведя элементарный пример. Итак, вы пришли на конференцию, где в один и тот же момент читают три интересных доклада, и не знаете, куда идти. А когда уже выбрали — думаете: а вдруг там, на другом докладе, информация более важная… Знакомая ситуация? Я от души посмеялась, потому что пример попал в точку.

Отметил Денис и то, что привычная многим фрустрация на самом деле только мешает мозгу ^[2] изучать новую информацию. Тема перфекционизма (без которого мы вообще не живём) была раскрыта на факте из биографии Генри Форда, который однажды прислушался к словам своего помощника и решился выпустить неидеальную (по мнению Форда) машину. В итоге именно это ключевое решение сделало его всемирно известным и чрезвычайно богатым человеком. Ещё один пример — письмо Гарвардского университета с заголовком «Slow down ^[3]» («Сбавьте темп»), в котором студентов призывали не убиваться, изучая информацию, и не стремиться уложить два или даже три года обучения в один.

Это был единственный нетехнический доклад на конференции, который, прозвучав в самом завершении мероприятия, выделялся больше всех. Уверена, что в скором времени он появится в Сети. Обязательно посмотрите его и задумайтесь: правильно ли вы поступаете? Может, по ночам стоит спать? Или вы остаётесь при мнении, что сон для слабаков?

Два следующих доклада я объединила для себя, поскольку они перекликаются друг с другом и решают одну проблему: транспорт. Тут можно поспорить (куда же без этого), но, забегая вперед, сообщу, что сами авторы со мной отчасти согласились.

Суть в том, что веб-разработка усложняется с каждым днём, если не с каждым часом. Появляется всё больше составных частей и, как следствие, вопросов коммуникации между ними. Проблема создания плагина для отладки сборки или продукта, в котором нужно проводить транзакции между сервером и клиентом, становится всё острей. Нам нужно покрывать всё больше и больше кейсов и решать всё больше проблем, о которых мы раньше даже не подозревали. Варианты выхода из этого сложного положения были описаны в докладах Ромы Дворнова про Rempl и Андрея Ситника про Logux.

Rempl ^[4] (remote platform) — это платформа для контролируемого удалённого доступа к JavaScript runtime с использованием UI. Если понятней, это набор всего самого необходимого, что упрощает создание удалённых инструментов. Интерфейс таких инструментов может запускаться как в плагине для Chrome, так и в отдельной вкладке или в плагине к редактору. Возможности использования Rempl просто взрывают мозг ^[2] — от инструментов, библиотек и фреймворков до «безумных» идей вроде простого файлообменника. Коллеги из компании Avito создали Rempl, решая свои задачи, но решили поделиться наработками со всеми. Теперь вместо мучений с проблемами инфраструктуры мы сразу думаем, что можно сделать, имея удаленный доступ к одному JavaScript runtime из другого через пользовательский интерфейс. Какие-то части платформы ещё в разработке, но уже сейчас ребята приглашают всех поучаствовать в жизни opensource-проекта и воплотить свои фантазии в жизнь. К тому же самому вас призываю и я!

Logux ^[5] — это транспорт, синхронизирующий состояние данных на сервере и клиенте и решающий, таким образом, проблему потери интернета у пользователя. Название технологии может показаться вам созвучным с Redux, и это не случайность. Logux является своего рода объединением Redux и Swarm.js. Первая часть названия Logux отражает подход к синхронизации данных — через логи. Например, если вы оказались в лесу, горах или на необитаемом острове и отправили комментарий под фоточку с котиком, то, когда вы появитесь в Сети, хронологически он окажется именно там, где и должен был находиться, когда вы нажимали кнопку «отправить». Логи на сервере и клиенте синхронизируются по времени. Андрей отметил, что технология пока ещё сырая, а готовую версию обязательно будут предоставлять сразу с рекомендациями к применению и лучшими практиками. Несмотря на разность двух технологий, Rempl и Logux, согласитесь: они действительно перекликаются, решая проблемы сложных коммуникаций.

Последний доклад, о котором я хочу рассказать («Мутация Web»), представил Павел Кондратенко. В частности, он рассказывал о способах, с помощью которых Lenta.ru удерживает пользователей на сайте: о push-уведомлениях, AMP (js-библиотеке от Google для ускорения работы web-страниц на мобильных устройствах, которая ещё и способствует их индексации) и… о крестиках-ноликах. Да, именно о крестиках-ноликах. Мини-игра открывается, если пользователь уже был на странице Lenta.ru с телефона, но у него пропал интернет. Теперь читатель больше не закрывает страницу, а остаётся на ней и играет в крестики-нолики. Круто? Очень круто. Можно прямо сейчас рвануть и проверить, что это так. Единственный минус — опция работает только для смартфонов на Андроиде. Вопрос «почему?» предлагаю задать Павлу лично. Что же касается push-уведомлений, то они являются новинкой для современного рынка и только-только начинают привлекать внимание бизнеса. А между тем, как показывает опыт Lenta.ru, количество посещений страниц сайта после начала использования уведомлений увеличилось на 2 %.

Таковы четыре доклада, которые я решила выделить из всей конференции. Повторюсь, это совсем не значит, что остальные оказались скучными или неважными! На HolyJS Mosсow было огромное количество интересной информации, которую представили прекрасные англо- и русскоговорящие спикеры. Отдельно хотелось бы отметить отличный звук и подарки вроде шоколада от HolyJS (чтобы мозг ^[2] лучше работал) или моей новой худи с надписью «JavaScript» (чтобы теперь уж точно было видно, что я веб-разработчик). Наконец, нельзя не упомянуть площадку для холиваров после выступлений, которая не пустовала ни на минуту, и, конечно же, afterparty с душевными разговорами о технологиях и общением со спикерами. Я могу с уверенностью сказать, что с каждой такой конференцией мы становимся всё ближе и ближе к европейскому комьюнити разработчиков.

В завершение. На мероприятии я встретила коллег со своего прошлого места работы, которые сами уже трудятся в других компаниях. Мы обменялись новостями и тёплыми воспоминаниями. Также я увидела знакомых с прошлых конференций, наладила новые связи, подружилась с отличными разработчиками, вдохновилась на очередные свершения и просто была счастлива, что являюсь частью этого большого сообщества. Стоит ли посещать такие мероприятия и тусовки, как HolyJS Moscow? Несомненно, да! Потому что только здесь вы сможете не только встретить своих старых знакомых или познакомиться с будущими друзьями-коллегами-единомышленниками, но и набраться знаний и вдохновения на создание по-настоящему крутых вещей!

P. S. Знаете, что самое ужасное? После конференции, а точнее после закрывающего доклада Дениса о том, что нужно сбавить темп, я просидела полночи за компьютером, перебирая в интернете всё услышанное и изучая документации… Уверена, что в этом я была не одинока! Всё-таки мы неизлечимы: мы разработчики.

Автор: Mail.Ru Group

Источник ^[6]