JavaScript의 목적 분석_기본지식

오늘부터 나는 JavaScript 읽기 경험에 대한 나의 ppk를 이 블로그에 계속 게시할 것입니다. ppk는 제가 존경하는 웹 개발자로, JavaScript 개발자로서 다른 개발자들이 관심을 두지 않거나 일부러 무시하는 웹 표준, 사용성, 접근성 등의 영역을 다루고 있다는 것 외에 다른 이유는 없습니다. 또한, 다양한 브라우저를 테스트하기 위해 많은 사례를 작성하고 JavaScript 인터페이스(API)의 호환성을 요약했는데, 이는 몇 년 동안 JavaScript 개발자에게 중요한 참고 자료가 되었지만 이러한 연구 정신은 많은 사람들에게 부족합니다.
PPK가 올해 9월에 책을 출간했는데, 제가 작년부터 기다려온 책이에요. 오늘 받았는데 빨리 첫 장을 읽고 싶었어요. 정말 놀라움으로 가득 차 있고 그의 기술은 대단합니다. 비록 저는 초보자이지만 이미 올바른 학습 경로를 밟고 있다고 생각합니다. 제가 배운 경험을 공유하면 공부하는 사람들도 보고 함께 소통하고 발전할 수 있을 거라 생각해요. 비록 저에게서 영감을 얻을 수 있을지는 장담할 수 없지만, 제가 쓴 이 노트들은 분명 있을 거에요. 귀하의 복사 및 붙여넣기 코드 학습 방법이 더 정확합니다.

이 책은 10개의 장으로 구성되어 있으며 장 이름은 목적, 배경, 브라우저, 준비, 핵심, BOM, 이벤트, DOM, CSS 변경 및 데이터 수집 등 간결하고 명확합니다. 자바스크립트의 모든 면을 이렇게 간결하게 설명한 책은 지금까지 없었기 때문에 학습이 그다지 부담스럽지 않을 것입니다. 서문이 너무 많으면 안 되므로 첫 번째 장의 학습 노트부터 시작하겠습니다.

개방 원리: JavaScript의 목적은 웹 페이지에 특별한 유용성 계층을 추가하는 것입니다. 간단해 보이지만 이 황금률은 종종 오해를 받습니다. 유용한 JavaScript를 작성하더라도 개발자는 웹 표준 운동의 발전과 HTML 페이지의 최신 접근성 등을 적절하게 맥락화하지 못할 수 있습니다. 더 나쁜 점은 일부 개발자가 웹 페이지에 유용성 레이어를 추가하는 대신 전체 레이어로 대체한다는 것입니다. 그 결과 브라우저가 JavaScript를 지원하지 않으면 웹 사이트가 망가집니다.

개념 개요
JavaScript는 브라우저에서 해석되는 스크립트 언어입니다. 서버 측이 아닌 클라이언트 측에서 양식 유효성 검사 및 새 메뉴 생성과 같은 특정 상호 작용을 처리하여 웹 사이트에 유용성을 추가합니다. 전통적인 웹 페이지 상호 작용에서는 클라이언트가 수행하는 모든 움직임이 서버를 통해 피드백되어야 합니다. 오래 기다리면 사용자가 충돌하게 됩니다. JavaScript는 서버 측 대신 클라이언트 측에서 특정 작업(가장 확실한 것은 양식 유효성 검사)을 수행하여 사용자 경험을 향상시킬 수 있습니다.

시대가 발전함에 따라 JavaScript는 점점 더 많은 상호 작용을 처리할 수 있습니다. 질문이 생깁니다. JavaScript는 너무 많은 일을 할 수 있는데, 어느 정도 사용해야 할까요? 이것은 부자와 마른 사람의 대결입니다. 전체 페이지에서 상호 작용을 제어하기 위해 JavaScript를 사용해야 합니까, 아니면 사용성을 향상시키기 위해 일부 JavaScript를 추가해야 합니까? 즉, JavaScript를 최대한 많이 사용합니까, 아니면 드물게 사용합니까, 아니면 사용하지 않습니까?

씬 클라이언트는 클라이언트-서버 통신에 크게 의존하는 반면, 리치 클라이언트는 추가 데이터 통신을 최대한 제한합니다.

어떤 방법이 좋을까요? 리치 클라이언트는 유용성 이점을 제공하지만 씬 클라이언트는 아마도 JavaScript의 "표준" 사용에 더 가깝습니다. 웹은 인터페이스의 모음이 아니라 문서의 모음으로 간주됩니다. 가장 확실한 증거는 브라우저에 문서로 이동할 수 있는 뒤로 및 앞으로 기능이 있고 인터페이스가 거기에 있다는 것입니다. 브라우저 북마크(bookmark) 문서는 가능하지만 인터페이스는 가능합니까? 접근성 측면에서 씬 클라이언트는 오류 발생 가능성도 적습니다.

이런 불균형은 해결하기 어렵습니다. 물론, 리치 클라이언트는 더욱 발전된 인터페이스에서 앞으로 이동하거나 뒤로 이동하거나 수집할 수도 있으며, 완벽한 접근성도 달성할 수 있습니다. 이를 위해서는 많은 추가 작업이 필요하지만 모든 프로젝트에 예산을 초과할 시간이나 자금이 있는 것은 아닙니다. 또한, 사용성에 너무 치중하고 접근성을 무시하는 것도 문제입니다.

그렇다면 JavaScript는 리치 클라이언트 또는 씬 클라이언트에 서비스를 제공하도록 설계되었습니까? 대답은 다음과 같습니다. 상황에 따라 다릅니다. 귀하의 웹사이트, 청중, JavaScript 수준에 따라 다릅니다.

기술 개요
JavaScript는 코어, BOM(브라우저 개체 모델), 이벤트, DOM(문서 개체 모델), CSS 변경 및 데이터 수집(XMLHttpRequest)이라는 6가지 측면으로 나뉩니다.

고대에는 NetScape가 선두를 달리던 시절에는 NetScape3가 사실상의 표준이었습니다.

현대는 그렇게 단순하지 않습니다. ECMA는 JavaScript Core를 표준화하고, W3C는 DOM을 표준화하며, BOM은 아직 WHAT-WG에 의해 표준화 과정에 있으며, W3C는 XMLHttpRequest의 첫 번째 초안을 방금 출시했습니다. 오늘날 BOM은 여전히 ​​NetScape3의 사실상 표준을 따르고 있으며 XMLHttpRequest는 여전히 Microsoft의 원래 사양을 따릅니다.

JavaScript의 목적은 사용자의 개인 정보 보호 및 보안을 훼손하는 것이 아니라 웹사이트의 유용성을 높이는 것입니다. 따라서 JavaScript는 사용자의 파일(쿠키 제외)을 읽거나 쓰는 것을 허용하지 않으며 동일 출처 정책을 채택하고 동일한 도메인에서의 상호 작용만 허용합니다. 기록 읽기가 허용되지 않으며 파일 업로드 양식에 값을 설정할 수 없으며 JavaScript로 제어되는 창을 닫으려면 사용자 확인이 필요하며 JavaScript로 열린 창은 100×100 창보다 작을 수 없으며 창 밖으로 이동할 수 없습니다. 화면.

JavaScript의 역사
역사를 탐구하면 JavaScript가 왜 그렇게 오해되는지 이해하는 데 도움이 됩니다.JavaScript는 Brendan Eich에 의해 만들어졌으며 NetScape 2에서 처음 구현되었습니다. 그 목적은 개발자가 코드를 복사하고 조정하기만 하면 쉽게 웹 페이지에 상호 작용 기능을 추가할 수 있을 만큼 간단한 언어를 만드는 것입니다. 많은 JavaScript 개발자가 복사 및 붙여넣기 작업을 시작한다는 점에서 이는 정말 인상적입니다.

안타깝게도 JavaScript의 이름과 구문이 잘못되었습니다. 원래는 LiveScript라고 했는데 1996년에 Java가 뜨거웠고 NetScape가 이를 타고 싶어 했기 때문에 특정 제품 관리자(누구였는지 궁금합니다. ㅎㅎ)가 이름을 바꾸라고 지시하고 Brendan Eich에게 주문했습니다. "Java와 같은 Javascript"를 만들기 위해. 이로 인해 많은 사람들은 JavaScript가 Java의 낮은 수준 버전이고 진지한 프로그래머의 관심을 끌 수 없다고 잘못 믿게 됩니다.

1996년에는 NetScape 3가 최고였으며 Microsoft는 이를 복사할 수밖에 없었습니다. 물론 이는 보기 드문 조화의 시기였습니다. 당시의 브라우저는 지금보다 "더 얇았으며" 형식 확인 및 마우스 회전과 같은 몇 가지 작은 트릭으로 제한되었습니다.

다음 단계는 광범위한 브라우저 전쟁입니다. 시장 경쟁을 위해 두 브라우저는 서로 다른 것을 구현했으며 각각은 사실상의 표준이 되기를 원합니다. 가장 유명한 것은 NetScape 4의 document.layer와 IE 4의 document.all입니다(잊으세요!). 그들은 DHTML을 대중화시켰습니다.

1999년 Microsoft는 CSS와 DOM을 잘 지원하는 IE5를 출시하여 승리했습니다. NetScape는 무너졌고 마침내 CSS라는 혁명이 일어날 충분한 시간을 갖게 되었습니다. WaSP는 CSS로 시작되었으며 많은 전문가들이 이 혁명을 가능하게 하는 많은 브라우저 해결 방법을 발견/발명했습니다.

2003년 일부 선구자들은 CSS 혁명의 영향으로 새로운 JavaScript 스타일을 탐구하기 시작하여 접근성에 더 많은 관심을 기울이고 사람들의 나쁜 평판을 바꾸는 것, 즉 눈에 띄지 않게 변경하는 것입니다. HTML 구조에서 JavaScript를 변경하면 레이어가 분리됩니다. 불행하게도 브라우저 전쟁에서 살아남은 프로그래머들은 이 새로운 길을 발견하지 못했을 수도 있습니다.

2005년 Ajax 열풍은 JavaScript 커뮤니티에 새로운 피를 불어넣었습니다. 그러나 어떤 측면에서 Ajax는 DHTML과 너무 유사합니다. 접근성은 많은 Ajax 애플리케이션의 말할 수 없는 비밀입니다. 열풍은 기술(Ajax 사용 방법)에 초점을 맞추는 경향이 있는 반면 유용성과 상호 작용성(Ajax 이유)은 과소평가됩니다. 결국 다양한 비대해진 라이브러리(현재는 프레임워크라고 함)가 빠르게 발전했습니다.

Ajax는 여전히 전속력으로 전진하고 있지만 이는 DHTML처럼 끝날 것이며 사람들은 점차 흥미를 잃고 무너질 것입니다.

자바스크립트의 흥망성쇠에는 어떤 '법칙'이 지배하는 것 같습니다. 우리는 이 악순환을 끊을 수 있을까요? 무슨 일이 있어도 JavaScript 개발자는 모든 종류의 멋진 코드와 화려한 프레임워크를 찾는 것 외에도 JavaScript가 표준을 준수하고 장벽이 없는 웹 페이지에서 실행될 수 있도록 작업을 조정해야 합니다.​