"La historia no es el pasado, la historia se está organizando. Con el rápido desarrollo de W3C y los navegadores, el desarrollo modular front-end se convertirá gradualmente en infraestructura. Todo finalmente se convertirá en historia y el futuro será mejor". - Personalmente estoy de acuerdo con el último párrafo del texto original de Yu Bo. Como hablamos sobre el "futuro", personalmente creo que si el módulo JS front-end continúa desarrollándose, es probable que su formato de módulo se convierta en una especificación estándar para futuras web y producir múltiples métodos de implementación. Al igual que el formato JSON, finalmente se vuelve estándar y el navegador implementa de forma nativa.
¿Quién tiene el mejor estándar para que los módulos asincrónicos se conviertan en el futuro? SEAJS sigue la especificación CMD, RequestJS sigue la especificación AMD, comencemos con estos dos formatos diferentes.
CMD
Método de declaración de dependencia del módulo CMD:
La copia del código es la siguiente:
Definir (función (requerir) {
var a = requerir ('./ a');
var b = require ('./ b');
// más código ..
})
Las dependencias de CMD se declaran cerca y se declaran a través de métodos de requisito interno. Sin embargo, debido a que es un módulo asincrónico, el cargador necesita cargar estos módulos por adelantado, por lo que antes de que se use realmente el módulo, se deben extraer todas las dependencias en el módulo. Ya sea que se trate de extracción del cargador o preextractando a través de herramientas automatizadas, este formato de declaración de dependencia de CMD solo se puede implementar a través del análisis estático, que es la desventaja de CMD.
Desventajas de las especificaciones de CMD
No se puede comprimir directamente: requerir una variable local, lo que significa que no se puede comprimir directamente a través de la herramienta de compresión. Si se reemplaza la variable requerida, las herramientas de cargador y automatización no podrán obtener las dependencias del módulo.
El módulo tiene una convención adicional: los parámetros de ruta no pueden ser operaciones de cadena, y las variables no se pueden usar en su lugar, de lo contrario el cargador y las herramientas de automatización no pueden extraer la ruta correctamente.
Las convenciones fuera de la especificación significan más documentación a menos que también formen parte de la especificación.
Nota: La implementación del análisis estático de SEAJS es utilizar la parte del requisito de extracción regular para obtener la ruta del módulo de dependencia.
Amd
Método de declaración de dependencia del módulo AMD:
La copia del código es la siguiente:
Define (['./ a', './b'], function (a, b) {
// más código ..
})
Las dependencias de AMD se declaran de antemano. La ventaja de esta ventaja es que la dependencia no requiere un análisis estático. Tanto el cargador como la herramienta de automatización pueden obtener directamente dependencias. La definición de la especificación puede ser más simple, lo que significa que se pueden generar implementaciones más poderosas, lo cual es beneficioso tanto para el cargador como para la herramienta de análisis de automatización.
Desventajas de la especificación AMD
Las declaraciones de anticipación de dependencia no son tan amigables en la redacción de códigos.
Hay una cierta diferencia entre el módulo interno y los módulos de NodeJs.
El segundo problema debe explicarse en detalle. De hecho, ni los módulos asincrónicos de CMD ni AMD pueden ser consistentes con la especificación del módulo de sincronización (módulos de NodeJS), solo quién es más como un módulo de sincronización que quién es. Para convertir la AMD en un módulo de sincronización, además de eliminar el paquete de la función Definir, debe usar necesidades en la cabeza para declarar la dependencia, mientras que CMD solo necesita eliminar el paquete de la función Definir.
Resumir
En términos de especificación, AMD es más simple y riguroso, y tiene una aplicabilidad más amplia. Con la fuerte promoción de las necesidades, casi se ha convertido en un estándar de módulo asíncrono de facto en el extranjero, y las principales bibliotecas han apoyado sucesivamente las especificaciones de AMD.
Pero de SEAJS y CMD, también hemos hecho muchas cosas buenas:
1. Estilo de declaración de dependencia relativamente natural
2. Pequeña y hermosa realización interna
3. Diseño cuidadoso de función periférica
4. Mejor apoyo de la comunidad china
Si es posible, espero ver que Seajs también apoya a AMD, y la máxima felicidad de los desarrolladores es la mayoría de los desarrolladores.