Как я побывала на HolyJS Moscow и нужно ли туда ходить
В минувшее воскресенье, 11 декабря, мне представилась возможность поучаствовать в HolyJS Moscow, грандиозном мероприятии, целиком и полностью посвящённом JavaScript. Количество информации на конференции поражало воображение (не обошлось даже без упоминания других технологий, хотя это логично: в мире веб-разработки всё взаимосвязано), однако из всего массива лично мне запомнилось четыре доклада. Сразу оговорюсь: дело не в том, что другие были лучше или хуже, просто именно эти привлекли моё внимание больше остальных. И здесь я поясню подробно, почему это так.
Для начала — небольшое лирическое отступление. Одна из причин моего переезда в Москву заключалась как раз в том, чтобы иметь возможность участвовать в подобных мероприятиях, находиться в центре последних новостей и технологий, всегда быть на гребне волны и в курсе модных тенденций в мире frontend. Я даже не помню, когда именно меня охватила мания к изучению всей информации, которая меня окружает, но так было не всегда. Уверена, что в этом стремлении я не одинока. Многие из вас пытались или даже пытаются в данный момент изучить 16 фреймворков и 23 библиотеки за неделю и за одну ночь выкатить шесть проектов. Откуда это берётся? С одной стороны, интуитивно понятно, что, если не успевать за новыми технологиями, можно оказаться невостребованным. Так что, возможно, всеми нами движет страх. Но с другой — задайте себе вопрос: так ли это на самом деле? Останутся ли ребята без знания webpack, например, или изоморфного рендеринга не у дел? Ведь ирония гонок за технологиями заключается в том, что можно напороться на фреймворк, о котором все говорят, начать его изучать, убить -дцать ночей и однажды проснуться вместе с релизом новой, несовместимой с обратной, версии этого же фреймворка. Более того, эта версия будет с новым синтаксисом, терминами и абсолютно другим подходом.
Эту историю мы все знаем либо по собственному опыту, либо по чужим рассказам. Мы начинаем говорить: «За технологиями не угонишься», «Это сегодня модно, завтра уже нет» или «Пока я буду разбираться с этой библиотекой, выйдет ещё семь». Однако даже зная, что такое произойдет, всё равно спешим собрать новый проект на модных инструментах хотя бы в песочнице, чтобы избавиться от страха, что мы в не теме. Я вовсе не хочу сказать, будто изучать новое — это плохо! Но что именно изучать? Сколько времени тратить? Иными словами, как остаться востребованным frontend-разработчиком, чтобы не умереть от недосыпа и стресса к 30 годам?
Совсем недавно я пришла к выводу, что жизнь в формате ночного кодинга и круглосуточной работы над изучением технологий — это не жизнь. Подводит здоровье, рано или поздно накрывает депрессия, а самое ужасное — ты начинаешь думать, что у тебя ничего не получается, да и как разработчик ты, в принципе, так себе. Это называется фрустрация. Знакомо? А ведь главная её причина кроется в банальной усталости. Поэтому в моей жизни появилось лимитированное время на работу. Оно постоянно пытается вырваться из рамок и захватить всю жизнь, но я держусь. Именно по этим причинам меня так зацепил доклад Дениса Мишунова под названием «Debugger».
Первым делом Денис указал на симптом, по которому можно выявить у себя эту «болезнь», приведя элементарный пример. Итак, вы пришли на конференцию, где в один и тот же момент читают три интересных доклада, и не знаете, куда идти. А когда уже выбрали — думаете:, а вдруг там, на другом докладе, информация более важная… Знакомая ситуация? Я от души посмеялась, потому что пример попал в точку.
Отметил Денис и то, что привычная многим фрустрация на самом деле только мешает мозгу изучать новую информацию. Тема перфекционизма (без которого мы вообще не живём) была раскрыта на факте из биографии Генри Форда, который однажды прислушался к словам своего помощника и решился выпустить неидеальную (по мнению Форда) машину. В итоге именно это ключевое решение сделало его всемирно известным и чрезвычайно богатым человеком. Ещё один пример — письмо Гарвардского университета с заголовком «Slow down» («Сбавьте темп»), в котором студентов призывали не убиваться, изучая информацию, и не стремиться уложить два или даже три года обучения в один.
Это был единственный нетехнический доклад на конференции, который, прозвучав в самом завершении мероприятия, выделялся больше всех. Уверена, что в скором времени он появится в Сети. Обязательно посмотрите его и задумайтесь: правильно ли вы поступаете? Может, по ночам стоит спать? Или вы остаётесь при мнении, что сон для слабаков?
Два следующих доклада я объединила для себя, поскольку они перекликаются друг с другом и решают одну проблему: транспорт. Тут можно поспорить (куда же без этого), но, забегая вперед, сообщу, что сами авторы со мной отчасти согласились.
Суть в том, что веб-разработка усложняется с каждым днём, если не с каждым часом. Появляется всё больше составных частей и, как следствие, вопросов коммуникации между ними. Проблема создания плагина для отладки сборки или продукта, в котором нужно проводить транзакции между сервером и клиентом, становится всё острей. Нам нужно покрывать всё больше и больше кейсов и решать всё больше проблем, о которых мы раньше даже не подозревали. Варианты выхода из этого сложного положения были описаны в докладах Ромы Дворнова про Rempl и Андрея Ситника про Logux.
Rempl (remote platform) — это платформа для контролируемого удалённого доступа к JavaScript runtime с использованием UI. Если понятней, это набор всего самого необходимого, что упрощает создание удалённых инструментов. Интерфейс таких инструментов может запускаться как в плагине для Chrome, так и в отдельной вкладке или в плагине к редактору. Возможности использования Rempl просто взрывают мозг — от инструментов, библиотек и фреймворков до «безумных» идей вроде простого файлообменника. Коллеги из компании Avito создали Rempl, решая свои задачи, но решили поделиться наработками со всеми. Теперь вместо мучений с проблемами инфраструктуры мы сразу думаем, что можно сделать, имея удаленный доступ к одному JavaScript runtime из другого через пользовательский интерфейс. Какие-то части платформы ещё в разработке, но уже сейчас ребята приглашают всех поучаствовать в жизни opensource-проекта и воплотить свои фантазии в жизнь. К тому же самому вас призываю и я!
Logux — это транспорт, синхронизирующий состояние данных на сервере и клиенте и решающий, таким образом, проблему потери интернета у пользователя. Название технологии может показаться вам созвучным с 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 (чтобы мозг лучше работал) или моей новой худи с надписью «JavaScript» (чтобы теперь уж точно было видно, что я веб-разработчик). Наконец, нельзя не упомянуть площадку для холиваров после выступлений, которая не пустовала ни на минуту, и, конечно же, afterparty с душевными разговорами о технологиях и общением со спикерами. Я могу с уверенностью сказать, что с каждой такой конференцией мы становимся всё ближе и ближе к европейскому комьюнити разработчиков.
В завершение. На мероприятии я встретила коллег со своего прошлого места работы, которые сами уже трудятся в других компаниях. Мы обменялись новостями и тёплыми воспоминаниями. Также я увидела знакомых с прошлых конференций, наладила новые связи, подружилась с отличными разработчиками, вдохновилась на очередные свершения и просто была счастлива, что являюсь частью этого большого сообщества. Стоит ли посещать такие мероприятия и тусовки, как HolyJS Moscow? Несомненно, да! Потому что только здесь вы сможете не только встретить своих старых знакомых или познакомиться с будущими друзьями-коллегами-единомышленниками, но и набраться знаний и вдохновения на создание по-настоящему крутых вещей!
P.S. Знаете, что самое ужасное? После конференции, а точнее после закрывающего доклада Дениса о том, что нужно сбавить темп, я просидела полночи за компьютером, перебирая в интернете всё услышанное и изучая документации… Уверена, что в этом я была не одинока! Всё-таки мы неизлечимы: мы разработчики.
