Поскольку r.js компилирует модули AMD в один большой файл, где находится "асинхронный" в определении асинхронного модуля?

Question

Мне немного трудно понять, где существует асинхронный аспект архитектуры AMD, когда вы использовали что-то вроде r.js для объединения всех ваших модулей в один большой файл.

В чем преимущество (помимо минимизации) использования r.js по сравнению с простым разрешением require.js асинхронно загружать дискретные js по требованию, не блокируя DOM? Конечно, быстрее загружать только то, что в данный момент требуется приложению (vanilla require.js), чем загружать все, что может понадобиться приложению (скомпилированный r.js).

Answer 1

У AMD нет единой выгоды, если вы решите сделать из нее один пакет, только недостатки, поскольку все, что вы получите, - это пакет кода, смешанный с образцом.

Если вы ищете чистые решения, попробуйте стиль CommonJS, а не шаблон, и с правильными инструментами это намного быстрее, чем AMD (так как асинхронные дисковые операции быстрее, чем асинхронные сетевые операции), с CommonJS ваш код становится также независимым от среды, так что вы можете просто загрузите ваш модуль на сервер (Node.js) и клиент, без дополнительной настройки / взлома.

Проверьте Webmake (я его автор) Уже несколько лет я развиваюсь с ним. Я никогда не оглядывался назад.

Посмотрите также некоторые истории успеха перехода AMD -> CommonJS: http://esa-matti.suuronen.org/blog/2013/03/22/journey-from-requirejs-to-browserify/

Answer 2

Я приведу вам пример для моей компании. У нас есть веб-приложение с одностраничным модулем (каждая вкладка в приложении разрабатывается отдельной командой). У каждой команды есть свой код, и он использует некоторые общие части. В модуле требуются общие части доступа, поэтому они уверены, что он будет доступен (пути одинаковы в комплектных скриптах и ​​на сервере). Это дает возможность создавать связанные файлы для модулей, в которых нет всего.