Хабрахабр

«Пора валить из фронтенда»: Андрей Ситник о стагнации сообщества, опенсорсе и не только

Но поскольку Андрей живёт в Нью-Йорке, а путешествует по всей планете, застать в России его можно нечасто. Андрей Ситник из Злых марсиан — одно из самых известных российских имён во фронтенде: у его проектов PostCSS и Автопрефиксер счёт GitHub-звёзд идёт на десятки тысяч.

Почему Андрей считает, что фронтенд стагнирует, а код наших проектов излишне разбухший? В мае он будет в Петербурге на конференции HolyJS, и по этому поводу его подробно расспросили участники программного комитета HolyJS Дмитрий DmitryMakhnev Махнёв и Максим Юзва. Как учить английский и почему это менее важно, чем кажется? В чём различия IT-сообществ разных стран? Куда пропал проект Logux, презентованный на HolyJS ещё в 2016-м?

О текущих проектах

Дмитрий: Для начала расскажи кратко о себе — где ты и чем занимаешься.

В основном меня знают по опенсорсу и выступлениям — как сейчас популярно говорить, «медийный бренд в области IT». Андрей: Меня зовут Андрей Ситник, я живу в Нью-Йорке, но стараюсь много путешествовать. Не могу сказать, что я его прямо-таки заслужил, но удача мне способствовала.

Помимо опенсорса я занимаюсь продвижением языкового разнообразия в твиттер-аккаунте @LinguoPunk, википедией в @LostInWiki и борьбой за секс-позитивизм.

Дмитрий: Над какими проектами сейчас работаешь?

Возможно, PostCSS сейчас слегка активизируется: Алексей Бондаренко сделал очень большое обновление API, поэтому скоро может быть большой релиз. Андрей: В опенсорсных есть несколько проектов на поддержке, самые известные — PostCSS и Autoprefixer.

Единственное там, что мы сейчас активно пилим — поддержку Grid для IE 10-11, но она идёт плохо из-за сопротивления Рейчел Эндрю, которая активно продвигала Grid. А Autoprefixer находится на поддерживающих релизах. И из-за её противодействия эта фича, к сожалению, особо не распространилась. Она очень известный человек, и ей не нравятся любые инструменты, которые что-либо автоматически делают в CSS — такая религиозная борьба.

Дмитрий: Как Рейчел может мешать вам делать инструмент?

Но open source — не про программирование, open source — про общество и социализацию. Андрей: Инструмент ничего не мешает делать, он работает. Как следствие, это бьёт по мотивации разработчиков, которые это сделали и продолжают делать. Если никто не пользуется твоим продуктом или не говорит о нем медийно, нет никакой мотивации его делать. Об их геройстве мало кто говорит, но они все равно молодцы и настоящие герои.

На самом деле, мы реализовали все, что хотели и могли, там есть даже безумная идея с поддержкой автогридов, которую вообще невозможно сделать на этой спеке, но ребята придумали, как с помощью хитрого комбинирования магии селекторов сделать это.

А я в этом году хочу больше посвятить себя статьям, чем конкретному опенсорсному проекту. В общем, PostCSS и Autoprefixer находятся на поддержке, там фичи добавляются редко и в основном мелкие, а вот активно разработка идет у Logux.

Дмитрий: Ты сделал много сильно выстрелившего, а вот о Logux после презентации на HolyJS в 2016-м не очень слышно — что с ним?

Дело в том, что есть разные пути распространения ПО. Андрей: Это хороший вопрос, потому что поднимает очень интересную тему.

Лучше всего разработку программного обеспечения описывает индустрия моды. Использование опенсорса — это не какое-то рациональное принятие решений. Технический выбор — это, в первую очередь, мода, хайп и подобные штуки.

Например, когда что-то появляется, как следует ещё не работает, но за счёт страха упустить что-то огромное люди быстро садятся на hype train, начинают пилить и доводят до рабочего состояния. Поэтому есть несколько стратегий продвижения новых решений.

Вернее, хайп вокруг них совершенно не соответствует качеству кода и уровню поддержки от организаторов. По-хорошему, больше половины популярных опенсорс-проектов были написаны просто отвратительно. Но поскольку на hype train подсаживалась сразу куча людей, проект выживал и продолжал существовать.

Ты не можешь сделать асинхронные функции внутри плагинов, и это ужасная проблема, я не знаю, как это попало в продакшен, потому что это ужасно ограничивает огромные рынки применения Babel. Например, у Babel-плагинов нет асинхронности. В Babel много весёлого. Но так он был написан, такая у него архитектура.

Но есть и другой способ. Это один способ распространения: рассказать «всё пропало, если не выучите к завтрашнему дню — всё, рынку потребуются люди с тремя годами опыта в этой технологии». Конечно, открытый вопрос, насколько именно он был готов к продакшену, но понятно, что фреймворки на 100% не подготовить. Например, в React сделали по-другому: сначала «варили» у себя в среде, а потом представили уже более-менее готовый к продакшену проект.

Идея запросов, будь то GraphQL или Ajax, не предназначена для нестабильного интернета и работает в таких условиях просто отвратно — это известная проблема большинства сайтов. Logux — система связи клиент/сервер. Идея не новая, таких решений множество, и они проваливались, и меня это волновало. Logux — другой подход, и, как следствие, технически очень большое решение. Даже GraphQL производился с ужасным скрипом, и это должно было чему-то научить.

Мы не можем сделать решение, чтобы на него все наскочили и всё поехало. У меня мнение, что для такого типа задач hype train не работает. Когда мы поставляем решение сразу для фронтенда и бэкенда, попытки вывезти всё это на hype train приводят к противостоянию сообществ.

Весь этот год-два мы варили Logux внутри Амплифера, применяли на разных проектах и смотрели, как реагируют бэкендеры. Поэтому я решил, что с Logux мы не будем делать так, а пойдём аккуратно и медленно, готовя его внутри проекта. Потому что говорить им то, что мы говорим фронтендерам в духе «это хайп» — неправильно, там это не работает. Я пытался объяснять, показывать, и сейчас Дима Салахутдинов поедет на Ruby-конфу рассказать о Logux, чтобы мы посмотрели, как они реагируют, как нам его пиарить бэкендерам.

Дмитрий: Почему не работает?

И как следствие, у них другие приоритеты: когда у тебя нет новых фреймворков каждые полгода, это на тебя влияет. Андрей: Бэкенд перешёл на систему либо стагнации, либо поддержки: в последние годы практически нет развития. Как следствие, люди сфокусированы на другом. Они есть где-нибудь в Rust или Go, но Ruby — что там нового? Конечно, я очень упрощаю, и бэкенд бэкенду рознь.

В 2017-2018 годах у нас уже была рабочая версия 0. Я хочу правильно распиарить это на бэкенде и на клиенте, хочу прийти с готовым решением, которое будет реально работать, которое мы реально проверили на продакшене. У нас была идея, как масштабировать, и для пиара этого было бы достаточно, но на самом деле это неправильно. 2, но не было никакого scalability.

И в Logux мы серьезно прокачали систему: например, можем без проблем поднять сервер на нескольких серверах сразу, и одной командой увеличить их число. Вместо этого мы разбираемся с проблемами реального, а не теоретического scalability, когда у тебя непонятно глючит и ты вообще не знаешь, в какой точке.

Потому что без неё не поймешь, где у тебя затык. Это бессмысленно делать, пока у тебя нет настоящей аналитики. Поэтому у нас есть код, реально готовый к масштабированию, и огромное число аналитики: как и сколько времени тратится, сколько запросов приходит, можно посмотреть, где начинается затык. Можно сколько угодно масштабировать, но окажется, что есть какое-то одно место, которое не скейлится. Например, по количеству операций в секунду или по количеству пользователей, и всё это на сервере решается по-разному.

И, как я понимаю, планы достаточно большие на ближайшее время? Дмитрий: Звучит достаточно интересно.

3 и писать доки, которых не хватает для массового применения. Андрей: Да, планы мы уже доварили до практического применения, я сейчас буду релизить 0. А код хороший.

О Nano ID и быстром интернете

Дмитрий: Ты затронул тему интернет-соединения: все привыкли к тому, что у нас интернет стабильный и хороший, а на самом деле всё совсем не так. И тут невозможно не обратить внимание на размер бандлов и прочего, вспомнить твой проект Nano ID. Почему это тебя так волнует? Начнём с размера.

Хороший вопрос. Андрей: Не кажется ли мне, что это «экономия на спичках», когда у всех нормальный интернет?

Когда мы уменьшали её с 200 байт, это не имело практического смысла, а было «политическим манифестом» о том, что пора бы думать об этом. Nano ID — это библиотека весом в 141 байт, которая генерирует ID.

Во-первых, компиляторы её не решают, а даже наоборот: большинство бандлеров неправильно объединяют, существенно увеличивают размер или неэффективно его используют. Размер JS — это интересная проблема.

Как только интернет ускоряется, заявляют о себе страны, где с ним всё очень плохо — например, в Центральной Африке. И то, что скорость интернет-подключений растёт — это и правда, и в то же время нет. И ещё есть хитрая проблема: скорость скачивания растёт, но при этом сайты быстрее не загружаются. А также появляются новые рынки — например, мобильный. Можно проверить на каком-нибудь LTE, который должен быстро всё открывать, если поделить размер страницы сайта на скорость сети.

Например, от количества round trip’ов. Проблема в том, что реальная скорость загрузки сайта зависит уже от других параметров. Это время очень большое, до 500 мс. Дело в том, что между запросами и первыми байтами неизбежно проходит какое-то время, когда сигнал придёт и вернётся. И если у вас файлы по очереди загружают друг друга, то сайт будет тормозить. Во-первых, из-за ограничения скорости света, во-вторых, оборудование работает медленно.

Но она не единственная. К счастью, эту проблему мы обнаружили довольно давно и научились её решать. Дело в том, что 1 мегабайт картинок легко загрузить и отобразить, а 1 мегабайт JavaScript в 2-3 раза тяжелее для браузера, потому что его нужно компилировать. Недавно мы столкнулись с другим: оказывается, проблема не в интернете, а в скорости компиляции. И это объективная проблема низкой скорости сайтов. А количество JS растёт.

Есть у нас сайт, который весит 1 МБ. Можно хитро подойти к вопросу изучения сайта методом энтропии. Мегабайт — не просто количество строк, это сколько вообще смысла содержится в этом коде. Есть понятие «количество информации». Неужели настолько разные юзеркейсы на сайте, что для их покрытия должен быть такой объём кода? И насколько сложным должен быть сайт, чтобы там требовался 1 МБ?

В ядре Linux столько нужно, но на сайтах — нет. На самом деле, таких кейсов единицы. И, следовательно, у нас куча лишнего кода.

Какого чёрта у меня там 1 МБ? Смысл Nano ID-движения не в том, чтобы экономить каждый байт, а в том, чтобы думать: «а что у меня вообще в бандле? На большинстве сайтов 75% кода не используется. У меня не может быть задач, где требовался бы такой объём». Nano ID — это движение против того, чтобы мы отправляли пользователям такой код.

Это больше, чем условная «Война и мир», которую можно писать годами, и при этом код писать куда сложнее из-за взаимозависимостей. Когда мы начинаем думать, почему столько кода не используется, понимаем: если речь не о громадной команде, один мегабайт кода не написать вручную.

Знаменитая история с Moment.js: ты её подключаешь, а она из-за особенностей работы webpack грузит тебе на сайт каждый язык. И чаще всего этот объём — библиотеки. И подобных случаев много.

Зачем мне столько для генерации случайного ID? В своё время мне в Logux понадобилось генерировать уникальный ID, я взял библиотеку, а потом обнаружил, что она весит 100КБ.

Поэтому главная идея — использовать Size Limit, чтобы разработчики библиотек контролировали размер своих проектов. Такие размеры чаще всего из-за того, что разработчики библиотек неправильно их пишут. И мы тут же видим, что огромное количество библиотек можно уменьшить в два раза. Как ESLint, только для размера библиотек.

Если я экспортирую свою библиотеку объектом вместо отдельных функций, и не подключу на свой страх и риск Google Closure Compiler, то мне никто ничего не обрежет. Дмитрий: Тебе не кажется, что вопрос не только в размере кода, но и в подходах инструментов разработки? Может быть проблема глубже, чем просто написание кода?

Все думают, что тришейкинг решит проблему, но нет. Андрей: Я бы не сказал, что проблема treeshaking действительно актуальная, потому что он в JavaScript не работает. Используют какой-нибудь Rollup, упаковывают весь проект в один файл, и оказывается, что туда запаковывают, например, зависимости. Чаще всего проблема в другом: в том, что делают пакет. Это огромная проблема, и мы с помощью Size Limit сильно уменьшили одну библиотеку, потому что убрали зависимости, которые в каждом проекте наверняка будут повторяться.

Например, была библиотека choo.js — «компактный JS-фреймворк», где проверяли входящие аргументы с помощью Node.js-модуля assert. Вторая проблема в том, что случайно используют какой-нибудь API из Node.js. И ради крошечной библиотеки мы грузим дополнительно 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 есть хорошая идея, что стартап должен расти естественно, без вливания крупных денег: как только начинают вливаться крупные деньги, возникают совершенно другие условия, и они плохо влияют не только на общество, но и на всё развитие нашего движения.

По-твоему, если всё-таки собраться и придумать что-то клёвое, возможно ли серьёзно заниматься опенсорсом без поддержки элит, или это до конца перекрытый путь? Дмитрий: Если вернуться к социальным лифтам.

Это офигенный проект, но он никогда не победит React, хотя у него решено всё, за что мы критикуем React. Андрей: Есть хороший пример с Vue.js. Неважно, какой проект ты напишешь: пока есть монополия, у пользователя просто не будет причин переходить.

Исключение — это незанятые рынки. Мы настолько верим в мантру «я должен написать так же, как пишут все, ни в коем случае не должен отходить от мейнстрима», что эта мантра сдерживает тебя, даже если ты предлагаешь продукт на 20–30% лучше. Например, Яндекс победил в России, потому что Google не было.

Его победить можно только либо новых рынках, как какой-нибудь Instagram или Facebook, либо на новых языковых рынках, это, например, Яндекс в России. Google сместить невозможно, неважно, насколько у тебя хороший поисковик. Единственная причина, почему Vue нормально существует: он победил на рынке Китая и других, куда React ещё не успел прийти. То же самое с фреймворками.

Я не считаю зазорным просить у компании деньги, и компании с удовольствием их дают, если вы правильно попросите. С другой стороны, Vue был начат как собственный проект, а потом туда пришли и присоединились корпорации. Компании очень редко вмешиваются и создают какие-то проблемы опенсорсу. Поэтому находить поддержку у компаний — это нормально, это реально работает, это ситуация win/win.

Проблемы тут именно маркетинговые, потому что есть очень небольшая группа элит, которая определяет, как ведётся веб-разработка, и очень сложно там что-то новое предложить, потому что вы не наберёте столько же читателей, столько же медиавлияния, как они, если не выйти на какой-то совершенно новый рынок.

Стоит ли вообще идти в опенсорс

Дмитрий: Возникает вопрос, стоит ли этим заниматься.

Сразу говорю: нет, не занимаетесь, не создавайте новые опенсорс-проекты. Андрей: Это хороший вопрос.

Но на самом деле это «ошибка выжившего». Главная причина, по которой их создают — это реклама: делайте опенсорс, и вы станете таким же знаменитым, как звёзды. Есть Дэн Абрамов на Западе, есть я в России, а по факту под этой верхушкой айсберга есть сотни людей, которые сделали проекты не хуже, но никому не известны.

Например, я в свое время сделал Size Limit, и мы просто решили сначала написать хорошую статью, где мы будем его пиарить, а за это время другой чувак сделал проект, и о нем все рассказали, а Size Limit проиграл. По-хорошему, даже если вы сделаете идеальный проект, с 99-процентной вероятностью вы провалитесь.

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

Стартапы — это на самом деле не «прекрасная ситуация, когда люди создают 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, говоришь: «Слушай, ты пришёл сюда, наверное, тебе это нужно. Приходит человек, говорит «хочу», а потом хакает ваш проект. Смотри, я ищу мейнтейнера, не хочешь стать им?» Но тут есть и угроза безопасности. Поэтому я и говорю, что если не готовы поддерживать, то лучше не выкладывать.

Дмитрий: А сталкивался ли ты когда-нибудь с тем, что в твои проекты пытались что-то инжектить?

Это больше теоретические кейсы. Андрей: Нет. Например, хакнуть проект на Ruby на порядок проще, чем на JavaScript. Люди любят говорить, что 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 году был прямо зачётный, один из лучших в моей жизни, и тогда всё очень хорошо организовали. Андрей: Хорошего тусича!

Пожелание для вечеринки? Дмитрий: А что бы ты порекомендовал в этот раз сделать, чтобы было ещё лучше?

У нас есть много местных митапов, и довольно круто получается, когда у них есть возможность что-то сделать самим — есть множество инициативных людей, нужно дать им возможность. Андрей: Я бы попробовал сорганизоваться с местными митапами. И было бы круто, если организаторам всех локальных митапов или их ключевым спикерам дали бесплатный билет или какую-то помощь, это было бы отлично.

А помимо него, там будет множество других значимых фигур JS-опенсорса: от Райана Дала (Node.js, Deno) до Мишеля Уэстстрате (MobX, Immer). На ближайшей HolyJS (Санкт-Петербург, 24-25 мая) Андрей ещё больше расскажет о продвижении опенсорс-проектов. Все подробности о их темах докладов — на сайте, приобрести билеты можно там же, и постепенно они дорожают.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть