Веб-разработчик объяснил, почему многие не «используют платформу» браузера
Автор эссе, веб-разработчик, который сам не раз призывал «использовать платформу», то есть брать готовые возможности браузера вместо самописного кода на JavaScript. Стандартный довод сторонников таков: то, что вы построите сами, скорее всего, будет работать хуже и быть менее удобным, чем то, что браузер даёт из коробки. Автор решает встать на другую сторону, чтобы понять скептиков: если принцип так очевиден, почему многих приходится убеждать?
Первая причина историческая. Долгое время браузеры догоняли экосистему, выросшую поверх них: библиотеки вроде jQuery закрывали важные пробелы, пока браузеры реализовывали аналогичные API, а потом ещё приходилось ждать, пока устареют отстающие вроде IE6. Сейчас большинство браузеров обновляются непрерывно (про Safari автор говорит, что это спорно, но примерно 7 релизов в год, неплохо), однако примерно до 2020-х веб был «неровным», и писать своё было разумным решением.
Вторая причина, привычка: кто привык искать React-компоненты в npm, тот тянется к npm при любой задаче. Автор иронизирует, что по запросу «sticky positioning» в npm не найдётся пакета с советом «просто используй CSS position: sticky» (это его гипотетическая иллюстрация). Он также отмечает, что npm-библиотеки часто заполняли промежуток между удобством фреймворков и низкоуровневой платформой: например, библиотека виртуального списка может использовать «сырой» DOM ради скорости, а наружу отдавать более простые для новичка примитивы. Роль сыграла и документация: у npm-пакетов обычно подробные README, а документация по веб-платформе была разбросана по блогам, StackOverflow и сайтам вроде CSS Tricks, пока MDN не стал главным местом; многие из этих источников сами советовали взять jQuery или GreenSock.
Главную причину автор видит в другом: для определённого типа разработчиков писать самим просто интереснее, а такой код проще понимать, если нет энциклопедических знаний о платформе. Плюс срабатывает «эффект IKEA», хочется поддерживать и доводить собственную самоделку. Пример, модальное окно: позиционирование через position:absolute и z-index, блокировка прокрутки фона, обработка Esc, ловушка фокуса, возврат фокуса на вызвавший элемент, затем анимации, темы, кнопка закрытия, и вот уже библиотека, готовая для npm. Для одних это кошмар, для других веселье, куда интереснее, чем взять
При этом самоделки не всегда благо: иногда это чистое незнание. Автор считает, что обилие JavaScript-решений там, где лучше справился бы CSS, во многом вызвано тем, что разработчики не потратили время, чтобы глубоко понять CSS. Он оговаривается, что CSS исторически сложен (clear fix, float, трюк min-width: 0), проще вообразить императивную логику и записать её на JavaScript, а годами в CSS не было простого способа для частых задач, обрезки текста по числу строк (line clamping), изменения размера textarea, скрытия полосы прокрутки.
Явление не ограничено вебом. В своей работе автор использует ClickHouse для аналитических данных. Они с коллегой расходились во мнениях, как хранить крупные JSON-данные в колонке: коллега сделал систему сжатия перед записью, а автор клал данные в отдельное key-value-хранилище, а в ClickHouse вставлял только ключ. Оба оказались неправы: ClickHouse сжимает данные автоматически, и как колоночное хранилище даёт лучшее сжатие по строкам, если ему не мешать; отдельное key-value-хранилище было лишь «бедной версией» того, что уже делает колоночный SELECT. Понял это автор, только вдумчиво прочитав документацию и написав бенчмарк для проверки гипотезы; он был потрясён, что их решение оказалось медленнее и неуклюжее того, что платформа даёт из коробки. Числовых результатов бенчмарка в тексте нет. Автор предполагает, что похожие истории есть у разработчиков под iOS, Android и игровые движки, а «матёрый сеньор», заменяющий запутанный код джуниора одной строкой, стереотип именно об этом.
Наконец, об ИИ-кодинге у автора два предположения. Оптимистичное: у языковых моделей энциклопедические знания о платформе, и они выберут нужное платформенное API; такое решение, вероятно, быстрее и корректнее пользовательского кода, и агент предпочтёт его после тщательного тестирования и замеров; а «эффект IKEA» исчезает, когда код пишут не сами разработчики. Пессимистичное: модели любят дублировать код (например, игнорируют уже существующие вспомогательные функции и пишут свои), объём самописного, не идиоматичного для платформы кода взлетит, разработчики будут коммитить первый черновик агента, а агенты продолжат наращивать переусложнённые решения. Автор пишет, что видел оба явления в собственной работе с ИИ-кодингом, хотел бы верить в оптимистичный исход по мере улучшения моделей и инструментов, но не уверен. Итог: как мантру «use the platform» он любит, но сам бывал тем автором самоделок и знает радость от такого кода, поэтому считает важным понимать таких разработчиков; призыв, по его мнению, будет звучать, пока существуют платформы.
Ключевые факты
- Автор, сторонник принципа «use the platform», выступает адвокатом скептиков и объясняет, почему разработчики пишут своё вместо встроенных возможностей браузера.
- Причины, которые он называет: история (браузеры догоняли экосистему, jQuery закрывал пробелы, «неровный» веб примерно до 2020-х), привычка тянуться к npm, разбросанная документация до появления MDN и просто интерес к самостоятельной разработке с «эффектом IKEA».
- Не всё самодельное хорошо: часть решений возникает из незнания, например, JavaScript там, где лучше справился бы CSS; пример автора с ClickHouse показал, что и он с коллегой построили более медленное и неуклюжее решение, чем встроенное.
- Об ИИ-кодинге у автора два предположения: оптимистичное (агент выберет платформенное решение после тестов и замеров) и пессимистичное (рост дублирующего самописного кода); он видел оба явления, но однозначного вывода не делает.
- Это авторское эссе-мнение без опросов и статистики: аргументы строятся на личном опыте и рассуждении.
Почему это важно
Эссе проясняет, почему призыв «use the platform» работает хуже, чем кажется его сторонникам. Автор показывает, что сопротивление не сводится к лени: за ним стоят история веба, привычка к npm, плохо организованная документация и удовольствие от самостоятельного конструирования. Отдельный интерес, его мысль, что нынешние сторонники принципа сами когда-то писали полифилы и библиотеки и именно так изучали платформу. Это не новость и не открытие, а осмысление давно известного поведения разработчиков.
Кому это важно
Веб-разработчикам и техническим руководителям, которые решают, писать компонент самим или взять встроенное средство браузера (например,
Как это применить
Практические выводы, которые следуют из текста: прежде чем строить своё, потратить время на документацию платформы и на замеры. Автор сам понял ошибку с ClickHouse только после внимательного чтения документации и написания бенчмарка. В вебе же стоит проверить, нет ли встроенного решения (для модального окна,
Можно ли доверять
Это личное мнение разработчика с опытом в браузерных API (годы работы над PouchDB, участие во встречах W3C, issues и pull requests в спецификации IndexedDB). Автор сам называет свои мысли «многословными и несколько противоречивыми» и не заявляет, какая сторона права. В тексте нет опросов, статистики или исследований о том, как часто разработчики избегают платформы; пример с ClickHouse, личный случай без числовых результатов бенчмарка. Рассуждения об ИИ, предположения, а не выводы по данным; названий конкретных инструментов или моделей автор не приводит. Оценка Safari «около 7 релизов в год» дана вскользь и приблизительно.
Риски и подводные камни
Главный риск самописного кода, незнание: решения на JavaScript там, где лучше справился бы CSS, и более медленные и неуклюжие самоделки, чем встроенные возможности платформы. Второй, «эффект IKEA»: привязанность к собственному коду, который хочется поддерживать и дорабатывать. Для ИИ-кодинга автор видит риск, что модели будут дублировать код и усложнять решения, а разработчики не станут требовать достаточного тестирования. Обратная сторона: без пробела в платформе, который нужно закрыть, у части разработчиков могло бы не появиться мотивации дойти до глубокой экспертизы; автор не уверен, что сам достиг бы её.
«Я уверен, что призыв «использовать платформу» будет звучать, пока существуют платформы.»
— Автор эссе