Странные API браузера: почему pushState принимает лишний параметр

Поиграем? Назовите самое странное API браузера.

Если вы фронтендер, скорее всего вспомнили canPlayType(). Этот метод возвращает три значения: пустую строку («не поддерживается»), «вероятно» или «возможно». Какое-то вероятностное гадание, честно говоря.

Но есть кое-что ещё более показательное. Встречайте History.pushState() — настоящий памятник вебу, который не ломает старый код.

Вызывается он с тремя параметрами: state, title и url. State-объект понятен — хранит данные для восстановления при нажатии «назад». URL обновляет адресную строку без перезагрузки страницы.

А вот параметр title? Его просто игнорируют. Все браузеры без исключений отправляют его в /dev/null.

Так зачем он вообще нужен?

В 2008 году, когда API только появилось, кто-то решил: пусть приложения ставят свой заголовок для каждой записи в истории. Типа, SPA показывает «Панель управления», а в истории браузера лежит «Аналитика». Звучало логично.

Но разработчики браузеров быстро смекнули: будет путаница. Пользователь добавит страницу в закладки, а потом браузерные вкладки показывают одно, а закладка — другое. Разбираться с этим никто не хотел.

И они просто перестали использовать параметр. Но проблема: тысячи сайтов уже написали код с тремя аргументами. Убрать параметр — сломать прод. Сделать необязательным — сломать существующие вызовы pushState(state, url).

Поэтому в спецификации поступили изящно: параметр переименовали в unused и написали в документации, что он ни на что не влияет.

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

Именно эта философия — почему мы в NameOcean продвигаем статические сайты и проверенные технологии. Когда вы делаете что-то долговечное — медиаархивы, документацию, лендинги — стабильность ванильных веб-технологий это не ограничение, а преимущество.

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

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

В следующий раз, когда встретите странное API или deprecated-параметр, вспомните: кто-то когда-то принял решение, и теперь оно вмуровано в фундамент веба. Уважайте эту странность. Она держит всё в рабочем состоянии.