Comments 5
Так же как CommonJS больше подходит для вне-браузерной среды, цепочные определения модулей с их требованиями, идеально вписываются во внутри-браузерные сценарии использования.Не согласен. CommonJS подходит для браузера, но для вебного. AMD же идеально подходит для мобильного WebView браузера, где накладные расходы на количество файлов (обращений к диску) не так велики, как выигрыш от ленивости. В вебе же — наоборот. Если AMD используется в вебе, то всё равно нужно сконкатенировать все определения и добавить в них имена, а затем использовать минимальный загрузчик, типо almond. Это уже нельзя назвать «идеалом».
Функция require() в commonJS, в браузере, не может заблокировать выполнение до загрузки нужного модуля, если он еще не загружен. В результате с CommonJS может быть важен порядок загрузки модулей. Что несколько усложняет жизнь.
Все остальное, включая то как склеивать модули — задача инструментов. По возможностям в этом плане AMD точно не хуже CommonJS.
Все остальное, включая то как склеивать модули — задача инструментов. По возможностям в этом плане AMD точно не хуже CommonJS.
Я не говорю об использовании функции require напрямую. На клиенте CommonJS требует сборки. Но так как AMD тоже, вообще говоря, лучше собрать, чтобы уменьшить количество файлов, мы получаем одинаковые условия. При этом, CommonJS: менее громозкая структура файла, множество пакетов npm, возможность разделять код с сервером.
Sign up to leave a comment.
[Подборка] Melchior.js, ng-admin, Hello.js, ineed