«История-это не прошлое, история поставлена. С быстрой развитием W3C и браузеров фронтальное модульное развитие постепенно станет инфраструктурой. Все в конечном итоге станет историей, и будущее будет лучше». - Я лично согласен с последним абзацем оригинального текста Ю Бо. Поскольку мы говорим о «будущем», я лично считаю, что если модуль JS Front-End продолжает развиваться, его формат модуля, вероятно, станет стандартной спецификацией для будущей сети и создаст несколько методов реализации. Так же, как формат JSON, он в конечном итоге становится стандартным и внедряется внедренным браузером.
У кого есть лучший стандарт для асинхронных модулей, чтобы стать будущим? Seajs следует по спецификации CMD, requirejs следует спецификации AMD, давайте начнем с этих двух разных форматов.
CMD
Метод объявления зависимостей CMD -модуля:
Кода -копия выглядит следующим образом:
определить (function (require) {
var a = require ('./ a');
var b = require ('./ b');
// больше кода ..
})
Зависимости CMD объявляются поблизости и объявляются с помощью внутренних методов. Однако, поскольку это асинхронный модуль, загрузчик должен загружать эти модули заранее, поэтому до фактического использования модуля необходимо извлечь все зависимости в модуле. Будь то извлечение погрузчика или предварительное экспрессирование с помощью автоматизированных инструментов, этот формат объявления зависимости CMD может быть реализован только посредством статического анализа, который является недостатком CMD.
Недостатки спецификаций CMD
Не может напрямую сжать: Требуется локальная переменная, что означает, что ее нельзя сжать непосредственно через инструмент сжатия. Если заменяется переменная требования, инструменты загрузчика и автоматизации не смогут получить зависимости модуля.
Модуль имеет дополнительную соглашение: параметры пути не могут быть строковыми операциями, и вместо этого нельзя использовать переменные, в противном случае инструменты загрузчика и автоматизации не могут правильно извлечь путь.
Конвенции за пределами спецификации означают больше документации, если они также не являются частью спецификации.
ПРИМЕЧАНИЕ. Реализация SeaJS Static Analysis заключается в том, чтобы использовать часть требования к регулярной добыче для получения пути модуля зависимости.
Амд
Метод объявления зависимостей AMD модуля:
Кода -копия выглядит следующим образом:
определить (['./ a', './b'], function (a, b) {
// больше кода ..
})
Зависимости AMD объявляются заранее. Преимущество этого преимущества состоит в том, что зависимость не требует статического анализа. Как погрузчик, так и инструмент автоматизации могут напрямую получать зависимости. Определение спецификации может быть проще, что означает, что могут быть сгенерированы более мощные реализации, что полезно как для загрузчика, так и для инструмента анализа автоматизации.
Недостатки спецификации AMD
Декларации о предварительном отношении зависимости не так дружелюбны в написании кода.
Существует определенная разница между модулем внутри и модулями Nodejs.
Вторая проблема должна быть подробно объяснена. Фактически, ни CMD, ни асинхронные модули AMD не могут соответствовать спецификации модуля синхронизации (модули Nodejs), только кто больше похож на модуль синхронизации, чем кто есть. Чтобы преобразовать AMD в модуль синхронизации, в дополнение к удалению пакета функции Define, вам необходимо использовать потребности в голове для объявления зависимости, в то время как CMD должен только удалить пакет функции определения.
Суммировать
С точки зрения спецификации, AMD проще и строгим, и имеет более широкую применимость. Благодаря сильному продвижению требований, он почти стал фактическим стандартом асинхронного модуля за рубежом, и основные библиотеки последовательно поддерживали спецификации AMD.
Но из Seajs и CMD мы также сделали много хороших вещей:
1. Относительно естественный стиль заявления о зависимости
2. Маленькая и красивая внутренняя реализация
3. Тщательная конструкция периферической функции
4. лучшая поддержка китайского сообщества
Если возможно, я надеюсь, что SeaJS также поддерживает AMD, а окончательное счастье разработчиков - большинство разработчиков.