Функции JavaScript, которые можно забыть

Объект arguments был полностью устранен путем введения …args в ES6. Всегда было трудно объяснить странный способ взаимодействия с именованными аргументами и предупреждать о его последствиях для производительности. Вы по-прежнему можете видеть его в унаследованном коде, и вы можете вспоминать о его присутствии, если попытаетесь назвать локальную переменную или параметр функции arguments в строгом режиме, но теперь, когда у нас есть аргументы rest, ему стоит позволить уйти.

Раньше нам приходилось беспокоиться о производительности многократного объединения строк. Был период, когда мы все учились вставлять строки в массив, а затем использовать join() для объединения всего в конце. Затем JavaScript стал быстрым, и мы все сказали «Ну и хорошо» и перестали изучать этот паттерн. А теперь с литералами шаблонов, кому вообще нужна конкатенация строк!

document.write() был в значительной степени главной особенностью JavaScript в самом начале, до DOM. (Если вы не использовали JavaScript в 20-м веке, вы можете не знать, что было время до DOM, но это правда. Было свойство, которое вы могли бы установить, чтобы изменить цвет фона веб-страницы, но никак не могли изменить дерево документа после анализа документа.) Вы даже можете вставить скрипты в документ с помощью document.write(), но вы должны быть осторожны, чтобы не разбить закрывающий тег </script> на две строки, чтобы анализатор HTML не интерпретировал его как конец текущего запущенного скрипта.

В HTML не было в первые дни </iframe>/, но были </frameset>/ и </frame>/. Свойство window.frames являлось массивом вложенных объектов окон, представленных в документе фреймов. Можно было на самом деле вызвать метод документа open() во фрейме, а затем использовать его document.write() для динамической генерации всего документа внутри этого фрейма. Это было круто, на самом деле. Поскольку фреймы могут быть вложены в другие фреймы, каждый объект Window имеет массив frames, который содержит его дочерние фреймы, и свойство parent, которое ссылается на содержащее окно, и свойство top, которое ссылается на окно верхнего уровня. В более ранних изданиях моей книги объяснялись все это с помощью длинных разделов и сложных рисунков.

Существуют различные виды устаревших методов для ссылки на конкретные элементы в документе. Массив frames был одним из них, но, если мне не изменяет память, были также массивы links и images, которые являлись буквально просто списком всех ссылок и изображений в документе. IE (версия 4, я думаю) пошел ва-банк и представил document.all: массив всех элементов в документе. (Это было начало DOM и «DHTML» — вроде как первая рыба, которая вышла на сушу.) document.all имел всевозможные странные особенности: это был массив, который также содержал методы для поиска элементов по имени или что-то вроде как это. document.all никогда не был стандартизирован, но даже стандартные методы, такие как document.getElementById(), document.getElementsByName(), document.getElementsByTagName() и document.getElementsByClassName() кажутся устаревшим сегодня. Как ненужные функция х$() JQuery и методы document.querySelector() и document.querySelectorAll(), которые были этим вдохновлены. Из-за селекторов CSS эти две функции устарели.

Больше всего я ненавидел Internet Explorer за то, что он использовал метод регистрации обработчиков событий attachEvent(). На моей памяти они сделали это, хотя стандарт addEventListener() уже был определен, и это действительно раздражало меня. События и обработка событий были одним из крупнейших источников несовместимости в сети, и в течение многих лет программистам JavaScript (и авторам книг по JavaScript) приходилось иметь дело с длинным списком различий между моделью событий IE и стандартной моделью событий. Код обработки событий должен был быть написан дважды: один раз для IE и один раз для Firefox. Главы книг о событиях были вдвое длиннее, чем они должны были быть, потому что было два похожих, но совершенно несовместимых способа работы с ними. Одной из основных особенностей jQuery было то, что они реализовали собственный слой совместимости событий, поэтому вам нужно было знать только о событиях jQuery, и я подозреваю, что это было важной причиной его популярности.

Оригинальный DOM API был определен в эпоху магического представления о XML. (Похоже, в течение нескольких лет люди действительно верили, что XML решит все проблемы с данными. Это было странное время.) Каким-то образом W3C, определивший DOM API, проник в сознание Java-людей, которые считали целесообразным определить единый API, который будет использоваться программистами JavaScript, работающими с документами HTML, и программистами Java, работающими с данными XML. Вот почему у нас есть странные вещи, такие как узлы Attr (которые лучше игнорировать). В DOM API Level 3 меня всегда беспокоило то, что для удаления элемента e из документа вы не могли просто написать e.remove(), как сегодня. Вам на самом деле нужно было написать e.parentNode.removeChild(e).