Андрей Ситник — одно из самых известных российских имён во фронтенде: у его проектов PostCSS и Автопрефиксер счёт GitHub-звёзд идёт на десятки тысяч. Но поскольку Андрей живёт в Нью-Йорке, а путешествует по всей планете, застать в России его можно нечасто.
В мае он будет в Петербурге на конференции HolyJS, и по этому поводу его подробно расспросили участники программного комитета HolyJS Дмитрий DmitryMakhnev Махнёв и Максим Юзва. Почему Андрей считает, что фронтенд стагнирует, а код наших проектов излишне разбухший? В чём различия IT-сообществ разных стран? Как учить английский и почему это менее важно, чем кажется? Куда пропал проект Logux, презентованный на HolyJS ещё в 2016-м?
О текущих проектах
Дмитрий: Для начала расскажи кратко о себе — где ты и чем занимаешься.
Андрей: Меня зовут Андрей Ситник, я живу в Нью-Йорке, но стараюсь много путешествовать. В основном меня знают по опенсорсу и выступлениям — как сейчас популярно говорить, «медийный бренд в области IT». Не могу сказать, что я его прямо-таки заслужил, но удача мне способствовала.
Помимо опенсорса я занимаюсь продвижением языкового разнообразия в твиттер-аккаунте @LinguoPunk, википедией в @LostInWiki и борьбой за секс-позитивизм.
Дмитрий: Над какими проектами сейчас работаешь?
Андрей: В опенсорсных есть несколько проектов на поддержке, самые известные — PostCSS и Autoprefixer. Возможно, PostCSS сейчас слегка активизируется: Алексей Бондаренко сделал очень большое обновление API, поэтому скоро может быть большой релиз.
А Autoprefixer находится на поддерживающих релизах. Единственное там, что мы сейчас активно пилим — поддержку Grid для IE 10-11, но она идёт плохо из-за сопротивления Рейчел Эндрю, которая активно продвигала Grid. Она очень известный человек, и ей не нравятся любые инструменты, которые что-либо автоматически делают в CSS — такая религиозная борьба. И из-за её противодействия эта фича, к сожалению, особо не распространилась.
Дмитрий: Как Рейчел может мешать вам делать инструмент?
Андрей: Инструмент ничего не мешает делать, он работает. Но open source — не про программирование, open source — про общество и социализацию. Если никто не пользуется твоим продуктом или не говорит о нем медийно, нет никакой мотивации его делать. Как следствие, это бьёт по мотивации разработчиков, которые это сделали и продолжают делать. Об их геройстве мало кто говорит, но они все равно молодцы и настоящие герои.
На самом деле, мы реализовали все, что хотели и могли, там есть даже безумная идея с поддержкой автогридов, которую вообще невозможно сделать на этой спеке, но ребята придумали, как с помощью хитрого комбинирования магии селекторов сделать это.
В общем, PostCSS и Autoprefixer находятся на поддержке, там фичи добавляются редко и в основном мелкие, а вот активно разработка идет у Logux. А я в этом году хочу больше посвятить себя статьям, чем конкретному опенсорсному проекту.
Дмитрий: Ты сделал много сильно выстрелившего, а вот о Logux после презентации на HolyJS в 2016-м не очень слышно — что с ним?
Андрей: Это хороший вопрос, потому что поднимает очень интересную тему. Дело в том, что есть разные пути распространения ПО.
Использование опенсорса — это не какое-то рациональное принятие решений. Лучше всего разработку программного обеспечения описывает индустрия моды. Технический выбор — это, в первую очередь, мода, хайп и подобные штуки.
Поэтому есть несколько стратегий продвижения новых решений. Например, когда что-то появляется, как следует ещё не работает, но за счёт страха упустить что-то огромное люди быстро садятся на hype train, начинают пилить и доводят до рабочего состояния.
По-хорошему, больше половины популярных опенсорс-проектов были написаны просто отвратительно. Вернее, хайп вокруг них совершенно не соответствует качеству кода и уровню поддержки от организаторов. Но поскольку на hype train подсаживалась сразу куча людей, проект выживал и продолжал существовать.
Например, у Babel-плагинов нет асинхронности. Ты не можешь сделать асинхронные функции внутри плагинов, и это ужасная проблема, я не знаю, как это попало в продакшен, потому что это ужасно ограничивает огромные рынки применения Babel. Но так он был написан, такая у него архитектура. В Babel много весёлого.
Это один способ распространения: рассказать «всё пропало, если не выучите к завтрашнему дню — всё, рынку потребуются люди с тремя годами опыта в этой технологии». Но есть и другой способ. Например, в React сделали по-другому: сначала «варили» у себя в среде, а потом представили уже более-менее готовый к продакшену проект. Конечно, открытый вопрос, насколько именно он был готов к продакшену, но понятно, что фреймворки на 100% не подготовить.
Logux — система связи клиент/сервер. Идея запросов, будь то GraphQL или Ajax, не предназначена для нестабильного интернета и работает в таких условиях просто отвратно — это известная проблема большинства сайтов. Logux — другой подход, и, как следствие, технически очень большое решение. Идея не новая, таких решений множество, и они проваливались, и меня это волновало. Даже GraphQL производился с ужасным скрипом, и это должно было чему-то научить.
У меня мнение, что для такого типа задач hype train не работает. Мы не можем сделать решение, чтобы на него все наскочили и всё поехало. Когда мы поставляем решение сразу для фронтенда и бэкенда, попытки вывезти всё это на hype train приводят к противостоянию сообществ.
Поэтому я решил, что с Logux мы не будем делать так, а пойдём аккуратно и медленно, готовя его внутри проекта. Весь этот год-два мы варили Logux внутри Амплифера, применяли на разных проектах и смотрели, как реагируют бэкендеры. Я пытался объяснять, показывать, и сейчас Дима Салахутдинов поедет на Ruby-конфу рассказать о Logux, чтобы мы посмотрели, как они реагируют, как нам его пиарить бэкендерам. Потому что говорить им то, что мы говорим фронтендерам в духе «это хайп» — неправильно, там это не работает.
Дмитрий: Почему не работает?
Андрей: Бэкенд перешёл на систему либо стагнации, либо поддержки: в последние годы практически нет развития. И как следствие, у них другие приоритеты: когда у тебя нет новых фреймворков каждые полгода, это на тебя влияет. Они есть где-нибудь в Rust или Go, но Ruby — что там нового? Как следствие, люди сфокусированы на другом. Конечно, я очень упрощаю, и бэкенд бэкенду рознь.
Я хочу правильно распиарить это на бэкенде и на клиенте, хочу прийти с готовым решением, которое будет реально работать, которое мы реально проверили на продакшене. В 2017-2018 годах у нас уже была рабочая версия 0.2, но не было никакого scalability. У нас была идея, как масштабировать, и для пиара этого было бы достаточно, но на самом деле это неправильно.
Вместо этого мы разбираемся с проблемами реального, а не теоретического scalability, когда у тебя непонятно глючит и ты вообще не знаешь, в какой точке. И в Logux мы серьезно прокачали систему: например, можем без проблем поднять сервер на нескольких серверах сразу, и одной командой увеличить их число.
Это бессмысленно делать, пока у тебя нет настоящей аналитики. Потому что без неё не поймешь, где у тебя затык. Можно сколько угодно масштабировать, но окажется, что есть какое-то одно место, которое не скейлится. Поэтому у нас есть код, реально готовый к масштабированию, и огромное число аналитики: как и сколько времени тратится, сколько запросов приходит, можно посмотреть, где начинается затык. Например, по количеству операций в секунду или по количеству пользователей, и всё это на сервере решается по-разному.
Дмитрий: Звучит достаточно интересно. И, как я понимаю, планы достаточно большие на ближайшее время?
Андрей: Да, планы мы уже доварили до практического применения, я сейчас буду релизить 0.3 и писать доки, которых не хватает для массового применения. А код хороший.
О Nano ID и быстром интернете
Дмитрий: Ты затронул тему интернет-соединения: все привыкли к тому, что у нас интернет стабильный и хороший, а на самом деле всё совсем не так. И тут невозможно не обратить внимание на размер бандлов и прочего, вспомнить твой проект Nano ID. Почему это тебя так волнует? Начнём с размера.
Андрей: Не кажется ли мне, что это «экономия на спичках», когда у всех нормальный интернет? Хороший вопрос.
Nano ID — это библиотека весом в 141 байт, которая генерирует ID. Когда мы уменьшали её с 200 байт, это не имело практического смысла, а было «политическим манифестом» о том, что пора бы думать об этом.
Размер JS — это интересная проблема. Во-первых, компиляторы её не решают, а даже наоборот: большинство бандлеров неправильно объединяют, существенно увеличивают размер или неэффективно его используют.
И то, что скорость интернет-подключений растёт — это и правда, и в то же время нет. Как только интернет ускоряется, заявляют о себе страны, где с ним всё очень плохо — например, в Центральной Африке. А также появляются новые рынки — например, мобильный. И ещё есть хитрая проблема: скорость скачивания растёт, но при этом сайты быстрее не загружаются. Можно проверить на каком-нибудь LTE, который должен быстро всё открывать, если поделить размер страницы сайта на скорость сети.
Проблема в том, что реальная скорость загрузки сайта зависит уже от других параметров. Например, от количества round trip’ов. Дело в том, что между запросами и первыми байтами неизбежно проходит какое-то время, когда сигнал придёт и вернётся. Это время очень большое, до 500 мс. Во-первых, из-за ограничения скорости света, во-вторых, оборудование работает медленно. И если у вас файлы по очереди загружают друг друга, то сайт будет тормозить.
К счастью, эту проблему мы обнаружили довольно давно и научились её решать. Но она не единственная. Недавно мы столкнулись с другим: оказывается, проблема не в интернете, а в скорости компиляции. Дело в том, что 1 мегабайт картинок легко загрузить и отобразить, а 1 мегабайт JavaScript в 2-3 раза тяжелее для браузера, потому что его нужно компилировать. А количество JS растёт. И это объективная проблема низкой скорости сайтов.
Можно хитро подойти к вопросу изучения сайта методом энтропии. Есть у нас сайт, который весит 1 МБ. Есть понятие «количество информации». Мегабайт — не просто количество строк, это сколько вообще смысла содержится в этом коде. И насколько сложным должен быть сайт, чтобы там требовался 1 МБ? Неужели настолько разные юзеркейсы на сайте, что для их покрытия должен быть такой объём кода?
На самом деле, таких кейсов единицы. В ядре Linux столько нужно, но на сайтах — нет. И, следовательно, у нас куча лишнего кода.
Смысл Nano ID-движения не в том, чтобы экономить каждый байт, а в том, чтобы думать: «а что у меня вообще в бандле? Какого чёрта у меня там 1 МБ? У меня не может быть задач, где требовался бы такой объём». На большинстве сайтов 75% кода не используется. Nano ID — это движение против того, чтобы мы отправляли пользователям такой код.
Когда мы начинаем думать, почему столько кода не используется, понимаем: если речь не о громадной команде, один мегабайт кода не написать вручную. Это больше, чем условная «Война и мир», которую можно писать годами, и при этом код писать куда сложнее из-за взаимозависимостей.
И чаще всего этот объём — библиотеки. Знаменитая история с Moment.js: ты её подключаешь, а она из-за особенностей работы webpack грузит тебе на сайт каждый язык. И подобных случаев много.
В своё время мне в Logux понадобилось генерировать уникальный ID, я взял библиотеку, а потом обнаружил, что она весит 100КБ. Зачем мне столько для генерации случайного ID?
Такие размеры чаще всего из-за того, что разработчики библиотек неправильно их пишут. Поэтому главная идея — использовать Size Limit, чтобы разработчики библиотек контролировали размер своих проектов. Как ESLint, только для размера библиотек. И мы тут же видим, что огромное количество библиотек можно уменьшить в два раза.
Дмитрий: Тебе не кажется, что вопрос не только в размере кода, но и в подходах инструментов разработки? Если я экспортирую свою библиотеку объектом вместо отдельных функций, и не подключу на свой страх и риск Google Closure Compiler, то мне никто ничего не обрежет. Может быть проблема глубже, чем просто написание кода?
Андрей: Я бы не сказал, что проблема treeshaking действительно актуальная, потому что он в JavaScript не работает. Все думают, что тришейкинг решит проблему, но нет. Чаще всего проблема в другом: в том, что делают пакет. Используют какой-нибудь Rollup, упаковывают весь проект в один файл, и оказывается, что туда запаковывают, например, зависимости. Это огромная проблема, и мы с помощью Size Limit сильно уменьшили одну библиотеку, потому что убрали зависимости, которые в каждом проекте наверняка будут повторяться.
Вторая проблема в том, что случайно используют какой-нибудь API из Node.js. Например, была библиотека choo.js — «компактный JS-фреймворк», где проверяли входящие аргументы с помощью Node.js-модуля assert. А он грузит почти 4 КБ. И ради крошечной библиотеки мы грузим дополнительно 4 КБ.
И вот такие проблемы встречаются куда чаще, чем то, для чего используется treeshaking.
Лучшая рекомендация для тришейкинга — разбивайте файлы в сборке, пусть будут отдельные функции в отдельных файлах. Но чаще всего проблема в другом. Просто запустите Size Limit с опцией --why и посмотрите огромное количество мусора, который встраивает webpack при использовании вашего модуля.
Максим: Тогда получается, что использовать webpack для сборки — моветон?
Андрей: Смотря о чём говорить. Если делать библиотеку, скорее всего, webpack не нужен. У вас меньше 1% пользователей, которые хотят отдельный файл, и при этом лучше их заставить использовать webpack, потому что они вставляют вашу библиотеку, как ссылку на другой файл, и сайт будет тормозить.
А вот чем собирают пользователи ваши библиотеки, чем люди собирают сайты — на самом деле, без разницы. Мы во фронтенде привыкли, что, если неправильно использовать библиотеку, всё будет плохо, если прямо сегодня не перейдёшь с webpack на Parcel, то всё — до свиданья, ты плохой разработчик. Нет, честно говоря, плевать на инструменты.
В webpack хватает проблем, это плохой бандлер, но если он работает у вас — работайте дальше. Я видел проекты, где он помогает решать задачи, несмотря на то, что это один из самых заброшенных проектов. Например, css-loader там поддерживается одним человеком из России. Это реальный герой, но если он занят — всё, вашу проблему никто не исправит, а проблем-то множество.
Если я и говорю, что надо прекращать пользоваться webpack, то только потому что есть более хорошие сборщики. Но, опять же, пробуйте на новом проекте, а не меняйте на старом. Мы очень много дрочим на фреймворки и инструменты, хотя по факту они вообще не сказываются на том, как мы создаём код.
Почему hype train и «аристократы» — плохо
Максим: Ты сейчас говорил об уходе от webpack в пользу более крутых бандлеров. Может, есть проблема в том, что такие рекомендации от людей твоего уровня и создают хайп? Вместо того, чтобы рекомендовать использовать что-то новое, может, просто говорить «давайте поднажмём и сделаем webpack great again»?
Андрей: Хороший вопрос. С одной стороны, действительно есть проблема, когда подобные комментарии воспринимают без понимания контекста. Но есть и другая проблема: я опасаюсь стагнации.
Дело в том, что фронтенд стагнирует. Будем до скончания веков жить под эгидой React — ни один новый фреймворк не сможет его сместить, потому что критическая масса набрана. Это как в бэкенд-языках: старые языки не побеждены новыми, потому что нет критической массы, условий для перехода, разве что в каких-то узких задачах. Теперь и во фронтенде началось.
Стагнация фреймворков и систем сборки означает очень большую проблему: стагнацию людей, которые будут учить нас жить. Мы это видим прямо сейчас, потому что звёзды фронтенда всё те же самые, и, как следствие, новые не придут. А стагнация людей означает и стагнацию идей. Мы это видим пока по косвенным параметрам, пока хватает инерции, чтобы шли новые идеи. Но приходишь на конференцию, а все одинаковые, и меня это очень угнетает. По-моему, пора валить из мира фронтенда.
Это как Java — огромный рынок, на котором всё хорошо, но ничего нового нет. Как с этой проблемой справиться — не знаю. Но это одна из причин, по которым я топлю за маленькие проекты и постоянно их советую.
Честно скажу, что webpack очень сложно переписать, да и его создателю плевать на качество DX, он пишет его для себя и мало общается с пользователями. Кроме этого, есть архитектурные проблемы, из-за которых его реально сложно переписать. В команде webpack есть люди, которые честно пытаются сделать хорошо, но есть сложности, мешающие так сделать.
Есть сообщество, а куда его двигать — стабилизировать и дописывать старые инструменты или использовать новые — у меня нет ответа.
В идеальном мире мы не будем создавать ощущение, что использовать старые инструменты плохо, но при этом на новых проектах будем использовать новые. А как его создать, не знаю. Действительно даются неправильные рекомендации, и люди начинают травить других за использование «неправильных» вещей.
Максим: На твой взгляд, возможно ли такое, что большие корпорации вроде Microsoft и Facebook начнут скупать главные опенсорс-проекты вроде webpack и Babel?
Андрей: Скупать — нет. Им это невыгодно, пока сообщество приносит новые идеи, а это реальная бизнес-выгода. Они контролируют их, это работает по-другому.
К сожалению, во фронтенде уже возникла эта проблематика, но она выражается не в том, что компания что-то скупила, а в том, что у нас есть какие-то звёзды, которые не сменятся, всегда будут наверху и говорят, как мы будем писать код. Они знают друг друга, им легче подойти друг к другу и попросить что-то сделать. Поэтому их мнение важнее, чем мнение остальных людей. Это классическая система создания элит в обществе.
Без системы социальных лифтов это приводит к тому, что элиты консервируются, идеи становятся старыми. И проблема не в том, что компании их контролируют, а в том, что у нас есть очень небольшая группа людей, которая решает, какой фронтенд у нас будет. То, как работает браузер, полностью определяется очень небольшой группой людей, работающей над Chrome. Если Chrome продолжит наращивать популярность, будет большая проблема.
Основная проблема — создание аристократии, а не контроля корпораций. И это одна из вещей, из-за которой я считаю, что из фронтенда пора валить: аристократия уже сформировалась, и мы уже ничего не можем сделать. Например, на западном рынке не важно, насколько вы крутой и какую крутую идею продвигаете, скорее всего, не пробьётесь. У старых звёзд на порядок больше подписчиков, медийного влияния и их идеи будут куда более важны, чем ваши.
Дмитрий: «Не пробьётесь» с точки зрения опенсорса и донесения каких-то глобальных идей, а не с точки зрения работы в большой компании?
Андрей: Да. Слушай, ты говоришь, словно работа в большой компании — это благо. Конечно же, нет, это [нецензурно] галеры. О чём мы говорим?
Дмитрий: Я думаю, тут могут быть разные ощущения. Кто-то чувствует, что может именно так менять мир, потому что вместе с бизнесом есть какая-то поддержка, если мы немного отойдём от разработки.
Андрей: Дело в том, что бизнес разный. Я считаю, что реально хорошие компании — это, например, 37signals и DHH.
Самое смешное, что сейчас я смотрю на фронтенд с очень неприятным ощущением, что мы реально много потеряли, потому что приняли неправильные решения. Очень круто было вначале, когда была куча идей, мы постоянно их принимали, куда-то шли. А в итоге вся идея стартапов, которые на инвестициях больших компаний мгновенно разрастаются, оказалась ужасной.
Эти компании становятся монополистами, продают наши данные и принимают ужасные решения. Мне не очень нравится то, что с IT делает Долина.
У DHH есть хорошая идея, что стартап должен расти естественно, без вливания крупных денег: как только начинают вливаться крупные деньги, возникают совершенно другие условия, и они плохо влияют не только на общество, но и на всё развитие нашего движения. Мне совершенно не нравится, что происходит с большими корпорациями.
Дмитрий: Если вернуться к социальным лифтам. По-твоему, если всё-таки собраться и придумать что-то клёвое, возможно ли серьёзно заниматься опенсорсом без поддержки элит, или это до конца перекрытый путь?
Андрей: Есть хороший пример с Vue.js. Это офигенный проект, но он никогда не победит React, хотя у него решено всё, за что мы критикуем React. Неважно, какой проект ты напишешь: пока есть монополия, у пользователя просто не будет причин переходить.
Мы настолько верим в мантру «я должен написать так же, как пишут все, ни в коем случае не должен отходить от мейнстрима», что эта мантра сдерживает тебя, даже если ты предлагаешь продукт на 20–30% лучше. Исключение — это незанятые рынки. Например, Яндекс победил в России, потому что Google не было.
Google сместить невозможно, неважно, насколько у тебя хороший поисковик. Его победить можно только либо новых рынках, как какой-нибудь Instagram или Facebook, либо на новых языковых рынках, это, например, Яндекс в России. То же самое с фреймворками. Единственная причина, почему Vue нормально существует: он победил на рынке Китая и других, куда React ещё не успел прийти.
С другой стороны, Vue был начат как собственный проект, а потом туда пришли и присоединились корпорации. Я не считаю зазорным просить у компании деньги, и компании с удовольствием их дают, если вы правильно попросите. Поэтому находить поддержку у компаний — это нормально, это реально работает, это ситуация win/win. Компании очень редко вмешиваются и создают какие-то проблемы опенсорсу.
Проблемы тут именно маркетинговые, потому что есть очень небольшая группа элит, которая определяет, как ведётся веб-разработка, и очень сложно там что-то новое предложить, потому что вы не наберёте столько же читателей, столько же медиавлияния, как они, если не выйти на какой-то совершенно новый рынок.
Стоит ли вообще идти в опенсорс
Дмитрий: Возникает вопрос, стоит ли этим заниматься.
Андрей: Это хороший вопрос. Сразу говорю: нет, не занимаетесь, не создавайте новые опенсорс-проекты.
Главная причина, по которой их создают — это реклама: делайте опенсорс, и вы станете таким же знаменитым, как звёзды. Но на самом деле это «ошибка выжившего». Есть Дэн Абрамов на Западе, есть я в России, а по факту под этой верхушкой айсберга есть сотни людей, которые сделали проекты не хуже, но никому не известны.
По-хорошему, даже если вы сделаете идеальный проект, с 99-процентной вероятностью вы провалитесь. Например, я в свое время сделал Size Limit, и мы просто решили сначала написать хорошую статью, где мы будем его пиарить, а за это время другой чувак сделал проект, и о нем все рассказали, а Size Limit проиграл.
Скорее всего, вы так же закончите: кто-нибудь напишет проект, может быть, позже, может быть хуже, но он дружит с известными людьми, и известные люди сразу о нем напишут, вот и всё. Так выглядит опенсорс, это на самом деле кладбище людей, которые делают крутые проекты и не получают медиавлияния. Всё медиавлияние сливается в очень небольшую группу людей.
Это как стартапы. Стартапы — это на самом деле не «прекрасная ситуация, когда люди создают Google», а ситуация «для того, чтобы появился Google, нужно, чтобы 99% людей разрушили себе жизнь».
Поэтому, если вы хотите быть счастливым и известным, не делайте опенсорс. Если вы хотите, чтобы вас наняли, не делайте опенсорс. Потому что есть гораздо более хорошие способы получить эти вещи: выступать на митапах, исправлять документацию в уже крупных проектах, писать статьи.
Если вы приходите в компанию, и у вас есть какой-то pull request в Babel, это выглядит гораздо круче, чем если у вас есть какой-то проект с десятью звёздочками. А это, скорее всего, так и будет — неважно, насколько хорошо вы его напишете.
Если вы хотите просто влияния, важнее писать базовые статьи, где вы разжёвываете с необычной точки зрения какие-то базовые вещи. Это реально хорошо работает, медиаперсоны будут это репостить, потому что они говорят то же самое. Новые идеи не будут репостить, потому что они так же их не понимают.
Есть единственная причина начинать опенсорс — если вы хотите что-то изменить в этом мире. Например, PostCSS начинался, потому что я хотел, чтобы было больше CSS-инструментов. Autoprefixer был, потому что я хотел убить Compass, но потом, когда Compass мы убили, он продвигался, потому что я хотел, чтобы американские программисты перестали писать сайты только для американских браузеров, игнорируя Opera и так далее.
Если у вас такие задачи, там, самое смешное, статьи не работают. Все эти статьи про Accessibility, про использование кнопок вместо ссылок, если нет URL, вообще не работают, потому что они люди не вспоминают о них. Что реально работает, — автоматические тулзы, которые всё это проверяют. Был миллион докладов о том, как надо писать префиксы, и ни один из них не работал, пока не появился Autoprefixer.
Если вы хотите писать опенсорс, имейте хорошую чёткую цель, что вы хотите изменить в этом обществе, и и эта цель будет вас держать на плаву, когда вас будет ждать неудача, когда люди не будут пользоваться вашими разработками, когда звёзды будут игнорировать вас, потому что они вас лично не знают.
Дмитрий: Насколько сильным должен быть этот замах? Например, я хочу, прости господи, типы в JavaScript добавить, понятно, что это уже перебор. Где край, на котором стоит остановиться?
Андрей: Если вас устраивает, что мир изменится, а о вас никто не узнает — то это хорошая точка, чтобы начать делать опенсорс. Если нет — то есть много более надёжных способов стать популярным.
Максим: Я хочу перефразировать твоё утверждение. Получается, что опенсорс делать можно и нужно, и даже любые свои проекты стоит выкладывать в опенсорс, но не для хайпа.
Андрей: Нет, я бы так не говорил, поэтому огромное количество людей выкладывают свои проекты в опенсорс, и потом оказывается, что им начинает пользоваться куча людей, а поддерживать проект нет сил. Честно говоря, от этого все страдают. Нет, это неправильный подход.
Если у вас есть какой-то огонь в вашем сердце и вы хотите реально изменить общество, и вы готовы не спать ночами… PostCSS был написан, потому что я год работал без отпуска вообще, программировал сутки напролёт. Если вас такая мотивация, начинайте опенсорс, тогда всё будет хорошо. А если у вас какой-то пет-проект, его можно выложить, но опять же, от того, что он станет популярным, вы только проблемы получите.
Дмитрий: А какого рода проблемы?
Андрей: Люди будут приходить и требовать, чтобы вы исправили баги, не уважая вас.
Дмитрий: Если я оказался в такой ситуации, как бы ты подсказал искать людей, которые могут с этим помочь, по каким критериям их выбирать?
Андрей: Если вашим проектом пользуются люди, они его знают, от него зависит бизнес, при этом, это что-то фундаментальное, большое, например, то, за что люди готовы заплатить, я бы советовал начинать собирать деньги. Очень многие люди думают: «Вот я открыл Open Collective, а им никто не пользуется, компании виноваты».
На самом деле компании заплатят, если им рассказывать. В реальном бизнесе недостаточно написать программу. Вам нужно потратить ещё столько же сил на её пиар и разговор с клиентами. Если вы хотите развивать свой проект, но лень делать это бесплатно, у вас нет сил, вложитесь в пиар. «Есть проект, от этого проекта зависят жизни людей, вы мой проект используете. У меня есть Open Collective, давайте вы выложите небольшую сумму, и ваш проект будет в безопасности. Если нет, посмотрим, как ваш бизнес пойдёт, когда я перестану проект поддерживать».
Например, хорошо делать Babel или webpack. Они постоянно пишут: «Скидывайте деньги, вот что исправлено за них. Вот ваши issue, вот Open Collective, занесите баблишечка». Об этом нужно постоянно говорить, это отдельное приложение усилий. Холодные звонки, продажи — всё это нормально работает. Компания с удовольствием заплатит вам, если вы будете реально работать на эту систему продаж, потому что бизнес зависит от этого всего. Но у них должно быть чёткое понимание, кому сколько занести.
Если у вас просто маленький проект, и вы сами не хотите его развивать, это сложная задача. По-хорошему, нужно открыть issue, где вы напишете, что ищется maintainer, там вы чётко и явно укажете плюсы этого проекта, кто им пользуется, почему это важно, какой медиахайп можно получить. И дальше тем, кто открывает issue, говоришь: «Слушай, ты пришёл сюда, наверное, тебе это нужно. А проект не поддерживается. Смотри, я ищу мейнтейнера, не хочешь стать им?» Но тут есть и угроза безопасности. Приходит человек, говорит «хочу», а потом хакает ваш проект. Поэтому я и говорю, что если не готовы поддерживать, то лучше не выкладывать.
Дмитрий: А сталкивался ли ты когда-нибудь с тем, что в твои проекты пытались что-то инжектить?
Андрей: Нет. Это больше теоретические кейсы. Люди любят говорить, что JavaScript сломан, но на самом деле все пакетные менеджеры всех инструментов сломаны. Например, хакнуть проект на Ruby на порядок проще, чем на JavaScript. Сейчас это хайп. Были попытки что-то подобное сделать, но они были единичные. Проблема объективная, об этом нужно задумываться, но это не проблема только JavaScript.
Максим: Ты говорил, что даже pet project не стоит выкладывать в опенсорс. Допустим, я принимаю твою точку зрения, но у меня возникает новый вопрос: представим, я джуниор, работаю в веб-студии, где ещё пять таких же джунов и один миддл, которому нет дела до моего кода. Как мне попросить помощи у сообщества, чтобы они посмотрели код и сказали, хорошо я пишу или плохо?
Андрей: В пет-проект как раз сложно попросить помощи. Если хочешь расти, я очень советую контрибьютить в уже существующие проекты. Потому что как раз тут и твой код посмотрят, и тебе напишут, и на новую нормальную работу будет проще устроиться.
Тут возникает вопрос «куда контрибьютить». Есть реальный рабочий кейс. Вы пытаетесь развернуть проект, у вас не получается. Неправильно думать, что это вы тупой. А правильно — понять, что документация написана плохо, потому что maintainer не может написать хорошую документацию, находясь в состоянии, когда он-то всё понимает.
А вы как джуниор как раз находитесь в идеальных условиях, когда как раз и можете помочь. Поэтому, если вы не смогли развернуть, это место для хорошего вклада. Дальше вы пытаетесь разобраться, и в худшем случае, если не разобрались, открываете issue, а в лучшем случае разбираетесь-таки и добавляете в документацию те шаги, которые в итоге помогли вам разобраться, так, чтобы другой джуниор всё понял.
А если у тебя проект, как просить помощи? Никак. Можно на Хабр написать, но там, скорее всего, оценят только саму идею проекта. А код сложно проверять, я не знаю, как сделать это масштабируемо.
Максим: Бывает, что к тебе стучатся ребята и просят взять в падаваны или посмотреть их проект?
Андрей: Гораздо реже, чем мне бы хотелось. Я в феврале специально попросил людей присылать мне их проекты. Я давал рекомендации или помогал сразу же пиариться. Очень хорошо пошло, я буду такое повторять.
Единственный момент: если у вас есть вопрос, пишите его публично, чтобы мой ответ помог сразу куче людей. Я не очень люблю отвечать на вопросы частного характера в переписке, потому что это не очень масштабируемо. С другой стороны, если у вас есть опенсорс-проект, и вам нужна помощь, пишите мне обязательно. Я либо напишу вам, как документацию исправить, либо пропиарю ваш проект.
Просьб пропиарить проект приходит слишком мало, шлите ещё. Конечно, я пропиарю только процентов 10, потому что у большинства проблемы с позиционированием, с документацией и так далее, но, как минимум, советом вам помогу.
Максим: Ты считаешь, что это общая практика, которая должна быть в сообществе? Как по мне, это такой слегка пассивно-агрессивный подход: «Дэн Абрамов, помоги».
Андрей: Дело в том, что все медиаперсоны, включая меня, существуют за счет случайного перстня судьбы. Есть огромное количество хороших разработчиков, но судьба случайно выбрала нескольких. Я считаю, что это привилегия. «Помоги» — это другой вопрос, но я считаю, что обязанность любой медиаперсоны — пиарить молодые проекты. Понятно, что медиаперсоны получают огромное объективное преимущество, мне гораздо проще путешествовать из-за PostCSS. Я возвращаю долг комьюнити.
Медиа концентрируется буквально на паре человек, поэтому нужно создавать какие-то силы, которые будут распространять внимание на других людей. От концентрации внимания на двух-трёх людях плохо всем: самим медийным персонам, потому что они перегружены, сообществу, потому что новые идеи не развиваются, и вообще долгосрочной перспективе для человечества, потому что нас нет социальных лифтов для новых идей.
Ответы на вопросы — это другой момент. Вопросы не нужно писать всем, и никто не обязан отвечать вам на вопрос о вашем проекте с закрытым кодом, потому что, честно говоря, вы программист, и вам платят зарплату, чтобы вы в этом вопросе разбирались. Медиаперсоне помогло общество, поэтому она обязана помогать обществу. А закрытые проекты — это не помощь обществу, это помощь этим людям. Я считаю, это разные этические вопросы.
О путешествиях, необходимости знания английского и сообществах разработчиков в других странах
Дмитрий: Ты сказал, что PostCSS помогает путешествовать. Как много ты путешествуешь, и как ты это совмещаешь с работой?
Андрей: Честно говоря, работа даже лучше идёт. Я сейчас приехал в Нью-Йорк после небольшой поездки. Сложное путешествие, в Марокко плохой интернет, работать невозможно, но реально каждый день что-то полезное делал: статью написал, два сайта в совершенно новой технике сделал.
Приехал в Нью-Йорк, сижу, смотрю YouTube. Я путешествую, чтобы нормально и эффективно работать. На одном месте я сразу вафлей становлюсь, лежу на диване. Я путешествую, чтобы быть более продуктивным, поэтому совмещать легко.
Единственное правило: не думайте, что вы сможете в новом городе, работая, посмотреть его за сутки. Приезжайте с огромным запасом. Не думайте, что вы там будете везде гулять, вы реально будете всё так же работать. Вы будете обычным турецким фрилансером, который просыпается и работает, ест на улице, работает, смотрит сериальчики и спит. Если не менять города чаще, чем раз в две недели, то всё будет нормально. Проблем особо никаких нет.
Максим: Все понимают, что знание английского нужно, но хорошо выучить не так просто. У тебя был хороший бэкграунд? Откуда у тебя хороший английский?
Андрей: Вы смеётесь? У меня отвратительный английский. Я как раз эту тему поднимаю в «Лингвопанке». Мы в школе привыкли, что язык — это правила, особенно с токсичной русской культурой, где мы постоянно критикуем разных людей. Мы привыкли, что если ты говоришь и делаешь ошибку, то всё плохо.
На самом деле, язык — это система общения, и пока вас понимают, всё хорошо. Мы не понимаем, насколько язык дублирующая система. Это как компакт-диск или QR-код. Вы знаете, что у QR-кода можно большую часть уничтожить, и он всё равно будет читаться? Потому что там специальные алгоритмы дублирования информации. Смысл в том, что язык не нужно знать хорошо, нужно уметь общаться на нём.
Главное моё продвижение в языке случилось, когда я просто перестал бояться. Мы все боимся, потому что нас постоянно травят в школе и в интернете — страшный русский твиттер, где за описку травят сильнее, чем за антивакционную идею. На самом деле у русских неплохой английский. Начиная с того, что это близкородственные языки: не какой-нибудь китайский, где у тебя вообще другой языковой строй. Мы не представляем, как в остальном мире, там ещё хуже.
Россия находится на нормальном уровне. Конечно, похуже, чем Норвегия и подобные мелкие страны, которые просто вынуждены учить язык, потому что контента нет. Но в остальном русские хорошо говорят по-английски, никаких проблем нет. Главное правило — не бойтесь, просто коммуницируйте, переходите на язык жестов, бухайте перед обсуждением (это хорошо помогает понять, что на самом деле важны простые вещи).
Второй момент — смотрите сериалы с субтитрами, это реально помогает.
Путешествуйте, как раз язык выучите.
И главное — постарайтесь выступить.
Мы боимся языка, потому что в России есть проблема: мы очень мало коммуницируем с внешним миром. С одной стороны, это хорошо, так как есть внутренний рынок, который позволяет каким-то мелким людям выйти в свет. Как Яндекс вырос из монополии Google из-за языкового барьера, так есть и огромное количество социальных лифтов, по которым программист может подняться, чего никогда бы не случилось на Западе.
Но взамен есть проблема, что рынок закрытый, мы не смотрим наружу и все поднявшиеся люди, реально хорошие чуваки, не выходят на Запад, потому что боятся английского. Моя рекомендация — заведите два аккаунта в Twitter, в одном пишите на русском, чтобы помогать своей культуре (это тоже важно), а английский для практики. Когда вы пишете на английском, вы поймете, что это не сложно. Единственное, читать вас будет мало людей, потому что на Западе хватает своих, но критическая масса таким образом всё равно набирается, свои 150-300 читателей наберёте.
Участвуйте в англоговорящих митапах в России, это не страшно, вас никто не будет обижать, всё хорошо.
Дмитрий: А рекомендуешь ли ты попробовать переехать куда-то на какое-то время с целью изучения языка, если да — куда?
Андрей: Чтобы избавиться от страха, достаточно любого путешествия. А вот как дальше учить — хороший вопрос. Честно говоря, не знаю, я плохо знаю язык. Но могу сказать, что когда вы выступаете на митапе в Нью-Йорке, даже если аудитория с трудом воспринимает ваш акцент, то всем всё равно, потому что половина зрителей из Индии, половина из Китая.
И могу сказать о другом. В России есть популярный нарратив, что надо свалить, и везде хорошо: «В России всё плохо, я свалю и буду счастливым». Честно скажу — это та мотивация, которой лучше не руководствоваться. Потому что нарратив очень старый, и исторически мы знаем, что он не работает с XVIII-XIX веков. В других странах не принципиально лучше. Есть принципиальные проблемы управления, но они рано или поздно проявляются в любых странах.
Есть проблема выбора, когда у тебя есть задача, и она решается по-разному. Например, мы хотим, чтобы на улице было убрано, а для этого, на самом деле, нужно, чтобы было централизованное общество. Для этого нужно притеснять всех, кто думает неправильно, как в США. Там очень жёсткая система внутренних правил и противовесов о том, кто как должен думать и, на самом деле, США в этом плане похожи на Китай. Просто правила негласные, и государство этого не делает — это делает само общество.
Я бы не сказал, что есть однозначное решение, где лучше — где дороги разбиты, или где общество говорит, как вы должны думать. Но это не бинарное решение, и это вопрос политики и социологии. И общая канва: часто другие страны в чём-то лучше, потому что в другом месте хуже.
Лучше не переезжать сразу, а поездить по миру, и тогда вы поймёте, что вообще важно, какие вещи вы готовы отдать, чтобы взамен получить другие вещи. И вот уже с этим пониманием можно выбрать страну, куда вы можете переехать. И тогда переезжать нормально.
Но, скажу честно, счастливым вы не будете, потому что первая волна эмиграции — всегда испытывать ужасные страдания, находиться в депрессии, после переезда вы потеряете весь свой социальный круг.
Дмитрий: Хотелось бы узнать, какая разница в русском сообществе разработчиков и в других странах.
Андрей: Если говорить про Штаты, это интересная ситуация. Во-первых, там действительно жёсткая система навязывания философии. Она всегда была, у них жёсткая система наказаний, к примеру, публичная травля. Но система довольно старая и, в целом, работает. Честно говоря, зато она чаще всего использует для пропаганды правильных идей, а неправильные — ну, перегибы на местах.
Главная идея — там очень шаблонное в культуре, чтобы быстро распространять хорошие практики. Там огромное количество программистов не делают глупых ошибок, потому что всем сказали писать вот так, все так и пишут. Взамен довольно сложно продвигать свои идеи.
И есть особая культура small talk — травля за неправильные идеи создает социальное напряжение, а в США огромное количество наций, и они не умеют вести конфликтную тематику общения, не переходя на травлю, поэтому у них есть список из стоп-тем.
Это самое главное социальное отличие в комьюнити. Из плюсов — легки на подъем, и реально заботятся о том, чтобы люди не страдали. Ты приходишь, все дружелюбны, всё хорошо, пока ты обычный человек, который играет по правилам.
Вторая интересная особенность — там часто платят за митапы, символическая цена в 5-10 долларов, которая идет на еду. Опять же, потому что капитализм.
Дмитрий: А если не США, а другие страны?
Андрей: На втором месте, по тому, как я изучил комьюнити — это Китай. Там есть интересная особенность в огромном количестве разработчиков, а с другой стороны, у них интересный формат — очень мало нетворкинга. Он обычно закрытый, тебя приглашают на «особый завтрак», который проходит с лидерами сообщества. С другой стороны, люди на митапах реально приходят пообщаться на сложные темы и впитывать новые знания. Честно говоря, все эти особенности — это не рамки. Комьюнити разнообразное, и в Китае хватает анархистов, в Америке огромное количество людей тоже плевали на запреты. Ну и в России есть гостеприимные, вежливые и хорошие, а не мелочные критики.
Другая интересная особенность Китая — они закрытые, с отдельным миром, это и плюс, и минус. У них огромное количество своих наработок, потому что есть место, где они могут развиваться. А с другой стороны, они ужасно страдают от того, что не могут свои разработки вынести наружу, как в России. Все топовые китайские спикеры боятся выступать на английском от слова «вообще», хотя они нормально говорят на английском.
Дальше Япония. Несмотря на то, что это такая компьютерная страна, сверхдержава с развитой техникой, программирование считается хуже, чем менеджмент. Считается, что, в отличие от менеджеров, программирование — низкий труд: человеку сказали, и он пишет код. Как следствие — нет комьюнити, а ИТ развито просто ужасно, стартапы развиты несоизмеримо хуже, чем возможности страны. Нет Долины, «гениев-программистов», этого всего. А ещё там куда меньше женщин в ИТ, чем в Китае, из-за традиционного общества. В Китае с этим всё хорошо — много китаянок с интересными взглядами и опытом, хотя тоже есть куда расти.
Есть хорошее бразильское комьюнити. У испаноговорящих стран его нет, так как все ориентированы на Америку. У Франции тоже хорошее внутреннее комьюнити.
А вот в Шри-Ланке с ИТ-сообществом всё довольно плохо, потому что, когда выдают девушку замуж, чаще всего через семью, отец спрашивает: «а кем ты работаешь?». И есть белый список «правильных» профессий, и программисты в него пока не попали. Поэтому там очень мало программистов, хотя есть куча потенциальных плюсов: деньги, возможность иммиграции. Хороший отец оценил бы, что отдаёт дочь в хорошие руки, но такого не происходит, потому что список ещё не успел обновиться.
Я советую выступать на китайских и индийских конференциях: туда легко попасть (они с удовольствием принимают человека извне), а вы практикуетесь в английском в среде, где не будете бояться, потому что никто английского всё равно толком не знает и все говорят с ошибками.
Об идеальных конференциях
Дмитрий: Если мы заговорили о конференциях, какой фактор для участия в качестве спикера для тебя решающий?
Андрей: Для меня решающим фактором является доступность конференций. Хотя иногда, если мой путь идёт через какие-то страны, я соглашаюсь на конференции, которые не очень доступные для людей, просто чтобы прокачать доклад.
Я считаю, есть большая проблема, что цены на конференции сильно завышают. Я понимаю, что конференциям нужно зарабатывать деньги, с этим проблем нет, но есть какие-нибудь JSConf, которые берут баснословные $500 и, честно говоря, они тратят их на те вещи, на которых можно сэкономить. Например, на обеды, мощнейшее afterparty, хотя я бы, честно говоря, лучше пивка неприятного попил, но чтобы были интересные люди.
А огромные цены приводят к тому, что и спикерам неинтересно общаться со зрителями, иногда сложно поддержать тему, так как на конференции только работники крупных конференций, тот же создатель лучшей JS-имплементации CRDT Виктор Грищенко не смог приехать, потому что очень дорогой билет. Способов сэкономить куча, и их нужно применять, дорогие билеты — неправильно. Конференция должна быть доступной.
Я часто соглашаюсь поехать на небольшой митап, просто чтобы у всех был нормальный доступ к нетворкингу. И на многих митапах диалоги получаются лучше, чем на конференциях с большой стоимостью билета. Вот такой у меня подход.
Дмитрий: Без чего конференция не может быть хорошей? Уже ясно про нетворкинг, доступность, а что ещё?
Андрей: Ну, я как спикер очень ценю, когда перед сценой есть таймер. В этом плане у HolyJS всё очень профессионально, нравится организация выступлений. А вообще, нетворкинг — это ключевая вещь, люди ходят на конференциями не за знаниями, проще статью прочитать, чем доклад, а за ощущением принадлежности к сообществу.
Сообщество — самое важное, что происходит на конференциях. Ощущение, что ты поговоришь, и в тебе что-то изменилось, ты что-то узнал. Есть хорошая идея, что в нашем обществе не хватает понимания «зачем». Мы ходим на конференции, чтобы получить понимание, зачем вообще мы всем этим занимаемся. И хорошая конференция наверняка решает этот вопрос.
Дмитрий: Ты сказал «не за знаниями», это очень дискуссионный вопрос. Ты бы пошёл на конференцию, где собран набор людей с очень базовыми темами, но из очень разных комьюнити?
Андрей: Да, конечно, это было бы очень весело.
Дмитрий: И это было бы интереснее конференции, где серьёзные и мощные доклады?
Андрей: Я считаю, что оба подхода хороши, и никакой проблемы тут нету.
Дмитрий: Наверное, финальный вопрос. А что ты ожидаешь от HolyJS?
Андрей: Хорошего тусича! В 2016 году был прямо зачётный, один из лучших в моей жизни, и тогда всё очень хорошо организовали.
Дмитрий: А что бы ты порекомендовал в этот раз сделать, чтобы было ещё лучше? Пожелание для вечеринки?
Андрей: Я бы попробовал сорганизоваться с местными митапами. У нас есть много местных митапов, и довольно круто получается, когда у них есть возможность что-то сделать самим — есть множество инициативных людей, нужно дать им возможность. И было бы круто, если организаторам всех локальных митапов или их ключевым спикерам дали бесплатный билет или какую-то помощь, это было бы отлично.
На ближайшей HolyJS (Санкт-Петербург, 24-25 мая) Андрей ещё больше расскажет о продвижении опенсорс-проектов. А помимо него, там будет множество других значимых фигур JS-опенсорса: от Райана Дала (Node.js, Deno) до Мишеля Уэстстрате (MobX, Immer). Все подробности о их темах докладов — на сайте, приобрести билеты можно там же, и постепенно они дорожают.
Автор: Евгений Трифонов
