범용적인 목적으로 JavaScript를 사용하기 위해 필요한 선결 조건은 모듈화이다
CommonJS
CommonJS(http://www.commonjs.org/) 는 JavaScript를 브라우저에서뿐만 아니라, 서버사이드 애플리케이션이나 데스크톱 애플리케이션에서도 사용하려고 조직한 자발적 워킹 그룹
웹팩이 필요한 이유
웹팩이 등장한 이유?
- 파일 단위의 자바스크립트 모듈 관리의 필요성
- 웹 개발 작업 자동화 도구 (Web Task Manager)
- 웹 애플리케이션의 빠른 로딩 속도와 높은 성능
1. 파일 단위의 자바스크립트 모듈 관리
자바스크립트의 변수 유효 범위는 기본적으로 전역 범위를 갖는다. 전역 범위를 갖기 때문에 어디에서도 접근하기 쉽다는 장점이 있지만, 실제 웹 애플리케이션을 개발할 때 서로 다른 모듈에서 같은 이름의 변수를 사용한다면 서로가 서로를 의도치 않게 변경할 수 있디.
이러한 이유 때문에 파일 단위로 변수를 관리하거나, 모듈화를 해야 했는데, 그 동안은 AMD, Common.js와 같은 라이브러리를 사용해왔다.
📌 CommonJs & AMD
CommonJs, AMD는 모듈화 라이브러리인데, CommonJs는 특유의 동기적인 특성으로 서버 사이드 개발에 사용하기 용이하고, AMD(Asynchronous Module Definition)이라는 이름 그대로 비동기적 모듈 선언으로 클라이언트 사이드 개발에 사용하기 용이했다(?)
모듈화는 크게 스코프, 정의, 사용 세 부분으로 이루어진다.
- 스코프(Scope) : 독립적인 실행 영역
- 정의 : exports 객체
- 사용 : require 함수
모듈은 자신만의 독립적인 실행 영역이 있어야하므로 전역변수와 지역변수를 분리하는것이 중요하다. 서버 사이드에서는 파일 스코프가 있어 파일 하나에 하나의 모듈을 작성한다면 전역 변수가 겹치지 않는다.
두 파일(모듈)을 공유하고자 한다면 exports 라는 전역 객체를 사용하고, 공유된 함수를 다른 모듈에서 사용할 때는 require 함수를 사용한다.
[ECMAScript] AMD, CommonJS 의 JavaScript 모듈화 | MINJUNG
CommonJs는 모든 파일이 로컬 디스크에 있어, 필요할 때 바로 불러올 수 있는 상황에서만 사용한다.
브라우저에서 이러한 방식은 필요한 모듈이 모두 다운로드 될 때 까지 아무것도 할 수 없는 상황이 발생한다.
그래서 비동기 방식으로 자바스크립트 모듈을 사용하는 API인 AMD를 만들었고, CommonJs 와 AMD가 서로 호환되지 않는 문제를 해결하기 위해 UMD (Univarsal Module Definition) 라이브러리가 등장했다.
이후 ES6 부터 추가된 자바스크립트 자체 모듈이 ESM(ECMAScript Module)이다.
EMS의 import와 export를 지원하지 않는 브라우저가 많으므로, 번들러를 함께 사용해야 한다.
2. 웹 개발 작업 자동화 도구
프론트엔드 개발 업무를 할 때 가장 많이 반복하는 작업은 코드를 변경한 뒤 저장 후 브라우저에서 새로고침을 누르는 것이였다.
또한 서비스를 개발하고 웹 서버에 배포할 때 아래와 같은 작업들을 해야했다.
- HTML, CSS, JS 압축
- 이미지 압축
- CSS 전처리기 변환
이러한 일들을 자동화 해주는 도구들이 필요했다. 그래서 Grunt, Gulp 같은 도구들이 등장했다.
3. 웹 애플리케이션의 빠른 로딩 속도와 높은 성능
일반적으로 특정 웹 사이트 접근 시 5초 이내로 웹 사이트가 표현되지 않으면 사용자들은 해당 사이트를 벗어나거나, 집중력을 잃게된다.
그래서 웹사이트의 로딩 속도를 높이기 위해 많은 노력들이 있었는데, 대표적인 노력이 브라우저에서 서버로 요청하는 파일 숫자를 줄이는 것이다. 이를 위해 웹 태스트 매니저를 이용해 파일들을 압축하고 병합하는 작업을 진행했다.
뿐만 아니라 초기 페이지 로딩 속도를 높이기 위해 나중에 필요한 자원들은 나중에 요청하는 Lasy Loading이 등장했다.
그래서 왜 webpack 을 쓰냐고?
이유를 설명하기 전, 브라우저에서 자바스크립트를 작동시키는 방법은 크게 두 가지가 있다.
- 각 기능에 대한 script를 포함한다.
⇒ 이 방법의 문제점은 너무 많은 script를 로드할 시 네트워크 병목현상이 발생할 수 있다.
- 모든 프로젝트 코드가 포함된 큰 .js 파일을 사용한다.
⇒ 이 방법의 문제점은 스코프(Scope), 크기(Size), 가독성(Readability), 유지관리성(Maintainability) 등에 있서 다양한 문제를 불러올 수 있다.
여기서 IIFE(Immediately Invoked Function Expressions), 즉시실행함수 개념이 등장한다.
IIFE의 핵심은 스코프(Scope) 문제를 해결했다는 점이다.
IIFE 내부에서 정의된 변수는 함수 범위의 스코프를 가지며 외부에서는 접근이 불가능하다. 또한 IIFE를 변수에 할당하면, IIFE 자체가 저장되는것이 아니라 함수가 실행된 결과만 저장된다.
이러한 IIFE의 특징은 대규모 프로젝트의 스코프 문제를 해결한다. 스크립트 파일을 IIFE로 감싸주면, 스코프 충돌에 대한 걱정없이 안전하게 스크립트 파일들을 연결하거나 결합시킬 수 있다.
즉 안전한 번들링이 가능하다!
참고
- JavaScript 표준을 위한 움직임: CommonJS와 AMD : https://d2.naver.com/helloworld/12864
