모듈 시스템
최초의 모듈 시스템
<html> <script src="./src/dev.js"></script> <sciprt src="./src/react.js"></script> </html>
- html에서 js 소스코드를 제공
문제점- 순서대로 로드 시에 모듈간에 충돌 발생(dev, react 파일간의 변수 충돌)
- 모듈 간의 스코프가 구분되지 않아 파일을 오염
변화의 필요성- 단순히 문서를 보여주는 것에 그치지 않고 js를 활용한 다양한 개발
- 2008년 Google의 V8 엔진 공개 및 서버 사이드에서 js 활용하자라는 말이 나옴
- 2009년을 기점으로 모듈의 표준화를 하기 위한 여정이 시작
CommonJS
- js를 브라우저에서 뿐만 아니라
서버 사이드 애플리케이션등 조금 더 범용적으로 사용하기 위한 모듈 시스템을 만들기 위한 조직
동기적으로 모듈을 호출하는 방식
// 모듈 정의 module.exports = park; // 모듈 사용 const foo = require("./park");
문제점- 비동기 방식보다 느림
트리 쉐이킹(사용되지 않는 코드를 제거하는 방식 등 최적화와 관련된 용어)이 어려움- 비동기를 고려하지 않았기 때문에 브라우저에서는 사용할 수 없음(고민)
AMD(Asynchronous Module Definition)
비동기 상황에서도 JS 모듈을 사용하기 위해 CommonJS에서 함께 논의하다 결국 합의점을 찾지 못해 독립한 그룹
- 브라우저의 모듈 실행을 우선적으로 해야한다는 생각에 기인하여 만들어짐(기존에 브라우저에서 필요한 모듈들은 네트워크를 통해 비동기 다운로드를 하는 수고)
- CommonJS보다 더 나은 성능
- (소스코드는 아래 참고에 정리한 첫번째 웹 사이트 있습니다.)
UMD(Universal ModuleDefinition)
- CommonJS와 AMD간의 통일되지 않은 규격으로 인해 호환성 문제가 발생 했고 이 문제를 해결하기 위해 등장
- CommonJS와 AMD를 동시에 사용할 수 있도록 분기를 통해 분리하고, 이것을 팩토리 패턴으로 구현
문제점- 호환성은 어느정도 보완했지만
모듈 시스템의 부재라는 문제는 해결 하지 못함
ES6 Module
- 2015년 JS 자체에서 표준 모듈 시스템 명세,
ES6 Module(ES Module)
import park from './src/park.js/' export default park;
- 동기, 비동기 로드 지원
- 정적 분석 가능 ⇒ 코드를 실행하지 않아도 분석이 가능해
트리쉐이킹쉬워짐
문제점- 구형 브라우저에서 제대로 동작하지 않는 문제 발생
트랜스파일러
- ES6에 제공하는 표준 모듈 문법이 구형 브라우저에서도 동작하는 js 코드로 바꾸기 위해 도입
- 바벨 ⇒ 개발을 할 때는 최신 문법을 사용하고 바벨을 통해 구형 브라우저에서도 돌아갈 수 있는 코드로 바꿔주므로 개발자의 호환성 및 최신 문법을 사용함에 있어 걱정을 덜어줌
- TS ⇒ JS의 슈퍼셋 언어로서 꼭 JS 문법을 쓸 필요 없이 귀찮은 모듈 시스템 관리는 컴파일러가 대신하도록
태스크 러너 및 모듈 번들러
태스크 러너
- 모듈 시스템을 발전 시킨 이유는
스코프가 구분되는 모듈을 만들기 위함 ⇒ 여러 모듈을 조합, 중복 제거를 통해 생산성 높은 애플리케이션 개발
- 좋은 애플리케이션을 개발하기 위해서는
린팅, 테스팅, 빌딩과 같은 일련의 과정이 필수적으로 동반 됨
- 위에 말한 이러한 과정을 직접 하기보다는
자동화를 하면 더 효율적이라는 생각에 기인해태스크 러너가 등장
- Grunt와 Gulp는 테스트, 린트, 번들, 최적화 플러그인을 제공하고 이 과정들을 자동화 함으로써 많은 프론트엔드 개발자에게 도움을 줌
모듈 번들러
- JS 모듈을 브라우저에서 실행할 수 있는 단일 JS 파일로 번들링 하는데 사용되는 프론트엔드 도구
모듈 번들러 사용 이유- 모든 브라우저가 모듈 시스템을 완전히 지원하지 않음
- 코드의 종속성 관계의 이해에 도움
- 종속성 순서, 이미지, CSS 에셋 등을 로드하는 데 도움
- 최근에 번들러 자체에 개발과 빌드, 최적화를 위한 플러그인을 제공해서 태스크러너를 사용하지 않는 경우도 있음
Webpack
.png?table=block&id=1f546475-7485-4388-8677-31d49eedecd9&cache=v2)
- 생태계가 풍부하고 안정성이 뛰어난 번들러
- 서브파티 라이브러리 관리나 CSS 전처리, 이미지 에셋 관리 등에 있어 다른 번들러 보다 강점
- 웹팩에서 제공해주는 개발 서버 역시 다른 번들러에 비해 뛰어남
- ES6 모듈 형태로 번들링 되지 않고 복잡한 문서 및 초기 세팅이 어려워 진입 장벽이 높음
Rollup
- ES6 모듈 형식으로 결과물을 볼 수 있음
- 코드 스플리팅(지금 당장 필요한 코드가 아니라면 따로 분리시켜서, 나중에 필요할 때 불러와서 사용) 측면에서 다른 번들러와 비교해 강점
Parcel
- 웹팩은 js 엔트리 포인트를 설정해주어야 하지만 PACEL은 HTML 파일 자체를 읽음
- 별도의 설정 파일없이 설치 후 빌드 명령어를 입력해 바로 사용 가능
- 트랜스파일러도 간편하게 설정 ⇒ 웹팩과 롤업의 경우 CSS나 이미지와 같은 것을 번들에 추가하려면 일일이 설정해야 하지만 트랜스파일에 대한 기본 제공
- 좁은 생태계와 떨어지는 안정성 문제가 있음
