"A história não é o passado, a história está sendo encenada. Com o rápido desenvolvimento de W3C e navegadores, o desenvolvimento modular front-end se tornará gradualmente a infraestrutura. Tudo acabará se tornando história e o futuro será melhor". - Pessoalmente, concordo com o último parágrafo do texto original de Yu Bo. Como falamos sobre o "futuro", acredito pessoalmente que, se o módulo JS front-end continuar se desenvolvendo, seu formato de módulo provavelmente se tornará uma especificação padrão para futuras Web e produzir vários métodos de implementação. Assim como o formato JSON, ele acaba se torna padrão e é implementado nativamente pelo navegador.
Quem tem o melhor padrão para módulos assíncronos se tornarem o futuro? O SEAJS segue a especificação do CMD, o requerjs segue a especificação da AMD, vamos começar com esses dois formatos diferentes.
Cmd
Método de declaração de dependência do módulo CMD:
A cópia do código é a seguinte:
Definir (função (requer) {
var a = requer ('./ a');
var b = requer ('./ b');
// mais código ..
})
As dependências da CMD são declaradas nas proximidades e são declaradas por métodos internos requisitos. No entanto, por ser um módulo assíncrono, o carregador precisa carregar esses módulos com antecedência; portanto, antes que o módulo seja realmente usado, todas as dependências no módulo precisam ser extraídas. Seja extração ou pré-extração do carregador através de ferramentas automatizadas, esse formato de declaração de dependência do CMD só pode ser implementado por meio de análise estática, que é a desvantagem do CMD.
Desvantagens das especificações da CMD
Não é possível compactar diretamente: requer é uma variável local, o que significa que ela não pode ser comprimida diretamente através da ferramenta de compactação. Se a variável requer for substituída, as ferramentas de carregador e automação não poderão obter as dependências do módulo.
O módulo possui uma convenção adicional: os parâmetros do caminho não podem ser operações de string e as variáveis não podem ser usadas, caso contrário, as ferramentas de carregador e automação não podem extrair o caminho corretamente.
As convenções fora da especificação significam mais documentação, a menos que também façam parte da especificação.
NOTA: A implementação da análise estática do SEAJS é usar a parte regular de requisitos de extração para obter o caminho do módulo de dependência.
AMD
Método de declaração de dependência do módulo AMD:
A cópia do código é a seguinte:
define (['./ a', './b'], função (a, b) {
// mais código ..
})
As dependências da AMD são declaradas antecipadamente. A vantagem dessa vantagem é que a dependência não requer análise estática. Tanto o carregador quanto a ferramenta de automação podem obter diretamente dependências. A definição da especificação pode ser mais simples, o que significa que implementações mais poderosas podem ser geradas, o que é benéfico para o carregador e a ferramenta de análise de automação.
Desvantagens da especificação da AMD
As declarações de antecedência de dependência não são tão amigáveis na redação de código.
Há uma certa diferença entre o módulo dentro e os módulos de nodejs.
A segunda questão precisa ser explicada em detalhes. De fato, nem os módulos assíncronos da CMD nem a AMD podem ser consistentes com a especificação do módulo de sincronização (módulos do NodeJS), apenas quem é mais como um módulo de sincronização do que quem é. Para converter a AMD em um módulo de sincronização, além de remover o pacote da função Definir, você precisa usar o requer na cabeça para declarar a dependência, enquanto o CMD só precisa remover o pacote da função Definir.
Resumir
Em termos de especificação, a AMD é mais simples e rigorosa e tem uma aplicabilidade mais ampla. Com a forte promoção dos requisitos, ela quase se tornou um padrão de módulo assíncrono de fato no exterior, e as principais bibliotecas apoiaram sucessivamente as especificações da AMD.
Mas de Seajs e CMD, também fizemos muitas coisas boas:
1. Estilo de declaração de dependência relativamente natural
2. Realização interna pequena e bonita
3. Projeto de função periférica cuidadosa
4. Melhor apoio da comunidade chinesa
Se possível, espero ver o SEAJS também apoia a AMD, e a felicidade final dos desenvolvedores é a maioria dos desenvolvedores.