|
| 1 | +### AMD |
| 2 | +- 비동기적이고 동적으로 모듈 로드 |
| 3 | + - 초기 로딩 시간 감소 (비동기) |
| 4 | + - 필요한 모듈을 적절할 때 로드 (동적) |
| 5 | +- 브라우저 환경을 위함 |
| 6 | +- 스크립트 로더: RequireJS, curl.js |
| 7 | +- 장점 |
| 8 | + - 독립적인 모듈과 의존성을 명확하게 선언 |
| 9 | + - 전역 네임스페이스 오염 방지 |
| 10 | +- 단점 |
| 11 | + - 서버사이드와 호환 되지 않음 |
| 12 | + - ESM의 표준화에 따라 사용빈도 줄어듦 |
| 13 | + |
| 14 | +### CommonJS |
| 15 | +- 동기적이고 동적으로 모듈 로드 |
| 16 | +- Node.js에서 사용 |
| 17 | +- `require()`, `exports`로 활용가능 |
| 18 | + |
| 19 | +### UMD |
| 20 | +- 브라우저와 서버에서 모두 동작이 가능한 형태 |
| 21 | + |
| 22 | +### ESM |
| 23 | +- 표준 모듈 시스템 |
| 24 | +- `import`, `export` 키워드 사용 |
| 25 | +- 정적 분석이 가능 |
| 26 | + - 선언적으로 작성하며, 파싱 시점에 구조를 파악가능 |
| 27 | +- 의존성 트리 구축 가능 |
| 28 | +- 트리쉐이킹 원활 |
| 29 | +- 순환 참조 감지 가능 |
| 30 | + -> 효율적이고 예측가능한 코드 작성 가능 |
| 31 | +- 정적 분석 과정이 있어 CJS보다는 느리다 |
| 32 | + |
| 33 | +- 요즘엔 서버에선 CommonJS, 브라우저에선 ESM 주로 사용 |
| 34 | +- ESM이 표준이지만 이미 CommonJS로된 오픈소스들이 많음 |
| 35 | +- CommonJS와 ESM은 호환되지 않는다. |
| 36 | + - ESM에서 CJS를 `import` 할 수는 있으나 default import만 가능하다. |
| 37 | + - 반대는 쉽지 않다. (특히 top-level await 때문에) |
| 38 | + |
| 39 | + |
| 40 | + |
| 41 | + |
| 42 | + |
| 43 | + |
| 44 | +> 정리 : |
| 45 | +> CommonJS는 Node.js 환경에서 주로 사용되며, require()와 module.exports를 사용하여 모듈을 가져오고 내보냄 |
| 46 | +> ES Module은 최신 JavaScript 표준으로, import와 export 키워드를 사용함 |
| 47 | +> 둘이 비교하면, CommonJS는 동기적으로 모듈을 로드하는 반면, ES Module은 비동기적으로 로드함 |
| 48 | +> 이는 ES Module이 브라우저 환경에서도 사용될 수 있도록 설계되었기 때문, 왜냐하면 브라우저 환경에서는 비동기 로드가 필수적이니까, 반면에 CommonJS는 서버 사이드에서 모든 모듈이 로드된 후에야 코드가 실행되어야 해서 동기적 로드가 유리한 조건임 |
| 49 | +> CommonJS는 트리 셰이킹(Tree Shaking)이 어렵다는 단점 존재함, 동적 로드 지원해서 그럼 ㅋㅋ |
| 50 | +> 반면, ES Module은 트리 셰이킹이 용이, 왜냐면 ES Module은 정적 분석이 가능하기 때문 |
0 commit comments