Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
тоже думал над таким, но всё же остановился на препроцессинге и генерации одного js-файла.
собственно как и делает множество популярных фреймворков (jQuery, extJS, ...)
собственно как и делает множество популярных фреймворков (jQuery, extJS, ...)
Соглашусь, все же js имеет свои особенности. Тем более не всегда эта init нужна. Лучше все одним файликом слать или не одним но с начало все же подгружать все что надо.
Ну это два разных подхода. У обоих и преимущества есть, и недостатки.
Я выбрал такой подход, потому что мне он кажется яснее. Девелоперский цикл короче, опять же (не нужно компилировать мега-скрипт).
Да и кроме того. Фреймворк — это с точки зрения приложения атомарный элемент. Его один раз загрузил и используешь. Поэтому его разумно после разработки скомпилить в один скрипт. Но разработчик приложения, основанного на этом фреймворке, всё равно будет разбивать свой код на модули.
Теоретически можно, конечно, ещё раз всё собрать в большой скрипт. Но в реале я такого ни разу не встречал — тогда после каждого изменения придётся его пересобирать.
В место этого обычно используют костыли :-) причём, часто серверные. Какой-нибудь ужасный xml-файл, содержащий список всех скриптов, которые нужно подключить для каждого приложения. Из этого на сервере генерится огромная хтмл-ка, которая подключает скрипты «классическим» способом.
А, хотя, не слушайте меня. На самом деле мой подход мне нравится больше, потому что он мой :-D
Я выбрал такой подход, потому что мне он кажется яснее. Девелоперский цикл короче, опять же (не нужно компилировать мега-скрипт).
Да и кроме того. Фреймворк — это с точки зрения приложения атомарный элемент. Его один раз загрузил и используешь. Поэтому его разумно после разработки скомпилить в один скрипт. Но разработчик приложения, основанного на этом фреймворке, всё равно будет разбивать свой код на модули.
Теоретически можно, конечно, ещё раз всё собрать в большой скрипт. Но в реале я такого ни разу не встречал — тогда после каждого изменения придётся его пересобирать.
В место этого обычно используют костыли :-) причём, часто серверные. Какой-нибудь ужасный xml-файл, содержащий список всех скриптов, которые нужно подключить для каждого приложения. Из этого на сервере генерится огромная хтмл-ка, которая подключает скрипты «классическим» способом.
А, хотя, не слушайте меня. На самом деле мой подход мне нравится больше, потому что он мой :-D
>Я выбрал такой подход, потому что мне он кажется яснее. Девелоперский цикл короче, опять же (не нужно компилировать мега-скрипт).
кастомный хэндлер для жс запросов на вебсервере в ~30 строк кода и девелоперский цикл как при редактировании обычных жс'ников, только в итоге на выходе мы можем получать как debug, так и release сборки конкретных модулей.
>В место этого обычно используют костыли :-)
То что у вас — это ещё больший костыль.
Посмотрите YUI3 + YLS.
p.s. советую прочитать книжку javascript patterns
кастомный хэндлер для жс запросов на вебсервере в ~30 строк кода и девелоперский цикл как при редактировании обычных жс'ников, только в итоге на выходе мы можем получать как debug, так и release сборки конкретных модулей.
>В место этого обычно используют костыли :-)
То что у вас — это ещё больший костыль.
Посмотрите YUI3 + YLS.
p.s. советую прочитать книжку javascript patterns
Возможно, вы и правы. Мне тут сложно спорить, потому что я с YUI не знаком.
Но у меня уже очень давно создалось впечатление, что так делают чаще всего, потому что по какой-то причине стало принято собирать код в один скрипт. Может быть, потому что в js нет нативного инклуда. Точно также, как принято создавать веб-приложения посредством манипуляции элементами DOM. Наверное как раз поэтому я и пытаюсь использовать другой подход. Без лишних хуков и хендлеров.
Но у меня уже очень давно создалось впечатление, что так делают чаще всего, потому что по какой-то причине стало принято собирать код в один скрипт. Может быть, потому что в js нет нативного инклуда. Точно также, как принято создавать веб-приложения посредством манипуляции элементами DOM. Наверное как раз поэтому я и пытаюсь использовать другой подход. Без лишних хуков и хендлеров.
А с каким фреймворком вы знакомы? По-моему сейчас все так делают. YUI, JQuery UI, Google Closure, ExtJS. Вы правы, делают так «по какой-то причине». Объясню по какой — один большой файл быстрее скачивается и лучше сжимается, чем много маленьких. Причем это применяется не только к скриптам, но и к CSS и даже картинкам (в т.н. виде CSS-спрайтов).
>Наверное как раз поэтому я и пытаюсь использовать другой подход.
очень советую прочитать про модульность в javascript patterns, там вроде даже описаны исторические причины по которым различные мелочи добавлялись :) модульность в yui3 реализована примерно так как в той книжке и описано.
А если про загрузку модулей, то в yui3 есть выбор:
1. (девелоперский вариант) в сервер встроена примитивная компиляция модулей(либо ручная компиляция), на клиенте все метаданные и на клиенте происходит разруливание всех зависимостей.
2. combo — это уже на продакшене висит серверный кусок, который умеет склеивать несколько модулей(модули так же могут быть разбиты на несколько файлов) в один файл, но тут опять есть недостаток — метаданные и лоадер на клиенте.
3. yls — новый подход, скоро будут доступны исходники. Здесь уже лоадер встроен в сервер и он занимается разруливанием зависимостей и выдаёт весь нужный результат. В твиттере можно легко найти восхищения от того насколько сильно поменялась отзывчивость с внедрением подобной системы на некоторых крупных сайтах.
Девелоперский цикл такой же простой как и при обычной разработке, сохранил, в браузере нажал f5 :)
Не понимаю зачем люди пишут свои костыли, толком не ознакомившись с тем что сделано в других системах, ведь там накоплен оч большой опыт. Да, еслиб вам не подошло по каким-либо причинам то что там реализовано — это уже другой разговор.
очень советую прочитать про модульность в javascript patterns, там вроде даже описаны исторические причины по которым различные мелочи добавлялись :) модульность в yui3 реализована примерно так как в той книжке и описано.
А если про загрузку модулей, то в yui3 есть выбор:
1. (девелоперский вариант) в сервер встроена примитивная компиляция модулей(либо ручная компиляция), на клиенте все метаданные и на клиенте происходит разруливание всех зависимостей.
2. combo — это уже на продакшене висит серверный кусок, который умеет склеивать несколько модулей(модули так же могут быть разбиты на несколько файлов) в один файл, но тут опять есть недостаток — метаданные и лоадер на клиенте.
3. yls — новый подход, скоро будут доступны исходники. Здесь уже лоадер встроен в сервер и он занимается разруливанием зависимостей и выдаёт весь нужный результат. В твиттере можно легко найти восхищения от того насколько сильно поменялась отзывчивость с внедрением подобной системы на некоторых крупных сайтах.
Девелоперский цикл такой же простой как и при обычной разработке, сохранил, в браузере нажал f5 :)
Не понимаю зачем люди пишут свои костыли, толком не ознакомившись с тем что сделано в других системах, ведь там накоплен оч большой опыт. Да, еслиб вам не подошло по каким-либо причинам то что там реализовано — это уже другой разговор.
Правда в том, что код обычно компресснут и собран в один скрипт на прод энвайронменте.
А чего там творится на dev-версии никто никогда не узнает, можно написать себе хоть 100500 комбинаций из скриптов, которые вам нужны и компрессить их тем же YUI-компрессором, не используя при этом YUI.
А чего там творится на dev-версии никто никогда не узнает, можно написать себе хоть 100500 комбинаций из скриптов, которые вам нужны и компрессить их тем же YUI-компрессором, не используя при этом YUI.
> Девелоперский цикл короче, опять же (не нужно компилировать мега-скрипт).
добавить в IDE 2 (release + debug) кастомных кнопки?
так же как вариант — commit hook в cvs'ке, только на девелоперской машине по-другому работать будет (не 1 js-файл, а куча модулей).
добавить в IDE 2 (release + debug) кастомных кнопки?
так же как вариант — commit hook в cvs'ке, только на девелоперской машине по-другому работать будет (не 1 js-файл, а куча модулей).
всё очень сильно зависит от приложения, например во фликре в каждой странице стоит небольшой кусок кода, который перехватывает все события и записывает в очередь(на самом деле всё немного сложнее), но в это время пользователь уже может сидеть и наслаждаться фотографией. А когда уже подгрузится жаваскрипт, тот мелкий скрипт начинает плеваться событиями, которые накопил в своей очереди :)
Так экст же нынче автолоадером обзавелся.
Спасибо! Пригодится.
использую модули YUI
А зачем нужна функция init? Почему бы не инициализировать через тут же вызываемую анонимную функцию
(function() {
…
})();
Если так написать, функция будет вызываться сразу во время парсинга скрипта. Мне здесь нужно, чтобы init() вызывалась тогда, когда библиотека посчитает нужным (то есть, когда все зависимости готовы).
Ну и кроме того, это трюк. Стараюсь, чтоб всё проще было, когда возможно.
Ну и кроме того, это трюк. Стараюсь, чтоб всё проще было, когда возможно.
Библиотека инклуд же изначально грузится синхронно. Вместо Init лучше сделать:
Потому что init может уже быть, а в инклуде соответственно проверять не функция ли пришла. Если она, то добавлять в массив коллбэков. А когда всё проинициализировалось — запускать всё в цикле. Можно немного расширить и сделать бонусный параметр после функции с именем необходимого модуля (принимаемые параметры — текстовая строка или массив), тогда можно будет запускать код по мере подгрузки файлов (может некоторому коду достаточно someLibrary и ему не нужно ждать полного окончания загрузки).
include( function(){
someLibrary.doSomething();
var mySomething = new someLibrary.Something();
someOtherLibrary.doSomethingElse();
} )
Потому что init может уже быть, а в инклуде соответственно проверять не функция ли пришла. Если она, то добавлять в массив коллбэков. А когда всё проинициализировалось — запускать всё в цикле. Можно немного расширить и сделать бонусный параметр после функции с именем необходимого модуля (принимаемые параметры — текстовая строка или массив), тогда можно будет запускать код по мере подгрузки файлов (может некоторому коду достаточно someLibrary и ему не нужно ждать полного окончания загрузки).
Я не думаю, что есть смысл дополнительно усложнять ради фич.
Функция include() нужна для того, чтобы указать, что модуль А требует модуль Б. Функция kernel.requre() нужна для того, чтобы в рантайме сказать «загрузи модуль Ц и выполни этот код». Мне кажется, если приравнивать инициализатор к колбэку, то это приведёт к запутыванию кода. Сейчас всё ясно: вот инклуды, а вот код модуля.
А если какому-то коду нужны не все зависимости, тогда этот код нужно выделить в отдельный скрипт и прописать инклуды нужные только ему.
Функция include() нужна для того, чтобы указать, что модуль А требует модуль Б. Функция kernel.requre() нужна для того, чтобы в рантайме сказать «загрузи модуль Ц и выполни этот код». Мне кажется, если приравнивать инициализатор к колбэку, то это приведёт к запутыванию кода. Сейчас всё ясно: вот инклуды, а вот код модуля.
А если какому-то коду нужны не все зависимости, тогда этот код нужно выделить в отдельный скрипт и прописать инклуды нужные только ему.
Наверняка можно, и наверняка я его делать не буду :-)
Но если кто возьмётся — я готов проконсультировать.
Но если кто возьмётся — я готов проконсультировать.
А зачем jQuery-плагин, чем он должен отличаться от текущей реализации? Баксом вместо «kernel»? =)
Сначала прочитал «быдлокодить» :-D
Если честно, ничего не имею против jQuery и бакса, просто это для меня сейчас не самая интересная задача. Поэтому разве что если кто-то другой портирует.
Если честно, ничего не имею против jQuery и бакса, просто это для меня сейчас не самая интересная задача. Поэтому разве что если кто-то другой портирует.
(function(global, $, $include){
$include('some/module.js');
$(function(){
// Kill all humanz
});
})(this, jQuery, kernel.include);Не?
Мне кажется, что инициализация и очистка должны быть повыше уровнем, т.к. в модуль может входить не только js, но и шаблоны, стили, ресурсы, например — а их готовности тоже надо дожидаться, да и чистить хорошо бы. Потому пришлось написать отдельный менеджер модулей, использующий в том числе и лоадер скриптов (я пользую www.dustindiaz.com/scriptjs).
Существует множество скрипт лоадеров: LAB.js, head.js, yepnope.js. Последнтй позволяет подгружать скрипты при определенном условии:
Недавно он даже стал частью Modernizer.js
yepnope({
test : Modernizr.geolocation,
yep : 'normal.js',
nope : ['polyfill.js', 'wrapper.js']
});Недавно он даже стал частью Modernizer.js
+туда же:
RequireJs
RequireJs
туда же:
microjs.com/#loader
microjs.com/#loader
Я добавил в текст небольшой update, поясняющий отличие от других js-лоадеров
Так или иначе, молодец, саморазвитие — это всегда хорошо, а когда пишешь что-то подобное, то набираешься опыта.
Имхо автор молодец!
Имхо автор молодец!
Вот ещё одна реализация
www.artlebedev.ru/tools/technogrette/js/include/
www.artlebedev.ru/tools/technogrette/js/include/
Утки, надеюсь, не пострадали? :D
CommonJS структура, на мой взгляд, лучше подходит для использования в javascript. В node.js можно использовать github.com/substack/node-browserify — он автоматически заменить вызовы require так, что все будет работать, как будто вызов был блокирующим.
уровни модуляризации:
0 — всё единым файлом
когда объём кода превышает 9000:
1 — разбиение на файлы с ручным указанием зависимостей
когда число модулей превышает 9000:
2 — автоматическое вычисление зависимостей
когда число разработчиков модулей превышает 9000:
3 — автоматическое скачивание и установка зависимостей
0 — всё единым файлом
когда объём кода превышает 9000:
1 — разбиение на файлы с ручным указанием зависимостей
когда число модулей превышает 9000:
2 — автоматическое вычисление зависимостей
когда число разработчиков модулей превышает 9000:
3 — автоматическое скачивание и установка зависимостей
Такое ощущение, что в этой области каждый хочет повелосипедить по своему.
Мой велосипед github.com/dmitry-dedukhin/jsLoader и демо dmitry-dedukhin.github.com/jsLoader/
Мой велосипед github.com/dmitry-dedukhin/jsLoader и демо dmitry-dedukhin.github.com/jsLoader/
В рамках инициативы common.js
загрузку модулей стандартизовали, как для клиентского и сервеного JS
See Asynchronous Module Definition (AMD)
Одна из реализаций AMD => Require.js
загрузку модулей стандартизовали, как для клиентского и сервеного JS
See Asynchronous Module Definition (AMD)
Одна из реализаций AMD => Require.js
nicola, я уже давно внимательно изучил эту спецификацию, и считаю, что это полнейший балщит :-D
я уверен, людей которые составляли эту спецификацию скоро отпустит, и они поймут, что так кодить нельзя :-)
я уверен, людей которые составляли эту спецификацию скоро отпустит, и они поймут, что так кодить нельзя :-)
why?
слишком много библиотек уже использует AMD:
dojo => dojotoolkit.org/features/1.6/async-modules
ace editor (bespin) => ace.ajax.org/
все модули Node.js => nodejs.org/docs/v0.5.7/api/modules.html
…
Есть излишняя писанина, но зато можно две разные версии одной библиотеки загрузить. И в принципе очень изящное решение.
слишком много библиотек уже использует AMD:
dojo => dojotoolkit.org/features/1.6/async-modules
ace editor (bespin) => ace.ajax.org/
все модули Node.js => nodejs.org/docs/v0.5.7/api/modules.html
…
Есть излишняя писанина, но зато можно две разные версии одной библиотеки загрузить. И в принципе очень изящное решение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Helios Kernel (удобный include в Javascript)