Чому розробники знову обирають власний код замість веб-платформи

Історія та звичка

Щоб зробити використання функцій браузера корисним, основними аргументами замість власного JavaScript є продуктивність, зручність використання та доступність, але їх впровадження не завжди було простим. Для великої частини історії вебу браузери відставали від ширшої веб-екосистеми. Бібліотеки типу jQuery заповнювали значні прогалини, і розробникам часто доводилося чекати на застаріння старих браузерів, наприклад IE6, перш ніж використовувати нові API. У такому середовищі створення власного рішення поверх браузера було розумною відповіддю. Звичка також має значення: розробники React, які звикли шукати компоненти в npm, можуть шукати пакет, перш ніж розглянути CSS або API браузера. Обгортки (wrappers) роблять незнайомі функції платформи більш зрозумілими, а документація пакета часто була легшою для пошуку, ніж розсіяні знання про веб-платформу. MDN згодом став центральним напрямом документації, а web.dev був представлений як нова освітня ініціатива Google.

Привабливість створення

Для деяких розробників самостійна реалізація є задоволенням. Модальний діалог може початися з видимого позиціонування та прокрутки фону, а потім знадобиться обробка клавіші Escape, пастка фокусу та відновлення фокусу. Розробники можуть додавати анімації, теми або кнопку закриття, перш ніж перетворити результат на повторно використовуваний пакет. Джерело називає це ефектом IKEA, оскільки код, написаний вручну, може пробуджувати бажання зберігати та налаштовувати його. Власні інструменти також можуть бути способом навчання: автор працював з інструментами сховища, пов'язаними з IndexedDB, WebSQL та PouchDB, а згодом навіть зробив внесок у специфікацію IndexedDB. Ранні прогалини платформи сприяли появі поліфілів, шимів та бібліотек, що допомагало створювати експертизу платформи.

Проблеми знань та поведінка платформи

Не кожне власне рішення відображає обдумений компроміс; частина походить від неповних знань. Такі функції CSS, як float, clear fix та min-width: 0, були важкими для розуміння, а звичайні потреби, включаючи обмеження рядків, зміну розміру textarea та приховування смуги прокрутки, залишалися без прямих нативних рішень протягом років. Розробникам було легше виражати бажану поведінку в JavaScript. Приклад ClickHouse дав той самий результат. Один розробник стискав великий JSON перед зберіганням, а інший розміщував його в окремому key-value сховищі, зберігаючи в ClickHouse лише ключі. Після перегляду документації та бенчмаркінгу вони виявили, що ClickHouse уже стискає колонкові дані та забезпечує краще стискання між рядками, що робило окрему систему повільнішою та громіздкішою.

AI може змінити баланс

Кодування на основі AI може змінити цю поведінку в обох напрямках. Оптимістичний сценарій полягає в тому, що великі мовні моделі можуть спиратися на широкі знання платформи, вибирати відповідні нативні API з розпливчастих вимог і після тестування надавати перевагу швидшим і правильним функціям платформи. Оскільки розробники пишуть менше коду, прив'язаність до власних реалізацій може ослабнути. Песимістичний сценарій полягає в тому, що моделі можуть повторно створювати наявні помічники, обходити конвенції платформи та генерувати складні рішення без достатнього тестування. Автор бачить обидва результати і не може сказати, який стане домінантним, коли моделі та інструменти кодування розвиватимуться. Висновок полягає в тому, що використання платформи все ще цінне, але історія, звичка, проблеми документації, задоволення від створення та неповне розуміння пояснюють, чому розробники знову обирають власний код.