docs: 챕터 10 추가 (#87)

챕터_10/백지연.md

@@ -0,0 +1,106 @@
+# CHAPTER 10 모듈형 자바스크립트 디자인 패턴
+
+ES2015 이전에 사용된 다양한 모듈 형식을 활용한 모듈형 자바스크립트 작성 방법
+
+## 스크립트 로더에 대한 참고사항
+
+AMD, CJS 같은 모듈형 자바스크립트를 이해하기 위해서는  
+모듈형 자바스크립트를 구현하기 위한 도구인 **스크립트 로더**에 대해 알아야 함
+
+## AMD (Asynchronous Module Definition, 비동기 모듈 지원)
+
+- 모듈과 의존성 모두를 **비동기적으로 로드**할 수 있도록 설계된 모듈 정의 방식
+- 개발자가 활용할 수 있는 모듈형 자바스크립트 솔루션을 제공하는 것이 목표
+- 비동기적이면서도 높은 유연성을 가지고 있어 코드와 모듈 간 결합을 줄여줌
+- jQuery에 도입된 형식
+
+### 모듈 알아보기
+
+#### 중요 개념
+
+- 모듈 정의를 구현하는 `define` 메서드
+- 의존성 로딩을 처리하는 `require` 메서드
+
+### AMD가 모듈 기반 애플리케이션 개발에 좋은 이유
+
+- 유연한 모듈 정의 방식에 대한 명확한 제안을 제공
+- 전역 네임스페이스, `<script>` 태그 방식에 비해 구조화되어 있음
+- 모듈 정의가 독립적으로 이루어지기 때문에 전역 네임스페이스의 오염을 방지할 수 있음
+- 크로스 도메인, 로컬 환경, 디버깅 등에서 문제가 없으며, 서버 사이드 툴을 사용할 필요도 없음  
+  대부분의 AMD 로더는 빌드 과정 없이 브라우저에서 모듈을 로딩하는 것을 지원함
+- 여러 모듈을 하나의 파일로 가져오기 위한 transport 방식을 제공함
+- 스크립트의 lazy-load를 지원함
+
+### AMD 장점
+
+- 전역 객체의 사용에 대한 걱정을 줄여줌
+- 변수에 모듈을 할당할 수 있음
+- 브라우저 환경의 모듈 작동을 위해 서버 사이드에서의 변환이 따로 필요하지 않음
+- 의존성 관리 측면에서 효율적
+
+### AMD 단점
+
+boilerplate/wrapper code 작성이 귀찮음
+
+## CommonJS
+
+- **서버 사이드**에서 모듈을 선언하는 간단한 API를 지정하는 모듈 제안
+- AMD와 달리 I/O, 파일 시스템, 프로미스 등 **더욱 광범위한 부분을 다룸**
+- 모듈과 패키지 2가지에 대한 표준을 정립하려 노력했음
+
+### CommonJS 시작하기
+
+#### 구조적 관점
+
+- CommonJS 모듈은 재사용 가능한 자바스크립트 코드
+- 외부 의존 코드에 공개할 특정 **객체**를 내보냄
+- AMD와 달리 모듈을 함수로 감싸는 작업 X (ex. `define` 사용 X)
+
+#### 핵심 요소
+
+- `exports` 변수 : 다른 모듈에 내보내고자 하는 객체를 담음
+- `require` 함수 : 다른 모듈에서 내보낸 객체를 가져올 때 사용하는 함수
+
+### Node.js 환경에서의 CommonJS
+
+- CommonJS 모듈은 Node.js에서 사용할 자바스크립트 코드를 패키징하기 위해 등장
+- `require()` 함수를 호출하면 CommonJS 모듈 로더, `import()` 함수를 호출하면 ECMAScript 모듈 로더가 사용됨
+- Node.js에서 ES6 모듈 문법으로 작성된 라이브러리 실행할 경우, 내부적으로 CommonJS로 트랜스파일
+
+#### Node.js가 CommonJS 모듈로 인식하는 파일
+
+- `.cjs` 확장자를 가진 파일
+- 가까이에 위치한 `package.json` 파일에 type 항목이 commonjS로 되어있는 경우, `.js` 확장자를 가진 파일
+- 가까이에 위치한 `package.json` 파일에 type 항목이 존재하지 않는 경우, `.js` 확장자를 가진 파일
+- `.mjs`, `.cjs`, `.json`, `.node`, `.js` 이외의 확장자를 가진 파일
+
+## AMD vs CommonJS: 동상이몽
+
+AMD와 CommonJS는 서로 다른 목표를 가진 모듈 형식
+
+### AMD
+
+- 브라우저 우선 접근 방식을 채택하여 비동기 동작과 간소화된 하위 호환성을 선택
+- 파일 I/O에 대한 개념 없음
+- 객체, 함수, 생성자, 문자열, JSON 등 다양한 형태의 모듈을 지원
+- 브라우저에서 자체적으로 실행된다는 면에서 유연한 포맷
+
+### CommonJS
+
+- 서버 우선 접근 방식을 취하며 동기적 작동, 전역 변수와의 독립성, 미래의 서버 환경을 고려
+- 언래핑된 모듈을 지원하기 때문에 ES2015+ 표준에 가깝게 느껴짐
+- AMD에서 필수적인 define 함수를 사용하지 않아도 된다.
+- 오직 객체만을 모듈로써 지원
+
+> CommonJS의 문제점 (출처 : https://velog.io/@eunbinn/commonjs-is-hurting-javascript)
+>
+> - 모듈 로딩이 동기식입니다. 각 모듈은 불린 순서대로 하나씩 로드되고 실행됩니다.
+> - 트리셰이킹이 어렵습니다. 따라서 사용하지 않는 모듈을 제거하고 번들 크기를 최소화하기 어렵습니다.
+> - 브라우저 기반이 아닙니다. 이 모든 코드가 클라이언트 사이드에서 동작하도록 하려면 번들러와 트랜스파일러가 필요합니다.  
+>   따라서 CommonJS를 사용하면 빌드 단계가 길어지거나 클라이언트와 서버의 코드를 구분해서 작성해야 합니다.
+
+### UMD: 플러그인을 위한 AMD 및 CommonJS 호환 모듈
+
+브라우저와 서버 환경에서 모두 작동할 수 있는 모듈을 원하는 개발자에게는  
+기존 AMD와 CommonJS의 약점을 해결하는 방안이 필요했고, UMD 형식이 만들어짐 (아직 실험 단계)  
+AMD나 CommonJS를 대체하기 위한 것이 아니라, 다양한 환경에서 코드가 동작할 수 있도록 돕는 보조 도구