"역사는 과거가 아닙니다. 역사는 지금 일어나고 있습니다. W3C, 브라우저 등 사양의 급속한 발전으로 프런트엔드 모듈 개발은 점차 인프라가 될 것입니다. 모든 것이 결국 역사가 될 것이며, 미래는 더 좋아질 것입니다. "—— 유보 원문의 마지막 문단을 인용하자면, 개인적으로 매우 동의합니다. 이제 "미래"에 대해 이야기하고 있으니 개인적으로 프론트엔드 js 모듈이 계속 발전한다면 그 모듈 형식이 미래 WEB의 표준 사양이 되어 다양한 구현 방식이 나올 가능성이 높다고 생각합니다. JSON 형식과 마찬가지로 결국 표준이 되었고 브라우저에서 기본적으로 구현되었습니다.
미래 비동기 모듈 표준이 될 가능성이 더 높은 사람은 누구인가요? SeaJS는 CMD 사양을 따르고 RequireJS는 AMD 사양을 따릅니다. 이 두 가지 형식부터 시작해 보겠습니다.
CMD
CMD 모듈 종속성 선언 방법:
CMD 종속성은 근처에 선언되며 내부 require 메소드를 통해 선언됩니다. 하지만 비동기식 모듈이기 때문에 로더가 이러한 모듈을 미리 로드해야 하므로 모듈이 실제로 사용되기 전에 모듈의 모든 종속성을 추출해야 합니다. 로더에 의해 즉석에서 추출되거나 자동화된 도구를 통해 사전 추출되더라도 CMD의 이러한 종속성 선언 형식은 정적 분석을 통해서만 달성할 수 있으며 이는 CMD의 단점입니다.
CMD 사양의 단점
직접 압축할 수 없습니다. require는 로컬 변수입니다. 즉, require 변수를 교체하면 로더와 자동화 도구가 모듈의 종속성을 얻을 수 없습니다.
모듈 작성에 대한 추가 규칙이 있습니다. 경로 매개변수는 문자열 작업을 받을 수 없으며 변수로 대체될 수 없습니다. 그렇지 않으면 로더와 자동화 도구가 경로를 올바르게 추출할 수 없습니다.
사양 외부의 계약은 사양의 일부가 아닌 한 더 많은 문서를 의미합니다.
참고: SeaJS 정적 분석은 모듈 패키지를 String()에 넣은 다음 정규식을 사용하여 필수 부분을 추출하여 종속 모듈 경로를 얻는 방식으로 구현됩니다.
AMD
AMD 모듈 종속성 선언 방법:
AMD 종속성은 미리 선언됩니다. 이 장점의 장점은 종속성을 정적으로 분석할 필요가 없다는 것입니다. 로더와 자동화 도구 모두 종속성을 직접 얻을 수 있으며 이는 사양의 정의가 더 간단할 수 있으며 이는 더 강력한 구현이 생성될 수 있음을 의미합니다. 로더와 자동화가 유용합니다.
AMD 사양의 단점
코드 작성에서는 종속성을 미리 선언하는 것이 그리 친숙하지 않습니다.
내부 모듈과 NodeJS 모듈 간에는 특정 차이점이 있습니다.
두 번째 사항에는 특별한 설명이 필요합니다. 실제로 CMD나 AMD의 비동기 모듈은 동기 모듈 사양(NodeJS의 모듈)과 일치할 수 없습니다. 단 하나만이 다른 것보다 동기 모듈과 더 유사합니다. AMD를 동기화된 모듈로 변환하려면 정의 함수의 래퍼를 제거하는 것 외에도 헤더에서 require를 사용하여 종속성을 선언해야 하지만 CMD는 정의 함수의 래퍼만 제거하면 됩니다.
요약
사양 측면에서 AMD는 더 간단하고 엄격하며 적용 범위가 더 넓습니다. RequireJS의 강력한 홍보로 해외에서 거의 사실상의 비동기 모듈 표준이 되었으며 주요 라이브러리도 AMD 사양을 연속적으로 지원했습니다.
그러나 SeaJS와 CMD의 관점에서 보면 좋은 일도 많이 했습니다.
1. 비교적 자연스러운 종속성 선언 스타일
2. 작지만 아름다운 내부 구현
3. 친밀한 주변 기능 디자인
4. 더 나은 중국 커뮤니티 지원
가능하다면 SeaJS도 AMD를 지원해 프런트엔드 커뮤니티 환경과 일관성을 유지하는 모습을 보고 싶습니다. 결국 대다수의 개발자들은 만족할 것입니다.