Comments 5
Так же как CommonJS больше подходит для вне-браузерной среды, цепочные определения модулей с их требованиями, идеально вписываются во внутри-браузерные сценарии использования.
Не согласен. CommonJS подходит для браузера, но для вебного. AMD же идеально подходит для мобильного WebView браузера, где накладные расходы на количество файлов (обращений к диску) не так велики, как выигрыш от ленивости. В вебе же — наоборот. Если AMD используется в вебе, то всё равно нужно сконкатенировать все определения и добавить в них имена, а затем использовать минимальный загрузчик, типо almond. Это уже нельзя назвать «идеалом».
Функция require() в commonJS, в браузере, не может заблокировать выполнение до загрузки нужного модуля, если он еще не загружен. В результате с CommonJS может быть важен порядок загрузки модулей. Что несколько усложняет жизнь.

Все остальное, включая то как склеивать модули — задача инструментов. По возможностям в этом плане AMD точно не хуже CommonJS.
Я не говорю об использовании функции require напрямую. На клиенте CommonJS требует сборки. Но так как AMD тоже, вообще говоря, лучше собрать, чтобы уменьшить количество файлов, мы получаем одинаковые условия. При этом, CommonJS: менее громозкая структура файла, множество пакетов npm, возможность разделять код с сервером.
Есть случаи когда сборка в один большой кусок — не лучший вариант:
— во время разработки удобнее цеплять все файлы отдельно
— в больших проектах имеет смысл клеить скрипты в несколько больших кусков, и подгружать их по мере необходимости. С AMD такое делается проще
Что касается нескольких файлов, то тут я согласен. И чем больше файлов, тем сильнее преимущество AMD. Лучший кейс для AMD это WebView мобильного девайса.
Что касается разработки, то browserify умеет делить кусок на бандлы. А ещё есть кеширующие сборщики.

Only those users with full accounts are able to leave comments. Log in, please.