더이상 사용하지 말아야할 JS 기능들 / JavaScript Features To Forget

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

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

로 일곱 번째 에디션이 몇 주에 나오고, 나는 자바 스크립트의 우리가 지금, 자비, 잊을 수있는 초기 웹 플랫폼의 오래된 이상한 기능에 대한 기억을 더듬어 및 블로그 다운 여행을하고 싶다. 새 7 번째 에디션이 6 번째 에디션보다 얇은 이유 중 하나는 참조 섹션을 제거 했기 때문 입니다. 그러나 2020 년에는 더 이상 웹 개발자와 관련이없는 것들이 많았습니다. 웹 호환성은 영원히 (또는 25 년 이상) 지속되므로 브라우저 공급 업체는 오래되고 모호한 지원을 계속해야 할 수 있습니다 언어 및 플랫폼 기능이 오랫동안 사용되었습니다. 그러나 우리 나머지는 더 이상 우리의 마음을 어지럽 힐 필요가 없습니다.

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

• arguments개체가 완전히의 도입에 의해 없어진다 된 ...argsES6있다. 명명 된 인수와 상호 작용하는 이상한 방식을 설명하고 성능 관련 사항에 대해 항상주의를 기울이는 것은 항상 어려운 일이었습니다. 레거시 코드에서 여전히 볼 수 있으며 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 객체에는 frames자식 프레임을 포함 하는 배열과 parent포함 창 top을 참조 하는 속성 및 최상위 창을 참조 하는 속성이 있습니다. 필자의 저서 초판은 긴 부분과이 모든 것을 설명하는 복잡한 그림을 다뤘습니다.

• 문서 내의 특정 요소를 참조하기위한 모든 종류의 사용되지 않는 기술이 있습니다. frames배열이 또한 있었다, IIRC 일 이었지만, 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 사람들이 침투했다고 약속했습니다. HTML 문서로 작업하는 JavaScript 프로그래머 및 XML 데이터로 작업하는 Java 프로그래머가 사용하는 단일 API. 그렇기 때문에 Attr 노드와 같은 이상한 것들이 가장 좋은 이유입니다. DOM Level 3 API에 대해 항상 나를 괴롭혔던 것 중 하나는 e문서에서 요소를 제거하면 e.remove()오늘날처럼 쓸 수 없다는 것입니다. 당신은 실제로 썼다 e.parentNode.removeChild(e).

 

원문 : https://davidflanagan.com/2020/05/12/javascript-to-forget.html