javascript가 최초 나왔을 당시, 웹 페이지의 규모는 지금과 같이 크지 않았다.
그러나 컴퓨터의 성능이 향상되고, 네트워크 속도가 빨라지며 웹 페이지 규모도 점차 커지게 되었다.
웹 페이지 규모가 커지다보니 javascript 코드 규모 또한 커지게 되었고, 중복되는 기능도 많았다.
그러다보니 중복되는 기능들을 하나의 모듈로 만들어 소스 코드의 규모를 줄이고, 재사용성을 좋게 하였다.
하지만, 이 당시 javascript 모듈 사용을 위한 방법에는 정해진 표준이 없었다.
표준 없이 뒤죽박죽 개발을 하면 개발자들간에 혼선이 생기게 되고, 언어 사용성이 떨어지게 된다.
이를 막기위해 CommonJS 와 AMD (Asynchronous Module Definition) 방식의 모듈 사용이 등장하게 된다.
또, ECMAScript 2015 (ES6) 부터는 모듈 포맷을 내장하여 제공하기 시작했다.
번들러를 사용하게 된 이유
네트워크 속도가 빠르다고 해서 웹 페이지가 완벽하게 로드되는 시간까지 빠른 것은 아니다.
웹 페이지를 구성하는 html, js, css 및 이미지 파일들이 많을 수록 그 갯수만큼 웹 서버에 요청을 하고 응답을 받게 된다.
여기서 동일한 타입의 파일끼리 묶어서 구성하면 웹 서버에 요청하는 수가 줄지 않을까??
이 역할을 번들러를 통해 할 수 있다.
예를 들어, 어떠한 웹 페이지를 로드하기 위해 html 파일 1개, js 파일 5개, css 파일 5개가 있다고 가정해보자.
한개의 파일을 요청/응답 받는데 걸리는 시간이 1초라면, 총 11초가 걸리게 된다.
하지만, 동일한 타입의 파일로 묶게되면 총 3초가 걸리게 된다.
이미지 출처: https://webpack.github.io/
javascript 번들러의 종류로는 여러가지가 있는데, 그 중에 대표적인 번들러로는
webpack, parcel, browserify 가 있다.
'Dev study 정리' 카테고리의 다른 글
componentDidCatch() 함수 확인 (4) | 2018.08.30 |
---|---|
[Web] 브라우저가 웹 페이지 리소스를 받아오는 과정 (0) | 2018.08.23 |
API를 사용하는 이유 (4) | 2017.07.23 |
Redux란? (2) | 2017.07.08 |
javascript 클로저 코드를 통해 알아보기 (1) | 2017.04.17 |