Да, я упорот:)
JQuery, тем не менее, остается такой же громоздкой и приземленной, а также убивает навыки написания чистого и красивого vanilla-кода или не дает их получить...
Быстро, просто и со вкусом - это не про JQ, если под быстротой подразумевается скорость работы кода... В определенные моменты "задержка" чувствуется (не так уж и редко, как можно подумать). Именно JQuery не использую принципиально... С одной стороны, из-за этой библиотеки в свое время не получил знания основ и вообще понимания JS, с другой - принципиально не хочу грузить ~100кб кода в браузер. Если собрать JQ под себя, изменится не особо-то и много: весит больше, чем весь мой легкий foront-end и т.п.
Даже если поддержка старинных браузеров не нужна, 2.0 и 3.0 весят примерно столько же, сколько и 1.0, так что... разница не очень-то и велика.
Подобных JQuery библиотек море, (по 10кб, с нужным функционалом, с поддержкой IE8 (если это нужно) и т.п., включая поддержку БОЛЬШИНСТВА JQuery-плагинов), но нужны ли вообще JQuery-like либы? Стоит ли тащить вообще знак доллара (глобальную переменную) в проект? Или (при моем раскладе) лучше полностью отказаться от этого, уйдя в сторону пары-тройки Element.prototype.smth = function () { }?
Да, я знаю, но здесь речь идет о совете, что делать с используемыми функциями. Не вижу вариантов, кроме как создать просто отдельный файл с необходимым (потому что тащить за собой доллар ради двух-трех-четырех функций - это, наверное, смешно (поправьте, если не так)). Вопрос состоит в том, есть ли другие решения или предложениям именно по организации такого "кода".
xmoonlight, а кто сказал, что LazyLoad - библиотека? Судя по моим предыдущим словам, это фича, не библиотека. Про отношение - это ответ на ваш предыдущий комментарий, где вы упомянули LazyLoad, коего в вашей библиотеке нет.
Про base64: прекрасно знаю, что и как, простите, если не очень понятно выражаюсь в комментариях, - надеялся, что пишу доступным языком.
Видимо, в начале всей дискуссии, неверно понял ваши слова про base64. Была затронута тема про лишние запросы для каждого "куска" html, загружаемого вашей библиотекой. Далее вы пишете про base64, как решение (так мне показалось). Ошибочно подумал, что есть какой-то магический способ получить html+"куски" (подгружаемые includeHTML) через js одним запросом, "переделав" их в base64-формат...и вы хотите его применить, просите предложений по этому поводу... Приношу свои извинения.
LazyLoad в includeHTML использовать, конечно, можно, если вы имели ввиду, что это - хорошее решение. Главное - то, как оно будет работать: например, если вставляется футер, до которого нужно скроллить относительно долго, LazyLoad - неплохое решение, ИМХО. Главное - чтобы это не было в ущерб основному функционалу вашей библиотеки.
(вероятно, сейчас выступаю в роли Капитана Очевидность)
xmoonlight, лишь попытался развить идею с получением всех элементов конента за один запрос.
LazyLoad - это фича, причем не имеющая отношения к вашему замечательному includeHTML.
Да, прикрутить можно, но речь не об этом: вы просили написать, как лучше сделать - изложил выше свое мнение.
xmoonlight, возможно, у меня знаний не хватает (а это возможно), но даже не представляю, как за один запрос запихать запрашиваемые изображения и скрипты в base64. Если это возможно (если правильно понял вашу мысль, идею), то в ряде случаев это было бы очень полезно! Аудио и видео в base64 переводить ненужно, а вообще... Лучше (если это, опять же, возможно) сделать это опционально, грубо говоря, так:
(пример для большей ясности, пусть и так все ясно).
Зачастую (при подгрузке отдельных страниц, например) неважно, промотал ли пользователь вниз, а иногда достаточно будет (в случае с лендингом) в base64 впихнуть LazyLoad, и изображения загружать им по мере прокрутки...
Роман Бережнов, ваша правда, согласен. Тоже люблю всякие вещи вроде: "А что, если скорость интернета упадет до 5-10кб/с у всех сразу, и никто не будет ждать 10 минут, пока тяжеловесные скрипты весом в сумме в мегабайт загрузятся" (без шуток).
Роман Бережнов, аргумент про отключенный js устарел лет на 10, откровенно говоря. Так что это проблема самих пользователей, ИМХО, - то то же самое, что сидеть с IE4.
xmoonlight, спасибо, недавно открывал, но тогда еще не задумывался о переделке приложения, сейчас эти ссылки весьма кстати, перечитаю с большим осмыслением и относительным пониманием, что именно необходимо.
xmoonlight, согласен... у меня пока костыли для IE8, от костылей для Chrome убежал, слава богу.
Тут проблема в использовании кривых либ для красивого отображения картинок в галерее, которые руками правил, чтобы телефоны от них не зависали, например. На демо-сайтах библиотек все в порядке, картинки из примеров грузятся на ура, а вот стоит запихать туда свои, при третьем append вылазит какое-нибудь "нестандартное изображение" - тут начинает гореть.
Сейчас вся эта модульность у меня сделана через одно место (зациклился на микроскопичности). Вот думал как-то структурировать код, но как это лучше сделать на JS (JS слишком гибок, чтобы гнать MVC, а MVVM - не тот случай немного... и паттернов до кучи, знать бы, что тут "мое", желательно еще, чтобы примеры были достойные).
Хотел по типу Factory что-нибудь "сфабриковать", но в итоге застрял, искал подходящее на MicroJS, но за неимением примеров ничего так и не нашел.
Одно дело - хотеть сделать лучше, другое - знать, как сделать действительно лучше:)
В принципе, да, штука удобная. Так или иначе, у себя использую сейчас loadScript и loadStyle (простые функции на нативном js).
Проблемы начинаются при добавлении логики: допустим, в index.js содержится часть страницы, в index_typeGallary.js - 2.1, а в index_typeNews.js - 2.2 (подпункты - разные варианты рендридинга).
Использую location.hash, при изменении хэша меняются страницы (и/или их части).
Проблемы возникают в уж совсем разных "механизмах" работы страниц под пунктами 2.1 и 2.2... А так includeHTML - штука хорошая, возможно, смогу найти ей применении (пока писал комментарий, раза 3 пересмотрел свое мнение). Данные берутся преимущественно из JSON, а от HTML там буквально маленькие кусочки (шаблон новости, шаблон пункта галереи).
А это что еще за зверь, не надо придумывать несуществующие решения? Serj-One, просто задал вопрос по существу: есть ли такойхак, о котором мне неизвестно.
Спасибо! Благодаря вашему упоминанию tirgger "выкопал" new Event - подумал, что там какая-то неведомая магия... Очень благодарен за "код ниже": он помог развеять все непонятки, связанные с сонными поисками адекватного решения. Желаю удачи:)
Проще - это да, но вот именно ссылка на "Цепочку вызовов" из первого ответа немного заполняет мои пробелы в постижении js, как такового (имеется еще несколько решений, которым бы не помешал . В добавок к этому (возможно, потому что наркоман и "люблю" изобретать свои "удобные велосипеды", а также верю, что querySelector медленнее старого доброго getElement*) мне неудобно использовать querySelector(All) в определенных ситуациях:)
За el.nextSibling спасибо. А el.attributes посоветуете перебирать и дальше прямым for или есть для этого другой какой-то более правильный и быстрый вариант?
Алексей Ярков, спасибо за пример. Не знал о некоторых методах (например, об el.attributes). Переписал, дополнил под себя - использовал regex.test() - так это действительно является решением вопроса... В общем, спасибо большое!