Pull to refresh

Comments 8

grunt уж совсем банальный — дали ему список скриптов — он собрал. A вот brunch похоже хорош, больше возможностей, но тот же принцип — собираю все что в папке по алфавиту. Или тот же конфиг файл, как у грант. Но во многих случаях и этого достаточно. Спасибо, что поделились.
UFO just landed and posted this here
Важно (покрайней мере мне), что бы зависимости не лежали списком в отдельных файлах, и тем более не в одном, как у инструментов выше ( это получается, если я хочу подключить доплнительный модуль, я должен указать путь к ниму, и вспомнить его зависимости, что бы тоже указать в файле для сборки. А этих зависимостей может быть много, и не только скрипты, но и хтмл, и стили). Если я хочу подключить один javascript файл, он сам должен подключить, всё что ему надо. Если он подключил другой javascript, тот в свою очередь, подключает свои зависимости, ну и т.д. Тут как раз самое важно — контекст подключение ресурсов — он должен быть в управлении самих скриптов. Вот мы и получили систему подключения ресурсов, она может работать и без сборки. По скорости не уступает разным AMD системам, и если честно, если приложение не большое, я даже редко и собираю. А вот если побольше, тут и вступает сборщик ресурсов. Собсвенно он просто склеивает ресурсы — скрипты, стили, шаблоны, ленивые скрипты(что не мало важно в большых приложениях) — но берет он это все от системы подключения ресурсов. Ну вот наверное это все по конкатенация скриптов.
UFO just landed and posted this here
не, ну как-то слишком сложно)

как у него с поддержкой ie9-? во время подгрузки скриптов жизнь в браузере замирает?

я вот остановился на такой схеме: всё приложение делится на набор пакетов, пакеты на модули, в модулях уже скрипты, стили, картинки, шаблоны. сборщик пробегается по ним и «собирает пакеты». шаблоны в одну кучку, стили в другую, скрипты в третюю. при этом статически же определяются зависимости: из шаблонов определяется какие компоненты используются и подключаются одноимённые модули (целиком, со всеми ресурсами и их зависимостями), аналогично разруливаются зависимости между скриптами (используется простое соглашение: $jam.Component — модуль Component из пакета jam). в результате получается на каждый тип файла два варианта — отладочный с пофайловым подключением и релизный со слиянием воедино. есть ещё вариант со сквозной минификацией, когда атомы (http://habrahabr.ru/post/97670/) в шаблонах, стилях и скриптах заменяются на короткие

Сложно? Ничего сложного, заинклудили ресурсы — готово. Можна даже не собирать все в кучу, все будет прекрасно подгружатся, задумались о релизе — собрали. С поддержкой ие вам точно не скажу. Это все дело хорошо протестировано на wебкитах, так как сам я разрабатываю хтмл5 приложения для десктопов и мобилных с wебкит-контэйнером.
Скрипты и прочие ресурсы подгружаются асинхронно, так что ничего не замирает. А jam использует reuirejs? или я нето нашел?
сложность в том, что нужно настраивать, инклудить. куда удобней иметь какой-нибудь аналог автолоада из пхп. причём автолоада целиком модуля (клиентские скрипты, стили, локали, серверные скрипты, документация, шаблоны).

в иешках проблема с __defineGetter__

а в геттере только eval происходит, но загрузка должна быть произведена заранее асинхронно?

не то. там у меня ещё всё сыро.
jam — микроядерный яваскриптовый фреймворк nin-jin.github.com/jam/jam/jam.doc.xml
по ссылке собственно пример собранной документации.
сборщик написан на коленке. пока собирает сразу все пакеты и не умеет вычитать модули одного из другого. github.com/nin-jin/web-components/tree/master/so/Compile
Sign up to leave a comment.

Articles