Веб ожирел не по незнанию

Workafrolic (±∞)
5 min readJan 10, 2017

--

Среди разработчиков браузеров и любителей веба бытует мнение: в сети творится бардак. Средняя веб-страница превысила порог в 2.4 мегабайта и 200 запросов.

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

Мы допускаем мысль, что разработчики используют библиотеки или фреймворки только потому что не знают как сделать лучше. Или что эти люди решают некие проблемы, которых у нас не было — например, поддержку легаси окружений.

Я все больше и больше убеждаюсь, что мы не правы в этом вопросе. Это все не про фразы “ты не должен использовать фреймворки” или “использование XYZ считается вредным”. Это даже не о “если сделаете это сейчас, то позже это обернется кошмаром в плане поддержки”. Это все наше решение наших же проблем.

Мы делаем это. Снова и снова.

Информации в изобилии и нет проблемы с инструментами

Мы делаем все возможное, чтобы бороться с этой ситуацией. Мы делаем наши браузеры вечнозелеными и даже создаем “безголовые” версии для автоматического тестирования. Мы создаем инструменты чтобы точно показать что не так с веб-продуктом. У нас есть симуляторы, которые покажут, сколько времени требуется чтобы ваш продукт стал отзывчивым и доступным. Мы позволяем симулировать мобильные устройства на вашем компьютере, чтобы вы получили представление о том, как ваш продукт будет выглядеть для конечного пользователя.

Мы создаем наборы инструментов, которые вскрывают самые злостные нарушения, когда речь заходит о производительности. Мы сливаем и минифицируем скрипты и CSS, мы автоматически оптимизируем изображения и правим проблемы в процессе сборки до того, как они увидят жизнь.

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

И тем не менее в вебе полный бардак. И я говорю даже не о продуктах, которые раздулись из-за проблем поддержки или в силу возраста. Абсолютно новый, продвинутый и красивый продукт часто имеет в основе неверный подход к производительности. Почему?

Одна из причин ожирения — отсутствие страдающих от тех же проблем

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

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

Главная причина ожирения

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

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

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

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

Я не говорю, что это хорошо. Совсем нет. Постоянное давление на инновации с целью показать что-то новое и заставить людей быть более зависимыми от нашего продукта убивает интернет. И это убивает наше сообщество и ведет к нездоровой конкуренции среди разработчиков. Это ведет к тому, что 10х разработчиков готовы работать по 20 часов в день в течении нескольких месяцев над продуктом, который будет утилизирован через несколько недель после запуска.

Наша работа состоит в том, чтобы бороться с этим.

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

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

Наша работа состоит в том, чтобы давать разумную оценку сроков разработки и гордиться тем, что мы разработали.

И наша работа состоит в том, чтобы работать в тесном сотрудничестве с создателями библиотек и фреймворков, на которых основан наш продукт. Чтобы быть уверенным в том, что штуки, обещающие “получать больше меньшими усилиями” имеют качественный код вместо врожденного ожирения.

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

Самая большая проблема, которую нам нужно решить — перестать изобретать заново наш процесс работы каждые несколько месяцев. Вместо того, чтобы разобраться с нереальными сроками для слишком большого объема работ мы раз за разом оказываемся в той же ловушке. Мы хотим чтобы все видели, что мы пользуемся только самым новым и крутым и используем паттерны и способы работать быстрее, чем другие конкуренты. Качество и работа с платформами нынче не сексуальны. Изобретать новинки и отказываться от них — вот что сексуально.

Нет, я не против усовершенствований и я буду последним среди тех, кто скажет, что стек веб-технологий идеален. Но я очень устал видеть, как талантливые разработчики выгорают. Средний срок жизни разработчика в компании всего 1–2 года. Это не похоже на стабильность. Это не позволяет выстроить карьеру. Это не позволяет развиваться. Уродливый брограммер — это наша собственная вина. Это результат нашего нездорового отношения к работе, основанного на принципе “релизь быстро и ломай все”. Мы многое сломали. Давайте попытаемся поправить ситуацию, чиня то, что люди используют, а не говоря им, что они должны использовать.

Нашли ошибку? Воспользуйтесь функцией Private notes: выделяете текст с ошибкой, нажимаете на символ замка в появившемся бабле и оставляете свой комментарий. Спасибо!

--

--

Workafrolic (±∞)

Frontend-дева. Верстаю, пишу и перевожу статьи, менторю, выступаю.