[24/10/10-10/16] 안내 및 질문 모음집

[minjeongss]

📚 분량

47장-49장=끝! 😊

🎤 발표자

이성훈

질문

48장

• CommonJS와 AMD의 차이점? (김민석)

49장

• Babel과 Webpack을 이용한 개발 환경 구축을 실제 프로젝트에서 어떻게 활용할 수 있는가? (김민정)
• Vite를 활용해서 프로젝트를 진행했는데, webpack이나 babel과 비교해서 어떤 점이 매리트가 있는지? (김주영)

[minjeongss]

48장

• CommonJS와 AMD의 차이점? (김민석)
  • CommonJS: 서버 측 자바스크립트에서 모듈을 정의하고 사용할 수 있도록 설계된 표준
    • 사용: Node.js=서버측
  • AMD: 비동기적으로 모듈을 정의하고 로드할 수 있도록 설계된 표준
    • 필요한 파일을 에트워크를 통해 내려받아야 하는 브러우저와 같은 환경에 적합한 방식
    • 사용: 브라우저=클라이언트측

49장

• Babel과 Webpack을 이용한 개발 환경 구축을 실제 프로젝트에서 어떻게 활용할 수 있는가? (김민정)
  • react 환경에서 CRA(create react app)이 아닌 babel+webpack으로 환경 구축을 함
  • 개인이 개발 환경을 다 구축해서 사용하는 것이기에, 문제가 발생했을 때 해당 부분만 수정하면 되는 이점이 존재함
• Vite를 활용해서 프로젝트를 진행했는데, webpack이나 babel과 비교해서 어떤 점이 매리트가 있는지? (김주영)
  • 개발 서버
    • webpack: 소스 코드와 모든 종속 관계 모듈을 번들링 한 후 서버 준비
    • vite: esbuild로 미리 번들링 한 모듈을 필요할 때 동적으로 가져오기에, 즉각적으로 서버 구동
  • 프로덕션 빌드
    • webpack: 각 모듈을 범위마다 함수로 맵핑하여 결합
    • vite: Rollup으로 하나의 파일에 모든 종속 모듈을 전역 범위로 선언하여 결합
  • vite의 문제점
    • 프로덕션 환경에선 Rollup으로 번들링을 진행하는데, CommonJS나 Polyfill 처리가 안되어 있어 플러그인 설치 필요
    • 프로덕션 환경에는 Webpack과 빌드 시간에서 차이가 크지 않음
    • 개발 환경과 프로덕션 환경 설정이 달라 빌드 안정성이 낮아, 개발 환경에서만 사용한다는 의견이 존재함

[kimjuyoung78]

48장

CommonJS와 AMD의 차이점? (김민석)

• AMD: define() 이 함수이고 define.amd 속성의 객체를 가지고 있다.
• CommonJS: module 이 객체이고 module.exports 속성의 객체를 가지고 있다.
  참고

49장

Babel과 Webpack을 이용한 개발 환경 구축을 실제 프로젝트에서 어떻게 활용할 수 있는가? (김민정)

• 개발 환경 세팅 : 프로젝트 초기 설정 시 Babel과 Webpack을 구성.
• 변환 : 개발 중에는 최신 ECMAScript 문법을 자유롭게 사용하고, Babel이 이를 호환성 있는 코드로 변환.
• 코드 관리 : Webpack을 통해 모듈화된 코드를 효율적으로 관리, 필요한 경우 코드 스플리팅을 통해 성능 최적화.
• 배포 : 프로덕션 빌드 시 Webpack을 통해 코드를 최적화하고 번들링.

Vite를 활용해서 프로젝트를 진행했는데, webpack이나 babel과 비교해서 어떤 점이 매리트가 있는지? (김주영)

• Vite는 Cold-starting이 매우 빠름 :
  -> 개발 서버를 시작할 때 모든 파일을 미리 번들링하지 않고, 요청 시 필요한 모듈만 변환하기 때문
• TypeScript, JSX 등 기본 지원: 추가 설정 없이 이러한 기능들을 바로 사용할 수 있음
  참고 참고2
  참고3코딩애플

[se0kcess]

48장

CommonJS와 AMD의 차이점? (김민석)

로딩 방식:

• CommonJS: 동기적 로딩
• AMD: 비동기적 로딩

주요 사용 환경:

• CommonJS: 주로 서버 사이드 (Node.js)
• AMD: 주로 브라우저 환경

문법:

• CommonJS: require()와 module.exports 사용
• AMD: define()과 require() 함수 사용

의존성 선언:

• CommonJS: 모듈 내부에서 직접 require() 호출
• AMD: 모듈 정의 시 의존성 배열로 명시

실행 시점:

• CommonJS: 모듈을 불러올 때 즉시 실행
• AMD: 모든 의존성이 로드된 후 콜백으로 실행

49장

Babel과 Webpack을 이용한 개발 환경 구축을 실제 프로젝트에서 어떻게 활용할 수 있는가? (김민정)

webpack과 babel을 사용한 리액트 프로젝트 생성

Vite를 활용해서 프로젝트를 진행했는데, webpack이나 babel과 비교해서 어떤 점이 매리트가 있는지? (김주영)

정적 사이트 생성(SSG) 지원:

• Vite는 정적 사이트 생성을 기본적으로 지원
• Webpack에서는 추가 도구나 플러그인이 필요함

간단한 설정:

• Vite는 대부분의 경우 복잡한 설정 없이 바로 사용할 수 있음
• Webpack은 종종 복잡한 설정이 필요하며, 러닝 커브가 더 높을 수 있음

네이티브 ES 모듈 지원:

• Vite는 브라우저의 네이티브 ES 모듈을 활용하여 개발 중 번들링 단계를 건너뜀
• Webpack은 모든 모듈을 번들링하여 제공

TypeScript 및 JSX 지원:

• Vite는 TypeScript와 JSX를 기본적으로 지원
• Webpack에서는 추가 로더와 설정 필요

[joarthvr]

48장

• CommonJS와 AMD의 차이점? (김민석)
  • 로딩 방식:
    • CommonJS: 동기적 로딩
    • AMD: 비동기적 로딩
  • 주요 사용 환경:
    • CommonJS: 서버 사이드 (Node.js)
    • AMD: 브라우저 환경
  • 문법:
    • CommonJS: require()와 module.exports 사용
    • AMD: define() 함수 사용
  • 의존성 관리:
    • CommonJS: 파일 시작 부분에서 모든 의존성 로드
    • AMD: 모듈 정의 시 의존성 명시 및 콜백으로 처리
  • 실행 시점:
    • CommonJS: 모듈을 즉시 실행
    • AMD: 모든 의존성이 로드된 후 실행
  • 성능:
    • CommonJS: 서버에서 빠르지만 브라우저에서는 비효율적일 수 있음
    • AMD: 브라우저에서 효율적인 병렬 로딩 가능

49장

• Babel과 Webpack을 이용한 개발 환경 구축을 실제 프로젝트에서 어떻게 활용할 수 있는가? (김민정)

  1. 최신 JavaScript 문법 사용: Babel을 통해 ES6+ 문법을 사용하면서도 구형 브라우저 지원이 가능
  2. 모듈화: Webpack을 사용하여 코드를 모듈화하고 의존성을 관리
  3. 최적화: Webpack의 프로덕션 모드를 통해 코드 최소화, 트리 쉐이킹 등의 최적화를 자동으로 수행
  4. 확장성: CSS 전처리기, 이미지 최적화 등 다양한 로더와 플러그인을 추가하여 기능을 확장

• Vite를 활용해서 프로젝트를 진행했는데, webpack이나 babel과 비교해서 어떤 점이 매리트가 있는지? (김주영)

  1. 빠른 개발 서버 시작 시간: Vite는 사전 번들링 없이 네이티브 ES 모듈을 직접 제공하여 개발 서버를 매우 빠르게 시작합니다. Webpack에 비해 초기 구동 시간이 크게 단축
  2. 빠른 핫 모듈 교체(HMR): 변경된 모듈만 정확하게 교체하여 매우 빠른 HMR을 제공합니다. 이는 대규모 앱에서 특히 유용
  3. 기본 설정의 간소화: Vite는 많은 일반적인 사용 사례에 대해 기본 설정이 최적화되어 있어, 복잡한 설정 없이도 바로 사용
  4. TypeScript 및 JSX 지원: 별도의 설정 없이 TypeScript와 JSX를 즉시 지원
  5. CSS 전처리기 지원: SASS, Less, Stylus 등의 CSS 전처리기를 쉽게 통합

[shlee9999]

ES Module(ESM) vs CommonJS

JavaScript의 모듈 시스템은 크게 ES Moduel(ESM)와 CommonJS 로 나뉜다. ES Module은 최신 Javascript 표준으로, 내가 가장 익숙한 import와 export 키워드를 사용하는 방식을 사용한다. CommonJS는 Node.js환경에서 주로 사용되며, require()와 module.exports를 사용하여 모듈을 가져오고 내보낸다.

	CommonJS	ES Module
로드 방식	동기적	비동기적
트리 셰이킹	어려움	용이
사용 환경	서버 사이드	브라우저
키워드	require, module.exports	import, export

동기 vs 비동기

ESM은 브라우저 환경에서도 사용할 수 있도록 설계되어 모듈을 비동기적으로 로드한다. 반면 CommonJS는 동기적으로 모듈을 로드한다.

트리 셰이킹

ESM은 정적 분석이 가능하여 트리 셰이킹이 용이하다. 반면 CommonJS는 트리 셰이킹이 어렵다.

정적 분석 Tree Shaking

ES Module의 특징

ES Module(ESM)은 최신 JavaScript 표준으로, import와 export 키워드를 사용하여 모듈을 가져오고 내보냅니다. 이는 비동기적으로 작동하며, 브라우저 환경에서도 사용될 수 있도록 설계되었습니다.

ESM은 정적 분석이 가능하기 때문에, 트리 셰이킹이 용이합니다. 이는 사용되지 않는 코드를 제거하여 번들 크기를 줄이는 데 유리합니다. 왜냐하면 ESM은 모듈의 의존성을 정적으로 분석할 수 있기 때문입니다.

또한, ESM은 브라우저 환경에서 비동기 로드를 지원합니다. 이는 브라우저에서 모듈을 로드할 때 페이지 로딩 속도를 저하시키지 않기 때문에 중요합니다.

ESM은 import와 export 키워드를 사용하여 모듈을 가져오고 내보냅니다. 이는 코드의 가독성을 높이고, 모듈 간의 의존성을 명확하게 합니다.

다음은 ESM의 예제 코드입니다:

import { sayHello } from './moduleA';
sayHello();
export function sayHello() {

console.log('Hello from ES Module');

}

CommonJS의 특징

CommonJS는 Node.js 환경에서 주로 사용되는 모듈 시스템입니다. require() 함수를 사용하여 모듈을 가져오고, module.exports를 사용하여 모듈을 내보냅니다. 이는 동기적으로 작동하며, 모듈이 로드될 때까지 코드 실행이 중단됩니다.

CommonJS는 동기적 로드 방식을 사용하기 때문에, 서버 사이드 렌더링과 같은 환경에서 유리합니다. 왜냐하면 서버 사이드에서는 모든 모듈이 로드된 후에야 코드가 실행되기 때문입니다.

하지만, CommonJS는 트리 셰이킹이 어렵다는 단점이 있습니다. 이는 사용되지 않는 코드를 제거하기 어렵게 만듭니다. 왜냐하면 CommonJS는 동적 로드를 지원하기 때문입니다.

또한, CommonJS는 브라우저 환경에서 사용하기 어렵습니다. 브라우저에서는 비동기 로드가 필수적이기 때문입니다. 따라서, 브라우저 환경에서는 ES Module을 사용하는 것이 더 적합합니다.

다음은 CommonJS의 예제 코드입니다:

const moduleA = require('./moduleA');
moduleA.sayHello();
module.exports = {

sayHello: function() {

console.log('Hello from CommonJS');

}

};

CommonJS와 ES Module의 통합

최근에는 CommonJS와 ES Module을 모두 지원하는 라이브러리가 많이 등장하고 있습니다. 이는 두 모듈 시스템의 장점을 모두 활용할 수 있도록 합니다. 왜냐하면 각 모듈 시스템이 제공하는 기능과 성능이 다르기 때문입니다.

Webpack과 같은 번들러를 사용하면, CommonJS와 ES Module을 모두 지원하는 번들을 생성할 수 있습니다. 이는 프로젝트의 호환성을 높이고, 다양한 환경에서 사용할 수 있도록 합니다.

다음은 Webpack을 사용하여 CommonJS와 ES Module을 모두 지원하는 번들을 생성하는 예제입니다:

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        libraryTarget: 'umd',
    },
    module: {
        rules: [
            {
                test: /\\.js$/,
                exclude: /node_modules/,
                use: {
                    loader: 'babel-loader',
                },
            },
        ],
    },
};

위 예제에서는 Webpack을 사용하여 CommonJS와 ES Module을 모두 지원하는 번들을 생성합니다. libraryTarget을 'umd'로 설정하여, UMD(Universal Module Definition) 형식으로 번들을 생성합니다. 이는 CommonJS와 ES Module을 모두 지원합니다.

따라서, 프로젝트의 요구사항과 환경에 따라 적절한 모듈 시스템을 선택하고, 필요에 따라 두 모듈 시스템을 통합하여 사용할 수 있습니다. 왜냐하면 각 모듈 시스템이 제공하는 기능과 성능이 다르기 때문입니다.

이 글에서는 CommonJS와 ES Module의 통합 방법에 대해 알아보았습니다.

# ES Module(ESM) vs CommonJS

JavaScript의 모듈 시스템은 크게 ES Moduel(ESM)와 CommonJS 로 나뉜다. ES Module은 최신 Javascript 표준으로, 내가 가장 익숙한 import와 export 키워드를 사용하는 방식을 사용한다. CommonJS는 Node.js환경에서 주로 사용되며, require()와 module.exports를 사용하여 모듈을 가져오고 내보낸다.

	CommonJS	ES Module
로드 방식	동기적	비동기적
트리 셰이킹	어려움	용이
사용 환경	서버 사이드	브라우저
키워드	require, module.exports	import, export

동기 vs 비동기

ESM은 브라우저 환경에서도 사용할 수 있도록 설계되어 모듈을 비동기적으로 로드한다. 반면 CommonJS는 동기적으로 모듈을 로드한다.

트리 셰이킹

ESM은 정적 분석이 가능하여 트리 셰이킹이 용이하다. 반면 CommonJS는 트리 셰이킹이 어렵다.

정적 분석 [Tree Shaking](https://www.notion.so/Tree-Shaking-7ca0247e8d0743dfb20a7221da7fa4e5?pvs=21)

ES Module의 특징

ES Module(ESM)은 최신 JavaScript 표준으로, import와 export 키워드를 사용하여 모듈을 가져오고 내보냅니다. 이는 비동기적으로 작동하며, 브라우저 환경에서도 사용될 수 있도록 설계되었습니다.

ESM은 정적 분석이 가능하기 때문에, 트리 셰이킹이 용이합니다. 이는 사용되지 않는 코드를 제거하여 번들 크기를 줄이는 데 유리합니다. 왜냐하면 ESM은 모듈의 의존성을 정적으로 분석할 수 있기 때문입니다.

또한, ESM은 브라우저 환경에서 비동기 로드를 지원합니다. 이는 브라우저에서 모듈을 로드할 때 페이지 로딩 속도를 저하시키지 않기 때문에 중요합니다.

ESM은 import와 export 키워드를 사용하여 모듈을 가져오고 내보냅니다. 이는 코드의 가독성을 높이고, 모듈 간의 의존성을 명확하게 합니다.

다음은 ESM의 예제 코드입니다:

import { sayHello } from './moduleA';

sayHello();

export function sayHello() {
    console.log('Hello from ES Module');
}

CommonJS의 특징

CommonJS는 Node.js 환경에서 주로 사용되는 모듈 시스템입니다. require() 함수를 사용하여 모듈을 가져오고, module.exports를 사용하여 모듈을 내보냅니다. 이는 동기적으로 작동하며, 모듈이 로드될 때까지 코드 실행이 중단됩니다.

CommonJS는 동기적 로드 방식을 사용하기 때문에, 서버 사이드 렌더링과 같은 환경에서 유리합니다. 왜냐하면 서버 사이드에서는 모든 모듈이 로드된 후에야 코드가 실행되기 때문입니다.

하지만, CommonJS는 트리 셰이킹이 어렵다는 단점이 있습니다. 이는 사용되지 않는 코드를 제거하기 어렵게 만듭니다. 왜냐하면 CommonJS는 동적 로드를 지원하기 때문입니다.

또한, CommonJS는 브라우저 환경에서 사용하기 어렵습니다. 브라우저에서는 비동기 로드가 필수적이기 때문입니다. 따라서, 브라우저 환경에서는 ES Module을 사용하는 것이 더 적합합니다.

다음은 CommonJS의 예제 코드입니다:

const moduleA = require('./moduleA');

moduleA.sayHello();

module.exports = {
    sayHello: function() {
        console.log('Hello from CommonJS');
    }
};

CommonJS와 ES Module의 통합

최근에는 CommonJS와 ES Module을 모두 지원하는 라이브러리가 많이 등장하고 있습니다. 이는 두 모듈 시스템의 장점을 모두 활용할 수 있도록 합니다. 왜냐하면 각 모듈 시스템이 제공하는 기능과 성능이 다르기 때문입니다.

Webpack과 같은 번들러를 사용하면, CommonJS와 ES Module을 모두 지원하는 번들을 생성할 수 있습니다. 이는 프로젝트의 호환성을 높이고, 다양한 환경에서 사용할 수 있도록 합니다.

다음은 Webpack을 사용하여 CommonJS와 ES Module을 모두 지원하는 번들을 생성하는 예제입니다:

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        libraryTarget: 'umd',
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: {
                    loader: 'babel-loader',
                },
            },
        ],
    },
};

위 예제에서는 Webpack을 사용하여 CommonJS와 ES Module을 모두 지원하는 번들을 생성합니다. libraryTarget을 'umd'로 설정하여, UMD(Universal Module Definition) 형식으로 번들을 생성합니다. 이는 CommonJS와 ES Module을 모두 지원합니다.

따라서, 프로젝트의 요구사항과 환경에 따라 적절한 모듈 시스템을 선택하고, 필요에 따라 두 모듈 시스템을 통합하여 사용할 수 있습니다. 왜냐하면 각 모듈 시스템이 제공하는 기능과 성능이 다르기 때문입니다.

이 글에서는 CommonJS와 ES Module의 통합 방법에 대해 알아보았습니다.