Да, я думаю, что это трюк. Такой же, как и var me=this. Я не проводил тестов на скорость, но по идее это замедляет производительность, поскольку ключевые слова резолвятся непосредственно, а обращение к переменным приводит к линейному поиску по скопу.
Если честно, ничего не имею против jQuery и бакса, просто это для меня сейчас не самая интересная задача. Поэтому разве что если кто-то другой портирует.
Я не думаю, что есть смысл дополнительно усложнять ради фич.
Функция include() нужна для того, чтобы указать, что модуль А требует модуль Б. Функция kernel.requre() нужна для того, чтобы в рантайме сказать «загрузи модуль Ц и выполни этот код». Мне кажется, если приравнивать инициализатор к колбэку, то это приведёт к запутыванию кода. Сейчас всё ясно: вот инклуды, а вот код модуля.
А если какому-то коду нужны не все зависимости, тогда этот код нужно выделить в отдельный скрипт и прописать инклуды нужные только ему.
Возможно, вы и правы. Мне тут сложно спорить, потому что я с YUI не знаком.
Но у меня уже очень давно создалось впечатление, что так делают чаще всего, потому что по какой-то причине стало принято собирать код в один скрипт. Может быть, потому что в js нет нативного инклуда. Точно также, как принято создавать веб-приложения посредством манипуляции элементами DOM. Наверное как раз поэтому я и пытаюсь использовать другой подход. Без лишних хуков и хендлеров.
Если так написать, функция будет вызываться сразу во время парсинга скрипта. Мне здесь нужно, чтобы init() вызывалась тогда, когда библиотека посчитает нужным (то есть, когда все зависимости готовы).
Ну и кроме того, это трюк. Стараюсь, чтоб всё проще было, когда возможно.
Ну это два разных подхода. У обоих и преимущества есть, и недостатки.
Я выбрал такой подход, потому что мне он кажется яснее. Девелоперский цикл короче, опять же (не нужно компилировать мега-скрипт).
Да и кроме того. Фреймворк — это с точки зрения приложения атомарный элемент. Его один раз загрузил и используешь. Поэтому его разумно после разработки скомпилить в один скрипт. Но разработчик приложения, основанного на этом фреймворке, всё равно будет разбивать свой код на модули.
Теоретически можно, конечно, ещё раз всё собрать в большой скрипт. Но в реале я такого ни разу не встречал — тогда после каждого изменения придётся его пересобирать.
В место этого обычно используют костыли :-) причём, часто серверные. Какой-нибудь ужасный xml-файл, содержащий список всех скриптов, которые нужно подключить для каждого приложения. Из этого на сервере генерится огромная хтмл-ка, которая подключает скрипты «классическим» способом.
А, хотя, не слушайте меня. На самом деле мой подход мне нравится больше, потому что он мой :-D
На самом деле, я не имел в виду, что это какой-то потенциальный риск. Мне просто любопытно, предусмотрели ли они какой-нибудь способ борьбы с этим, или же это на усмотрение пользователя (мол, если сам не захотел пользоваться телефоном — твои проблемы)
В общем-то да. Но тогда выходит, что пользователь может сам для своего удобства изначально указать, что его *конкретный* телефон — тот, что эмулятор. Тогда по идее он сможет логиниться только с помощью компьютера.
Не, ничего плохого. Тут просто ироничный оффтопик с первых комментов: шрифт был выбран чересчур провокационный у вас =)
PS Когда по картинке становится ясно, о чём будет первый коммент, а потом зайдя под кат видишь, что первого коммента НЕТ — истинное мастерство состоит в том, чтоб этот коммент не писать :)
Исходный запакованный: 7299 байт
Минимизированный и запакованный: 2038 байт
Оптимизированный по описанным методам, минимизированный и запакованный: 1653 байта
Если использовать компрессию — почти полкило экономится для этого случая :-)
Если честно, ничего не имею против jQuery и бакса, просто это для меня сейчас не самая интересная задача. Поэтому разве что если кто-то другой портирует.
Функция include() нужна для того, чтобы указать, что модуль А требует модуль Б. Функция kernel.requre() нужна для того, чтобы в рантайме сказать «загрузи модуль Ц и выполни этот код». Мне кажется, если приравнивать инициализатор к колбэку, то это приведёт к запутыванию кода. Сейчас всё ясно: вот инклуды, а вот код модуля.
А если какому-то коду нужны не все зависимости, тогда этот код нужно выделить в отдельный скрипт и прописать инклуды нужные только ему.
:-D
Но у меня уже очень давно создалось впечатление, что так делают чаще всего, потому что по какой-то причине стало принято собирать код в один скрипт. Может быть, потому что в js нет нативного инклуда. Точно также, как принято создавать веб-приложения посредством манипуляции элементами DOM. Наверное как раз поэтому я и пытаюсь использовать другой подход. Без лишних хуков и хендлеров.
Но если кто возьмётся — я готов проконсультировать.
Ну и кроме того, это трюк. Стараюсь, чтоб всё проще было, когда возможно.
Я выбрал такой подход, потому что мне он кажется яснее. Девелоперский цикл короче, опять же (не нужно компилировать мега-скрипт).
Да и кроме того. Фреймворк — это с точки зрения приложения атомарный элемент. Его один раз загрузил и используешь. Поэтому его разумно после разработки скомпилить в один скрипт. Но разработчик приложения, основанного на этом фреймворке, всё равно будет разбивать свой код на модули.
Теоретически можно, конечно, ещё раз всё собрать в большой скрипт. Но в реале я такого ни разу не встречал — тогда после каждого изменения придётся его пересобирать.
В место этого обычно используют костыли :-) причём, часто серверные. Какой-нибудь ужасный xml-файл, содержащий список всех скриптов, которые нужно подключить для каждого приложения. Из этого на сервере генерится огромная хтмл-ка, которая подключает скрипты «классическим» способом.
А, хотя, не слушайте меня. На самом деле мой подход мне нравится больше, потому что он мой :-D
PS Когда по картинке становится ясно, о чём будет первый коммент, а потом зайдя под кат видишь, что первого коммента НЕТ — истинное мастерство состоит в том, чтоб этот коммент не писать :)