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

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

От автора: первая демонстрация языка, который должен был стать JavaScript, состоялась почти 25 лет назад. Язык был выпущен, как LiveScirpt, в бета-версии Netscape Navigator осенью 1995 года и переименован в JavaScript в том же году. В конце того же года я начал работу над первым изданием JavaScript («Бета-версия»), которое О’Рейли опубликовал как «бета-версию», и она вышла в августе 1996 года, то есть ему уже 24 года.

С седьмым релизом, выходящим всего через несколько недель, я хочу отправиться в путешествие по памяти и написать о некоторых старых странных функциях JavaScript и о ранней веб-платформе, о которой мы теперь, к счастью, можем забыть. Одна из причин того, что новое 7-е издание меньше 6-го, заключается в том, что я удалил справочный раздел. Но кроме того, я обнаружил, что в 2020 году уже много вещей больше не являются актуальными. Веб-совместимость останется навсегда (или, по крайней мере, намного дольше 25 лет), поэтому поставщикам браузеров, возможно, придется продолжать поддерживать старые и малоизвестные функции языка и платформы в течение длительного времени. Но нам больше не нужно забивать ими свой мозг.

Итак, вот некоторые функции JavaScript и веб-платформы, которые больше не увеличивают количество страниц «JavaScript: Полное руководство». Я с радостью прощаюсь с ними. (Я чувствую, что это звучит немного напыщенно, поэтому предупреждаю, что это не является подробным исследование; это только мои воспоминания о том, как все было в старые добрые времена):

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

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

JavaScript. Быстрый старт

Изучите основы 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).

В любом случае, сейчас на дворе 2020 год, и я обещаю, что новое седьмое издание моей книги не будет утомлять вас длительным объяснениям тех старых функций, которые лучше забыть.

Автор: David Flanagan

Источник: https://davidflanagan.com

Редакция: Команда webformyself.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Смотреть

Метки:

Похожие статьи:

Комментарии Вконтакте:

Комментарии Facebook: