JS Module History
[JS History](https://texonom.com/js-history-a2e9f4d79cc14d1db285e22f4056eeed)  [HTTP History](https://texonom.com/http-history-5ced2f1f555e44c4a5e1f0c5031e6762) [Web App History](https://texonom.com/web-app-history-14e51d2e6c684eee976d31bb50e30e3f) 


- ajax(xhr), jquery이후 2005 부터 2009 사이 js 개발자들 scalable한 코드 관리 욕심 생김
- <script/> 너무 많아지고 관리 안댐
> - 스코프 문제
> - 의존성 관리 문제 (로드 순서)
> - 로드시간 문제 (defer)
- 여러 차례 http request 날리는 것이 문제 http 1.1이라
- 2009년 1월, 모라 엔지니어 Kevin Dangoor를 중심으로 JS 모듈화 표준을 만들고자 하는 commonJS 그룹이 결성
- 3개월 뒤 commonJS API 0.1을 발표 (JS 모듈화의 0년)
- 2009년  nodeJS 등장하고 cjs 차용
- 서버사이드의 서버사이드 모듈화 표준이 목적이어서 브라우저 문제 해결 못해줌
- CJS 너무 오래 걸림 모듈 로드 동기적 blocking [CJS](https://texonom.com/cjs-61d87c3c7fe4483d967aa40c66958381) 
- event loop 덕분에 async하게 돌아갈 수 있는 v8 2008 나온걸 이용해서 AMD 등장 
> - amd에 기반한 모듈로더 [RequireJS](https://texonom.com/requirejs-44473dd651684ea3a680e302141a18ae) 
> - CJS 의 동기적 모듈 로딩 방식을 비동기로 한건 좋았지만
> - AMD 모듈화 기법이 대세를 거슬러서 개발자들이 서버사이드용 코드, 브라우저용 코드를 따로 작성해나가고 있다는 점이 문제
> - CJS 스타일 기반의 nodeJS로 자바스크립트기반 서버를 개발하고, npm으로 패키지를 모듈로 장착하고 싶었던 개발자들에게 AMD는 계륵
- 2010년 즈음, npm이 등장
- 개발자들 모듈 올리며 이들은 대부분 CJS 형식으로 만들어서 . CJS 스타일로 만든 코드를 AMD 스타일로 변환해야할 상황이 많아짐
- 이 문제를 해결하기 위해 등장한 것이 모듈 번들러, Browserify

> [What are CJS, AMD, UMD, and ESM in Javascript?](https://dev.to/iggredible/what-the-heck-are-cjs-amd-umd-and-esm-ikm)

> [자바스크립트 모듈 제공을 위한 AMD, CommonJS 그리고 RequireJS 소개](https://blog.pigno.se/post/157992405313/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EB%AA%A8%EB%93%88-%EC%A0%9C%EA%B3%B5%EC%9D%84-%EC%9C%84%ED%95%9C-amd-commonjs-%EA%B7%B8%EB%A6%AC%EA%B3%A0-requirejs-%EC%86%8C%EA%B0%9C)

> [웹팩(3/4); JS모듈화 역사 돌아보기(1)](https://medium.com/@chullino/%EC%9B%B9%ED%8C%A9-3-4-js%EB%AA%A8%EB%93%88%ED%99%94-%EC%97%AD%EC%82%AC-%EB%8F%8C%EC%95%84%EB%B3%B4%EA%B8%B0-1-9df997f82002)





