프론트엔드 모듈화의 개발 역사

원본 참고 유보가 달인이라 정리했습니다.

오늘의 주제는 주로 AMD CMD 개발을 위한 프런트엔드 모듈 개발의 역사에 관한 것입니다. 이 두 가지는 일종의 사양입니다. 그들의 실제 제품은 AMD와 RequireJS이고, CMD의 제품은 seajs입니다. 그들의 출현 그들은 모두 COMMONjs를 기반으로 개발되었으므로 먼저 COMMONjs에 대해 이야기해야합니다.

COMMONJS

2009-10년쯤에 CommonJS 커뮤니티가 모였습니다. CommonJS는 원래 ServerJS라고 불렸습니다. Modules/1.0 사양이 출시된 후 Node.js 환경에서 매우 좋은 사례를 달성했습니다. 2009년 하반기, 이 열심히 일하는 전문가들은 ServerJS의 성공적인 경험을 브라우저 측에 더욱 홍보하기 위해 커뮤니티 이름을 CommonJS로 변경하는 동시에 모듈 사양의 다음 버전에 대해 열띤 토론을 벌였습니다. 차이와 갈등이 생겨나고 점차 세 개의 주요 학파가 형성되었습니다: Modules/1.x(1.0의 기능을 완전히 기반으로 변환 기능만 추가), Modules/Async, Modules/2.0.

Modules/1.x school: 이 견해는 1.x 사양이 충분하며 브라우저에만 이식하면 된다고 믿습니다. 수행해야 할 작업은 새로운 모듈/전송 사양을 추가하는 것입니다. 즉, 브라우저에서 실행하기 전에 변환 도구를 사용하여 모듈을 전송 사양을 준수하는 코드로 변환하는 것입니다. 지금 주목할 만한 두 가지 구현이 있습니다: 컴포넌트와 es6 모듈입니다.

Modules/Async 학교: 이 견해는 브라우저가 고유한 특성을 갖고 있으며 Modules/1.x 사양을 직접 사용해서는 안 된다고 믿습니다. 이러한 관점의 전형적인 대표자는 AMD 사양과 그 구현인 RequireJS입니다. 이에 대해서는 나중에 자세히 설명합니다.

Modules/2.0 학교: 이 견해는 브라우저가 고유한 특성을 갖고 있으며 Modules/1.x 사양을 직접 사용해서는 안 되지만 가능한 한 Modules/1.x 사양과 일치해야 한다고 믿습니다. 이러한 관점의 대표적인 대표자는 BravoJS 및 FlyScript의 작성자입니다. BravoJS 작성자는 CommonJS 커뮤니티에 상당한 기여를 했습니다. FlyScript의 작성자는 CMD 사양의 전신인 Modules/Wrappings 사양을 제안했습니다. 불행하게도 BravoJS는 너무 학문적이어서 FlyScript는 나중에 자체적으로 거세되어 전체 웹사이트(flyscript.org)를 오프라인으로 전환했습니다. 이 이야기는 약간 비극적이어서 자세히 설명하지 않겠습니다.

위는 등장한 세 가지 주요 학교입니다. 이는 Modules/2.0으로 시작된 제품이 모두 문제없이 종료되었음을 의미합니다. 당시 Modules/1.x 표준 ES6은 아직 성숙되지 않았고 나중에는 Modules/Async를 표준으로 하는 RequireJS 개발이 매우 뜨겁습니다.

그러나 AMD의 RequireJS 실행 시기에 대한 이의가 있으며 모듈 작성 스타일은 논란의 여지가 있으며 CommonJS 커뮤니티에서 인정되지 않습니다. 이 두 가지 사항에 대해 자세히 이야기해 보겠습니다.

a.js를 미리 다운로드합니다. AMD는 브라우저의 한계로 커뮤니티에서 인정하는 동기 다운로드를 구현할 수 있는 방법이 없습니다. 그러나 AMD에서는 미리 실행하고, 기본 Modules/1.0 사양에서는 필요할 때 실행합니다. 처음으로. Modules/2.0 견해를 갖고 있는 사람들을 포함하여 많은 사람들이 AMD의 견해를 받아들일 수 없습니다. 이러한 차이는 또한 노드 모듈과 AMD 모듈을 공유할 수 없으며 잠재적인 충돌이 있다는 사실로 이어집니다. 또 다른 점은 모듈 작성 스타일이 논란의 여지가 있다는 것입니다.

AMD 스타일에서 매개변수를 통해 종속 모듈을 전달하면 근접성 선언의 원칙이 파괴됩니다. 근접성 원칙은 모듈이 사용될 때만 선언할 필요 없이 사용된다는 것을 의미합니다. 모듈을 미리. 마침내 AMD는 CommonJS 커뮤니티에서 분리되어 단독으로 AMD 커뮤니티가 되었습니다. 나중에 RequireJS가 특히 인기가 있다는 것을 알게 될 것입니다.

사실 이때 CommonJS 커뮤니티의 AMD 사양에서 벗어나 본질적으로 RequireJS로 발전했습니다. 나중에 RequireJS 커뮤니티에서 require 메서드를 사용하고 싶다고 말하는 사람들이 많았습니다. 결국 RequireJS 작성자는 타협했고 이것이 어설픈 지원을 받을 수 있는 유일한 방법이었습니다. (이것은 의사 지원이며 그 뒤에는 여전히 초기 실행과 같은 AMD의 운영 논리가 있다는 점에 유의하십시오.) AMD의 인기는 주로 RequireJS 작성자의 홍보에 달려 있으며 AMD 사양의 발전은 RequireJS와 분리될 수 없습니다.

Modules/2.0

BravoJS의 저자인 Wes Garland는 뛰어난 프로그래밍 기술을 보유하고 있으며 CommonJS 커뮤니티에서도 매우 존경받고 있습니다. 그러나 BravoJS 자체는 매우 학문적이며 Modules/2.0-draft 사양을 보여주기 위해 작성된 프로젝트입니다. 대학은 실용적인 RequireJS에 취약했고 이제는 기본적으로 좋은 추억만 간직하고 있습니다.

현재 Modules/2.0 진영에는 매우 간결한 모듈/래핑 사양을 제안한 FlyScript라는 실용적인 세력도 있습니다. 이 간결한 사양은 브라우저의 특수성을 고려하고 최대한 호환됩니다. Modules/1.0 사양을 사용합니다. 안타깝게도 FlyScript가 공식 버전과 공식 웹사이트를 출시한 후 당시 RequireJS는 호황을 누리고 있었습니다. 이 기간 동안 FlyScript 작성자와 RequireJS 작성자 James Burke 사이에 몇 가지 논쟁이 있었습니다. 나중에 FlyScript 작성자가 자체 거세를 수행하고 GitHub에서 프로젝트와 공식 웹사이트를 정리했습니다. 그는 당시 공식 웹사이트에 다음과 같은 문장을 남겼다는 것을 어렴풋이 기억합니다.

그동안 정확히 무슨 일이 일어났는지는 알 수 없습니다. 나중에 유 삼촌이 FlyScript 작성자에게 이메일을 보내 물어보았고 상대방은 제가 존경하는 두 가지 이유를 알려줬습니다.

1. 저는 프론트엔드 출신이 아니며 RequireJS의 저자인 James Burke는 저보다 브라우저를 더 잘 알고 있습니다.

2. 원하는 것이 아니더라도 우리는 커뮤니티 발전을 촉진하기 위해 함께 노력해야 합니다.

이 두 문장은 유삼촌에게 큰 영향을 미쳤습니다. 그 이후로 저는 RequireJS를 주의 깊게 공부하기 시작했고 이메일과 다른 방법을 통해 RequireJS에 많은 제안을 했습니다. 나중에 RequireJS를 실제로 사용하면서 많은 함정에 부딪혔습니다. RequireJS는 당시 매우 인기가 있었지만 실제로는 완벽하지 않았습니다. 이 기간 동안 나는 FlyScript가 떠날 때 "나는 더 좋은 것을 가지고 돌아올 것이다"라고 했던 말을 생각하고 있었습니다.

유 삼촌은 내가 FlyScript의 저자만큼 훌륭하지 않다고 말했고, 그는 계속해서 RequireJS에 대한 제안을 했습니다. , 하지만 그는 결코 받아들여지지 않았습니다. 그것을 채택한 후에는 로더를 직접 작성해야겠다는 생각이 들기 시작했습니다.

SeaJS입니다. SeaJS는 FlyScript의 module.declare 改名为 define 등 RequireJS에서 많은 것을 차용합니다. SeaJS는 Modules/2.0 관점에서 더 많이 나오지만 학술적인 내용은 최대한 제거하고 실용적인 아이디어를 많이 추가합니다. CMD, SeaJs의 간접 제품입니다.

자, 기본 기록은 마쳤습니다. 제가 말한 내용을 이해하실 수 있을지 모르겠습니다. 대략적으로 요약하면 COMMONJS가 서버 측에서 사용되므로 사용할 수 없습니다. 이 사양을 브라우저에서 어떻게 사용하는지에 대해서는 필연적으로 새로운 논의가 있을 것이며, 다른 개념과 논쟁이 생길 것입니다. 따라서 브라우저에 적합한 AMD 사양과 CMD 사양이 있을 것입니다. COMMONJS 커뮤니티에서 인정을 받아 마침내 독립적으로 운영되었습니다. 물론 RequireJS는 한동안 인기를 끌었지만 나중에 Yu Bo가 CMD의 제품인 seajs를 개발했습니다.

지금까지 이 두 제품은 아마도 오래되었을 것입니다. 물론 여전히 사용 중입니다. 결국 Webpakc는 세 가지 사양을 완벽하게 지원합니다. , 이것이 프론트엔드 모듈화 개발의 역사입니다. 초보자가 프론트엔드의 역사적 발전을 이해하는 것은 여전히 ​​필요합니다. 사실 원본 글은 유 아저씨가 쓴 글인데, 모두가 이해하기 쉽도록 그냥 제 나름의 버전으로 바꿨습니다. 또한 프론트엔드 모듈화의 역사에 대한 정보도 검색해 볼 수 있습니다. 왜 모듈화가 필요한지 먼저 이해하고, 질문으로 공부하면 더 빨리 배울 수 있습니다.

위 내용은 프론트엔드 모듈화의 개발 역사의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!