JavaScript가 될 언어의 첫 번째 데모는 거의 정확히 25 년 전에 진행되었습니다.

이 언어는 1995 년 가을 Netscape Navigator 베타에서 LiveScirpt로 출시되었으며 그해 말에 JavaScript로 이름이 변경되었습니다. 그해 말에 저는 JavaScript : The Definitive Guide의 첫 번째 판 (O'Reilly에서 이를 "베타 판"으로 출판)에 대한 작업을 시작했으며 1996 년 8 월에 출판되었습니다. 

몇 주 만에 일곱 번째 판이 나올 때, 나는 자바 스크립트와 우리가 자비 롭게 잊어 버릴 수 있는 초기 웹 플랫폼의 오래된 이상한 기능에 대해 메모리 레인과 블로그를 둘러보고 싶다.

새 7 번째 에디션이 6 번째 에디션보다 얇은 이유 중 하나는 참조 섹션을 삭제했기 때문입니다. 그러나 2020 년에는 더 이상 웹 개발자와 관련이 없는 것들이 많았습니다.

웹 호환성은 영원히 (또는 25 년 이상) 지속되므로 브라우저 공급 업체는 오래되고 모호한 언어 및 플랫폼 기능을 오랫동안 계속 지원해야 할 수 있습니다. 그러나 우리 나머지는 더 이상 우리의 마음을 어지럽힐 필요가 없습니다.

여기에 더 이상 JavaScript : Definitive Guide의 페이지 수를 늘리지 않는 JavaScript 및 웹 플랫폼 기능이 있습니다. 그들에게 작별 인사를 하게 되어 기쁩니다. (나는 여기에 약간의 맹렬한 소리가 나고 있다고 느낀다. 따라서 이것이 신중하게 연구되지는 않았고, 나쁜 옛날 시절의 일에 대한 나의 기억 만)

ES6에서 ... args를 도입하여 arguments 객체를 완전히 제거했습니다. 명명 된 인수와 상호 작용하는 이상한 방법을 설명하고 성능 관련 사항에 대해 항상 주의를 기울이는 것은 항상 어려운 일이었습니다. 레거시 코드에서 여전히 볼 수 있으며 엄격 모드에서 로컬 변수 또는 함수 매개 변수 인수의 이름을 지정하려 고하면 그 존재를 상기 시킬 수 있지만 이제 나머지 인수가 있으므로 망각에 빠질 수 있어야 합니다.

우리는 반복 된 문자열 연결의 성능에 대해 걱정해야 했습니다. 우리 모두는 문자열을 배열로 푸시하고 마지막에 join()을 사용하여 모든 것을 연결하는 법을 배웠습니다. 그런 다음 JavaScript가 빨라지고 우리는 모두“실제로”그 패턴을 배우지 못했습니다. 그리고 이제 더 이상 문자열 연결을 사용하는 템플릿 리터럴이 있습니다!

document.write()는 DOM 이전에 JavaScript의 주요 기능이었습니다. (20 세기에 JavaScript를 사용하지 않았다면 DOM 이전에 시간이 있었음을 알 수는 있지만 사실입니다. 웹 페이지의 배경색을 변경하도록 설정할 수 있는 속성이 있었지만 그 방법은 없습니다 IIRC를 사용하면 document.write()를 사용하여 문서에 스크립트를 삽입 할 수도 있지만 닫는 </ script> 태그를 두 개의 문자열로 분리해야 합니다. HTML 파서는 그것을 현재 실행 중인 스크립트의 끝으로 해석하지 않습니다.

HTML에는 초기에 <iframe>이 없었지만 <frameset>과 <frame>이 있었습니다. window.frames 속성은 문서의 프레임을 나타내는 중첩 된 윈도우 객체의 배열입니다. 실제로 프레임에서 문서의 open() 메서드를 호출 한 다음 document.write()를 사용하여 해당 프레임 안에 전체 문서를 동적으로 생성 할 수 있습니다. 실제로는 시원했습니다. 프레임은 다른 프레임 안에 중첩 될 수 있으므로 모든 Window 객체에는 자식 프레임을 포함하는 프레임 배열과 포함 창을 참조하는 부모 속성 및 최상위 창을 참조하는 최상위 속성이 있습니다. 필자의 저서 초판은 긴 부분과 이 모든 것을 설명하는 복잡한 그림을 다뤘습니다.

문서 내의 특정 요소를 참조하기 위한 모든 종류의 사용되지 않는 기술이 있습니다. 프레임 배열은 하나였지만 IIRC에는 문서의 모든 링크와 이미지 목록 인 링크와 이미지 배열도 있었습니다. 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 사람들이 침투했다고 약속했습니다. HTML 문서로 작업하는 JavaScript 프로그래머 및 XML 데이터로 작업하는 Java 프로그래머가 사용하는 단일 API. 그렇기 때문에 Attr 노드와 같은 이상한 것들이 있습니다. DOM Level 3 API에 대해 항상 나를 괴롭힌 것 중 하나는 문서에서 요소 e를 제거하기 위해 오늘날처럼 e.remove()를 작성할 수 없다는 것입니다. 실제로 e.parentNode.removeChild(e)를 작성해야 했습니다.

어쨌든, 지금은 2020 년이며, 제 새로운 저서 7 판은 잊어 버린 가장 오래된 기능들에 대해서는 긴 설명을 하지 않겠다고 약속합니다.