"역사는 과거가 아니고, 역사는 무대가되고있다. W3C와 브라우저의 빠른 발전으로 인해 프론트 엔드 모듈 식 개발은 점차 인프라가 될 것이다. 모든 것이 역사가되고 미래는 더 나아질 것이다." - 나는 유보의 원본 텍스트의 마지막 단락에 개인적으로 동의합니다. 우리는 "미래"에 대해 이야기하기 때문에 프론트 엔드 JS 모듈이 계속 개발되면 모듈 형식이 미래 웹의 표준 사양이되어 여러 구현 방법을 생성 할 것이라고 믿습니다. JSON 형식과 마찬가지로 결국 표준이되어 브라우저에서 기본적으로 구현됩니다.
비동기 모듈이 미래가 될 수있는 최상의 표준은 누구입니까? SEAJS는 CMD 사양을 따르고 요구 사항은 AMD 사양을 따릅니다.이 두 가지 형식부터 시작하겠습니다.
CMD
CMD 모듈 종속성 선언 방법 :
코드 사본은 다음과 같습니다.
define (function (요구) {
var a = 요구 사항 ( './ a');
var b = 요구 사항 ( './ b');
// 더 많은 코드 ..
})
CMD 종속성은 근처에 선언되며 내부 요구 방법을 통해 선언됩니다. 그러나 비동기 모듈이기 때문에 로더는 이러한 모듈을 미리로드해야하므로 모듈을 실제로 사용하기 전에 모듈의 모든 종속성을 추출해야합니다. 자동화 된 도구를 통한 로더 추출 또는 사전 추출 여부에 관계없이 CMD 의이 종속성 선언 형식은 CMD의 단점 인 정적 분석을 통해서만 구현할 수 있습니다.
CMD 사양의 단점
직접 압축 할 수 없습니다 : 요구 사항은 로컬 변수입니다. 즉, 압축 도구를 통해 직접 압축 할 수 없습니다. 요구 변수가 교체되면 로더 및 자동화 도구는 모듈의 종속성을 얻을 수 없습니다.
모듈에는 추가 규칙이 있습니다. 경로 매개 변수는 문자열 작업이 될 수 없으며 변수를 대신 사용할 수 없습니다. 그렇지 않으면 로더와 자동화 도구가 경로를 올바르게 추출 할 수 없습니다.
사양 이외의 규칙은 사양의 일부가 아니라면 더 많은 문서를 의미합니다.
참고 : SEAJS 정적 분석 구현은 정기적 인 추출 요구 사항 부분을 사용하여 종속성 모듈 경로를 얻는 것입니다.
AMD
AMD 모듈 종속성 선언 방법 :
코드 사본은 다음과 같습니다.
정의 ([ './ a', './b'], function (a, b) {
// 더 많은 코드 ..
})
AMD의 종속성은 미리 선언됩니다. 이 장점의 장점은 의존성에 정적 분석이 필요하지 않다는 것입니다. 로더와 자동화 도구는 모두 종속성을 직접 얻을 수 있습니다. 사양의 정의는 더 간단 할 수 있습니다. 즉, 더 강력한 구현이 생성 될 수 있으며, 이는 로더 및 자동화 분석 도구 모두에 유리합니다.
AMD 사양의 단점
의존성 사전 선언은 코드 작성에서 그다지 친숙하지 않습니다.
내부 모듈과 nodejs 모듈 사이에는 특정한 차이가 있습니다.
두 번째 문제는 자세히 설명해야합니다. 실제로 CMD 나 AMD의 비동기 모듈은 동기화 모듈 사양 (Nodejs의 모듈)과 일치 할 수 없으며, 누가 동기화 모듈과 비슷한 사람 만 AMD를 동기화 모듈로 변환하려면 Define 함수의 패키지를 제거하는 것 외에도 종속성을 선언하기 위해 헤드에서 요구 사항을 사용해야하지만 CMD는 Define 함수의 패키지 만 제거하면됩니다.
요약
사양 측면에서 AMD는 더 간단하고 엄격하며 적용 가능성이 더 넓습니다. 요구 사항의 강력한 홍보로 인해 사실상 해외 비동기 모듈 표준 표준이되었으며 주요 라이브러리는 AMD 사양을 연속적으로 지원했습니다.
그러나 Seajs와 CMD에서 우리는 또한 많은 좋은 일을했습니다.
1. 비교적 자연스러운 종속성 명령문 스타일
2. 작고 아름다운 내부 실현
3. 신중한 주변 기능 설계
4. 더 나은 중국 사회 지원
가능하다면 SEAJS도 AMD를 지원하기를 희망하며 개발자의 궁극적 인 행복은 대부분의 개발자입니다.