На сколько я помню, в webpack нет возможности загружать модули по требованию, это только сборщик модулей (module bundler), а не загрузчик модулей (module loader), как requirejs. В статье описано несколько кейсов, когда динамическая загрузка модулей очень полезна.
По-моему самое интересное в yeoman даже не генерация шаблона всего приложения целиком. Как тут уже сказали, это разовая операция и писать под нее такую мощную утилиту было бы странно. Главное, что yeoman может генерировать отдельные части уже созданного приложения, те же контроллеры, например. Вот наглядный пример из офф документации:
$ yo angular:controller myController
$ yo angular:directive myDirective
$ yo angular:filter myFilter
$ yo angular:service myService
Это действительно может помочь в ежедневной рутине, если модули приложения имеют сложную, но схожую структуру.
С ним подключение зависимостей выглядит более традиционно:
define(function(require) {
//Сразу сохраняем зависимости в нужные переменные
var a = require('a'),
b = require('b');
//Экспортируем API
return function () {};
}
);
не удалось быстро разобраться как, при сборке проекта быстро минифицировать и склеивать файлы в нужной мне последовательности
requirejs.org/docs/optimization.html — отличный сборщик AMD модулей, хорошо документированный, с огромным количеством настроек. Или вас именно это и не устроило?
Вот из-за последней ложки дегктя, относительные единицы измерения очень трудно использовать на больших проектах и это перекрывает все их достоинства. Большим поклонником em-ов был Яндекс, но и они постепенно переходят на px, например, тут: habrahabr.ru/company/yandex/blog/149327/:
Практически на всех наших сервисах сейчас используется указание размеров в относительных процентах или тегах em, но в новом проекте мы решили отказаться от них в пользу пикселей. Аргументов у этого решения несколько. Во-первых, доля браузеров, которые не умеют масштабировать шрифты в пикселях, исчезающе мала. Во-вторых, размеры в абсолютных единицах исключают влияние контекста, а вёрстка абсолютно независимыми блоками — один из основных принципов БЭМ-методологии. Ну и в-третьих, страница результатов поиска должна нормально работать на тач-устройствах. Разрешение экрана на них часто заранее известно и строго фиксировано, а меняться может только его ориентация.
Относительные единицы измерения создают сильную связанность между блоками, а от сильной связанности, как известно, лучше избавляться.
Вы все версии оперы имеете ввиду? Лимит по ширине у всех опер 32767px, кажется, это да. Потом перенесет все на след. строку. Во всех остальных браузерах этого глупого лимита нет, там все впорядке будет.
это уже совершенно отдельный вопрос оптимизации, вполне решаемый. Да и не обязательно там картинки должны быть, это я для примера привел. Вариантов может быть огромное количество.
использование подобных штук в курпных проектах мне показалось ацким адом по двум причинам:
1) практически полное отсутствие поддержки со стороны наиболее популярных IDE (eclipse, netbeans, idea, phpstorm), а в крупных проектах без таких IDE никуда. Фактически редактирование идет в блокноте. Все IDE-расширения и плагины, которые я видел для SASS крайне убоги даже в плане автодополнения кода (автодополнения переменных я не встретил нигде). Возможно сейчас ситуация поправилась, но до уровня редактирования CSS в IDE SASS и компания врядли доберется.
2) про дебаг css-кода в фаербаге можно забыть. То что вы увидете в фаербаге (стандартный css) будет в корне отличаться от файла SASS, который вы редактируете: строки будут разные, иерархия селекторов другой. Поможет только поиск и то, если не используется вложенность. Когда мне по наследству достался большой (но кривой) проект написанный с использованием SASS, я не придумал ничего лучше, чем заменить все SASS на CSS (копированием из браузера), что бы можно было работать с фаербагом.
Вобщем безумия этого я тоже не понимаю. CSS довольно гибкий и вполне достаточный даже для крупных проектов, а его интеграция с IDE и др. редакторами делает его в разы удобнее любого SASS
Вы этот пост, случайно, не под впечатлением книги Алана Купера «Об интерфейсе» писали? ) Очень похоже на тезисы нескольких первых глав. У меня, по крайней мере, после прочтения книги похожие мысли на счет проектирования сложились. +)
Это действительно может помочь в ежедневной рутине, если модули приложения имеют сложную, но схожую структуру.
На этот случай в requirejs есть, так называемый, «commonjs wrapper»: requirejs.org/docs/api.html#cjsmodule
С ним подключение зависимостей выглядит более традиционно:
requirejs.org/docs/optimization.html — отличный сборщик AMD модулей, хорошо документированный, с огромным количеством настроек. Или вас именно это и не устроило?
Относительные единицы измерения создают сильную связанность между блоками, а от сильной связанности, как известно, лучше избавляться.
1) практически полное отсутствие поддержки со стороны наиболее популярных IDE (eclipse, netbeans, idea, phpstorm), а в крупных проектах без таких IDE никуда. Фактически редактирование идет в блокноте. Все IDE-расширения и плагины, которые я видел для SASS крайне убоги даже в плане автодополнения кода (автодополнения переменных я не встретил нигде). Возможно сейчас ситуация поправилась, но до уровня редактирования CSS в IDE SASS и компания врядли доберется.
2) про дебаг css-кода в фаербаге можно забыть. То что вы увидете в фаербаге (стандартный css) будет в корне отличаться от файла SASS, который вы редактируете: строки будут разные, иерархия селекторов другой. Поможет только поиск и то, если не используется вложенность. Когда мне по наследству достался большой (но кривой) проект написанный с использованием SASS, я не придумал ничего лучше, чем заменить все SASS на CSS (копированием из браузера), что бы можно было работать с фаербагом.
Вобщем безумия этого я тоже не понимаю. CSS довольно гибкий и вполне достаточный даже для крупных проектов, а его интеграция с IDE и др. редакторами делает его в разы удобнее любого SASS