더 많은 JavaScript 사용 최신 브라우저를 통해 제공되는 더 많은 사용자 인터페이스 페이지는 전체 페이지를 가능한 한 적게 새로 고침하면서 제공됩니다. 이제 웹사이트에는 클라이언트에서 실행되는 많은 코드! 거대한 코드 베이스를 질서 있게 관리해야 하는데, 모듈 시스템 "모듈 시스템"은 코드 베이스를 모듈 "모듈"로 분할하는 기능을 제공합니다. 모듈 시스템의 각 파벌 모듈 및 모듈 종속성을 정의하는 데는 여러 가지 표준이 있습니다. "모듈 시스템을 사용하지 않습니다" </p> <p>CommonJS</p> <p> AMD </p> <p>ES6 모듈 시스템</p> <p>다른 것도 있습니다...<br></p> <p><br> 스크립트 태그<br><br>이 접근 방식은 모듈 시스템을 사용하지 않습니다</p> <p>각 모듈은 인터페이스를 전역 개체 "예: 창 개체"로 내보냅니다. 다른 모듈은 전역 개체를 통해 이 인터페이스에 액세스합니다. <br><br> 단점: <br><br> 충돌을 일으키기 쉬움 <br><br> 모듈 로딩 순서에 세심한 주의 필요 <br><br> 모듈 사용자는 모듈 종속성을 분해해야 함 <br> <br> 대규모 프로젝트에서는 관리해야 할 모듈이 많아 관리가 매우 어렵습니다. <br><br> CommonJS: 동기 require 메소드 <br><br> 이 메소드는 동기 require 메소드를 사용하여 종속 모듈을 로드합니다. 모듈을 만들고 인터페이스를 반환합니다. 내보내기 개체 "exports"에 속성을 추가하거나 module.exports에 값을 할당하여 모듈의 내보내기 개체를 정의할 수 있습니다. </p> <p> 이 접근 방식은 일반적으로 서버 측 NodeJS에서 사용됩니다. <br><br> 장점 <br><br> 서버 측 코드를 활용할 수 있습니다. <br><br> npm에는 이미 다음을 사용하는 많은 모듈이 있습니다. 이 스타일 <br><br> 매우 편리하고 사용하기 쉽다 <br><br> 단점<br><br> 블로킹 로딩 방식은 네트워크 환경에 적합하지 않으며, 네트워크 요청이 비동기식이다<br><br> 다중 모듈 로딩, 병렬 로딩 없음 <br><br> AMD: 비동기 require 메소드는 다른 브라우저 환경 모듈 시스템에서 사용됩니다. 동기 require 메소드를 지원하지 않지만, 비동기 require 메소드를 제공합니다: </p> <p> 장점 <br><br> 네트워크 환경에서 비동기 요청 방식을 준수 <br><br> 여러 모듈을 병렬로 로드할 수 있음 <br><br> 단점 <br><br> 추가 코딩 오버헤드. 가독성이 좋지 않음 <br><br> 약간 임시 솔루션과 비슷함 <br><br> 구현: RequireJS <br><br> ES6 모듈 시스템 <br><br> ECMAScript 2015 "6번째 버전", JavaScript용으로 일부 언어 제공 다른 모듈 시스템을 구성하는 구조 </p> <p>장점<br><br> 정적 분석이 용이함<br><br> 미래지향적 ES 표준<br><br> 단점<br> <br> 소요 브라우저가 이 기능을 지원하려면 시간이 좀 걸릴 것입니다. <br><br> 이런 방식으로 작성된 모듈은 아직 상대적으로 적습니다. <br><br> 객관적인 솔루션 <br><br> 개발자가 기존 코드 기반을 허용하는 모듈 시스템을 선택하도록 합니다. 다른 모듈 시스템을 사용하더라도 실행됩니다. <br><br>전송<br><br> 클라이언트에서 모듈을 실행하려면 먼저 서버에서 클라이언트로 모듈을 전송해야 합니다. 두 가지 극단적인 전송 방법이 있는데 둘 다 널리 사용되지만 둘 다 최적은 아닙니다 <br><br> 한 번에 하나의 모듈 요청 <br><br> 모든 모듈을 한 번에 요청 <br> <br> 한 번 요청 하나의 모듈에 대해 <br><br></p> <p> 장점: 필요한 모듈만 전송 </p> <p> 단점: 과도한 요청 오버헤드 </p> <p> 단점: 요청 지연이 커서 프로그램이 천천히 시작 <br></p> <p><br> 모든 모듈을 한 번에 요청 <br><br></p> <p> 장점: 요청 오버헤드가 적고 지연이 적음 </p> <p>단점: 사용하지 않은 모듈도 클라이언트에 다운로드<br></p> <p><br> 단편화된 전송<br><br> 대부분의 경우 보다 유연한 방법이 필요합니다. 전송 방법은 위 두 가지 중 하나입니다. 극단적인 경우: <br><br> 모든 모듈을 컴파일할 때 일련의 모듈을 하나의 요청과 관련하여 일련의 작은 조각 "청크" <br><br>로 분해합니다. 모든 모듈에 대해 샤딩 접근 방식은 네트워크 요청을 여러 요청으로 전환합니다. 더 작고 더 빠른 요청. 프로그램이 시작되면 필요하지 않은 조각이 필요할 때 로드됩니다. <br><br> 한 번에 하나의 모듈을 요청하는 것과 비교하면 프로그램 초기화 속도가 빨라지지만 여전히 실제 사용 중에 더 많은 코드를 얻을 수 있고 "네트워크 요청 오버헤드를 줄일 수 있습니다." <br><br> 샤딩 방법과 샤딩 위치는 개발자가 결정합니다. 대규모 코드 베이스는 이러한 방식으로 구성될 수 있습니다. <br><br> 결론 <br><br> 위의 두 가지 주요 테마에 대해 Webpack은 다중 모듈 시스템 스타일을 지원하고 유연한 청크 전송 "Code Split"을 지원합니다. <br><br> Webpack은 웹사이트의 JS 코드 라이브러리나 타사 코드 라이브러리를 패키징하는 데 사용할 수 있는 JS 모듈 패키징 도구입니다. AMD만 지원하는 RequireJs와 달리 NodeJS는 CommonJS, SeaJS는 CMD만 지원하고, 이제 ES6 모듈도 나오네요... Webpack은 올인원과 같아서 개발자가 자신의 취향에 따라 유연하게 코딩할 수 있습니다. </p> <p><br></p>