Javascript - Почему существует спецификация для модулей синхронизации и асинхронности?

Ответ 1

Это хороший вопрос. Это тема, которая вызвала много горячих дискуссий в сообществе Node. Чтобы иметь хорошее представление о том, что вам нужно, читайте:

• Node.js, TC-39 и модули Джеймса М Снелла из iBM
• Функциональность модуля ES6 - Node.js Предложения по улучшению
• В защиту .js - Предложение для Node.js Модули Дейва Хермана, Иегуды Каца и Кариди Патиньо
• Обсуждение Запрос Pull № 3 из node -eps (002: интерфейс модуля ES6)

Теперь, отвечая на ваш вопрос - Почему существует спецификация для модулей синхронизации и асинхронности? Потому что некоторые usecases предпочитают синхронную загрузку модулей, таких как серверные модули в Node.js, где вы хотите загрузить все, что вам нужно, прежде чем запускать запросы на обслуживание, а некоторые usecases предпочитают асинхронную загрузку модулей, например, в браузере, когда вы не хотите блокировать поток рендеринга при загрузке зависимостей.

В браузере действительно нет возможности для синхронной загрузки, потому что это сделает браузер нечувствительным.

Можно утверждать, что вы можете использовать асинхронную загрузку на сервере, но тогда вам придется либо возвращать promises вместо модулей на require(), либо принимать обратные вызовы. В любом случае это сделает любой сложный код, который использует много модулей намного сложнее.

Другая проблема связана с кэшированием и мутацией уже загруженных модулей. При синхронной загрузке модуля с помощью require вы загружаете только модуль один раз и любые другие вызовы require для того же модуля во всей базе кода (для этого процесса) возвращают кешированный ответ, который каждый раз является одним и тем же объектом. Любая часть кода может модифицировать этот объект и доступна для любой другой части кода. Некоторые функции, которые используют эту функцию, будут намного сложнее реализовать. Кроме того, сложнее предсказать порядок загрузки и выполнения кода.

Подводя итог ответу на ваш вопрос, есть аргументы для обоих способов загрузки модулей, и ни один из этих способов не является явным победителем для каждого сценария. Оба они необходимы, и оба имеют некоторые спецификации для стандартизации их поведения.

Прочитайте статьи, которые я связал для более подробного понимания.

Ответ 2

Я имею в виду, что поведение загрузки модуля зависит от загрузчика модуля, а не от того, как модуль структурирован. И если это так, то зачем следовать шаблону кодирования для разных типов модулей?

Независимо от того, загружен ли модуль синхронно или асинхронно, зависит от загрузчика модуля, но ваш модуль должен иметь возможность использовать загрузчик модуля, поэтому он должен включать интерфейс для связи с загрузчиком. Вы не можете загружать модули в node.js, используя функцию amd define. Вы должны использовать require.

Если мое предположение верно, тогда почему существует спецификация для UMD? Я имею в виду, если script загружается на основе среды, в которой он присутствует, то зачем создавать спецификацию для загрузки универсального модуля?

Script не загружается на основе среды, он загружается через интерфейс загрузчика. UMD предназначен для библиотек, которые люди используют как в браузере, так и на сервере. Автору библиотеки не нужно создавать две версии библиотеки: одну для браузера и одну для node, потому что UMD знает, как обрабатывать оба.