Dependency Injection. JavaScript

Согласен с тем, что, например AMD или CJS модули могут быть контейнерами сервисов. Но считаю, что это скорее побочный эффект оптимизаций загрузки, который использовать в архитектурных целях не очень правильно. Про синтаксические конструкции — можно подробнее? =)

Со вторым абзацем не согласен. На мой взгляд использование DI упрощает поддержку системы. «Go to declaration» поддерживается в CJS модулях, например Idea, а паттерн никак не влияет на связи в расположении классов.

Dependency Injection. JavaScript

В вашем примере вы инкапсулировали только реализацию логгера, но его создание и конфигурация лежит в ответственности модуля myModule. myModule должен знать о конфигурации логгера? Или в myApp/myLogger уже создается и конфигурируется экземпляр? ) Как можно поменять конфигурацию логгера?

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

Однако, стоит помнить, что jQuery спагетти-код тоже совсем недавно считался «JS-way». =)

Dependency Injection. JavaScript

Простыми словами мы заменяем зависимость от конкретных сервисов на зависимость от Сервис Локатора. При этом он сам по себе должен быть легко переносимым.

Не совсем так. Зависимость от сервисов все равно остается, при этом добавляется еще одна зависимость от Сервис Локатора.

Но тогда нам придется инициализацию каждого плагина привязать к Сервис Локатору, хотя вызываемые у него сервисы могут быть использованы лишь несколькими методами плагина, а они могут не использоваться в данном приложении. И получается, что обязательная зависимость от Локатора для идеального плагина — лишняя.

Здесь немного не понял. Мы не привязываем инициализацию, мы делегируем создание объектов IoC контейнеру, вместо того, чтобы создавать объекты самим.

Генерация CSS-спрайтов с Gulp

Если что — велкам в issues =)

Генерация CSS-спрайтов с Gulp

Да )

Генерация CSS-спрайтов с Gulp

Ну да, вопрос в идеологии разработки еще.

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

Поддержки ретины нет, есть только поддержка нотации ([e-mail]), на основании которой, можно правильно группировать спрайты =)

Генерация CSS-спрайтов с Gulp

Ну, изначально, у вас есть просто картинки для использования в css. Они совсем не спрайты, и даже разные состояния, скажем, кнопочек — у вас тоже разные картинки. Это исходники, точно такие же, как любой другой код. При сборке проекта, вы эти картинки, как и любой другой код, компилируете по какой-то логике. Когда вы, например, используете uglify, вы же не пишете для этого процесса какой-то код в исходниках? Точно так же и со спрайтами — вам не нужно нигде в .less или .css файлах использовать миксины, полученные, по факту, при компиляции исходников изображений =) Т.е. разработчик css и картинок совсем не должен знать о том, что произойдет с его творением при билде =)

Генерация CSS-спрайтов с Gulp

gulp-sprite-generator был написан как раз из-за невозможности юзать официальный порт spritesmith в «реверс» режиме — из css в css + sprites, без миксинов и прочего лишнего кода =)

Как писать парсеры на JavaScript

Интересная статья, интересные комментарии. Спасибо!

Как писать парсеры на JavaScript

Спасибо за ссылку =) Очень интересная статья =)

js2js: компилятор из JavaScript в JavaScript

Почитал код проекта. Понравилось, как используется bottom up парсер, хорошее синтаксическое ядро и неплохой словарь. Ребят ждет большое будущее!

Асинхронная добыча меток utm

GA проставляет свои метки не только из GET параметров.

upd. Например, хорошо описано тут.

Асинхронная добыча меток utm

Да, конечно. Например, в GET запросе у нас меток нет, но мы можем вытащить их из __utmz куки от Google Analytics, которая, в свою очередь, проставляется после загрузки и инициализации их библиотеки ga.js. А спрашиваем мы метки, например, до этой загрузки.