Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Идея live расширений понравилось, а остальное — вода. Вместо «исправлений» в отдельной библиотеке, лучше бы пулили риквесты в jQuery.
С пул реквестами не все так просто, потому что имеется уже много написанного кода.
Есть еще проблема конфликта имен. Например, в будущем в нативном DOM появятся
Большинство проблем ниже не могут быть исправлены в jQuery без потери обратной совместимости.
Есть еще проблема конфликта имен. Например, в будущем в нативном DOM появятся
find и findAll, т.е. это уже стандартизированные имена методов. В jQuery find по смыслу эквивалентен findAll. Стоит ли добавлять findFirst и тем самым запутывать людей еще больше? Много вопросов.
О, спасибо, только вчера на SmashingMagazine прочитал, а тут и на Хабре статья подоспела.
Тут ещё строили свою DOM-библиотеку: habrahabr.ru/post/204574/
А вообще,
«каждый уважающий себя javascript-программист должен написать:
1. свою реализацию классов
2. свой шаблонизатор
3. свой jQuery
4. свой Angular» © @ creage :)
(У меня уже есть половина реализации 3-го пункта, но выкладывать на гитхаб рано. На мой взгляд, заменитель должен быть крайне компактным, модульным и не обязательно на что-либо похожим, за исключением разве что нативных методов.)
А вообще,
«каждый уважающий себя javascript-программист должен написать:
1. свою реализацию классов
2. свой шаблонизатор
3. свой jQuery
4. свой Angular» © @ creage :)
(У меня уже есть половина реализации 3-го пункта, но выкладывать на гитхаб рано. На мой взгляд, заменитель должен быть крайне компактным, модульным и не обязательно на что-либо похожим, за исключением разве что нативных методов.)
Список, конечно, хороший, но начинать лучше с изучения существующих стандартов. Пункт 1, например, хорошо сделать для понимания как работает наследование в JavaScript. Но в ES6 появится стандартизированный синтаксис для объявления классов, поэтому через какое-то время «своя реализация классов» будет никому не нужной. Поэтому лучше инвестировать свое время на что-нибудь другое.
Изобретание велосипедов хорошо там, где пока еще нет стандартных решений либо они неудобные.
Изобретание велосипедов хорошо там, где пока еще нет стандартных решений либо они неудобные.
:) У меня наоборот — всё кроме 3его пункта ... А вот про гитхаб вы не правы — выкладывать никогда не рано!
PS: Не пропустите ещё одно хорошее начинание по `jquery` теме — Kimbo
PS: Не пропустите ещё одно хорошее начинание по `jquery` теме — Kimbo
А какие отличия данной реализации LIVE от jQuery.on? Тот же результат всплывающей подсказки можно сделать
P.S. По поводу SelectorListener: расширение прототипов нативных элементов браузеров — плохая практика. С этим столкнулись разработчики PrototypeJS.
jQuery(document).on('mouseenter', '[title]', func), добавив для лучшей производительности в селектор только определённые элементы и/или классы.P.S. По поводу SelectorListener: расширение прототипов нативных элементов браузеров — плохая практика. С этим столкнулись разработчики PrototypeJS.
добавив для лучшей производительности в селектор только определённые элементы и/или классы
Вот здесь вы ошибаетесь. Live events работают по принципу фильтрации событий определенного типа на рутовом элементе. Количество происходящих событий с селектором и без него одинаковое.
Live extensions используют иной механизм навешивания событий. Если грубо, то можно воспринимать их как дешевый
DOMNodeInserted. В отличие от live events селектор здесь влияет на количество происходящих событий. Поэтому они работают в тех случаях, когда live events использовать неэффективно.По поводу SelectorListener: расширение прототипов нативных элементов браузеров — плохая практика.
better-dom не расширяет нативные прототипы (за исключением фиксов для старых IE).
может, стоит посмотреть в сторону polymer?
К минусам polymer я бы отнес то, что он работает только с кастомными элементами и слабую поддержку браузеров. Поэтому этот фреймворк сложновато использовать в реальных проектах.
Live extensions работают с любыми элементами и поддерживают IE8+ и я уже сейчас многие проекты на его основе использую по принципу подключил и забыл (не надо ничего инициализировать).
Live extensions работают с любыми элементами и поддерживают IE8+ и я уже сейчас многие проекты на его основе использую по принципу подключил и забыл (не надо ничего инициализировать).
тогда в сторону x-tags. там ie9+ за счет того, что нет shadow DOM. Работает оно по крайней мере честнее чем трюки с keyframes. Особенно с учетом того, что mutation events и MutationObserver нацелены на то, чтобы отлавливать события изменения дом-дерева. А @keyframes — нет.
Я бы советовал вам получше посмотреть что такое mutation events и MutationObserver. Ни то, ни другое не позволяет эффективно отлавливать элементы по CSS селектору. Эти специификации не предназначены для этого.
Никто не любит хаков, и live extensions не занимаются продвижением уловки с @keyframes. Задача в том, чтобы начать использовать новую идею в реальных проектах, которая позволяет решать нетривиальные в прошлом задачи, и, соответвтвенно, мыслить другими категориями.
Никто не любит хаков, и live extensions не занимаются продвижением уловки с @keyframes. Задача в том, чтобы начать использовать новую идею в реальных проектах, которая позволяет решать нетривиальные в прошлом задачи, и, соответвтвенно, мыслить другими категориями.
ну, вы настойчиво хотите мыслить категориями прежними, даже с новыми технологиями. Не думаю, что кому-то нужно регистрировать события на '.users .userPreview .dropdown:nth-child(5)', например.
Не говоря о том, что сама архитектура достаточно некомфортна для использования.
Во-первых, не стоит завязывать части системы друг на друга. Даже jQuery передает в this нативные элементы — как из-за быстродействия, так и из-за совместимости с библиотеками. Обернуть в $() не составляет проблем, а ресурсы и читаемость значительно выше.
Во-вторых, если вы будете использовать this, указывающий на сам элемент внутри конструктора — вы можете столкнуться с рядом проблем, например — в случае, если совпадет несколько элементов, конструктор будет указывать непонятно на что.
В-третьих — не глядя — вы не знаете вертикальный порядок выполнения и не способны управлять им. Что произойдет, если, например, у вас будет
MutationObserver корректно разруливает подобные ситуации, так как добавляется всегда одна или более нод в списке, одновременного добавления нод с большей и меньшей вложенностью не бывает.
В-четвертых, у вас явно проблемы с событиями, вы их делали «под себя».
Нет и не предусмотрено получения чего-то вроде event.target.className, например.
Ну и в-пятых, идея далеко не нова. X-tags, Polymer. Да и директивы AngularJS (которому уже не первый год) работают по тому же принципу.
Мне продолжать?
Не говоря о том, что сама архитектура достаточно некомфортна для использования.
Во-первых, не стоит завязывать части системы друг на друга. Даже jQuery передает в this нативные элементы — как из-за быстродействия, так и из-за совместимости с библиотеками. Обернуть в $() не составляет проблем, а ресурсы и читаемость значительно выше.
Во-вторых, если вы будете использовать this, указывающий на сам элемент внутри конструктора — вы можете столкнуться с рядом проблем, например — в случае, если совпадет несколько элементов, конструктор будет указывать непонятно на что.
В-третьих — не глядя — вы не знаете вертикальный порядок выполнения и не способны управлять им. Что произойдет, если, например, у вас будет
<div render-handlebars-template>
<div insert-video-element='http://some.url'/>
</div>
MutationObserver корректно разруливает подобные ситуации, так как добавляется всегда одна или более нод в списке, одновременного добавления нод с большей и меньшей вложенностью не бывает.
В-четвертых, у вас явно проблемы с событиями, вы их делали «под себя».
Нет и не предусмотрено получения чего-то вроде event.target.className, например.
Ну и в-пятых, идея далеко не нова. X-tags, Polymer. Да и директивы AngularJS (которому уже не первый год) работают по тому же принципу.
Мне продолжать?
Не нужно продолжать, лучше перечитайте статью. Все ваши аргументы — это заблуждения, которые свидетельствуют, что вы не усвоили материал.
Еще раз повторю — better-dom не о кастомных тэгах, и в этом состоит основное различие подхода, который продвигается x-tags, polymer и т.д. Прочтите о декораторах (не custom tags) из Web Components по ссылке из статьи, они решают схожую проблему.
Еще раз повторю — better-dom не о кастомных тэгах, и в этом состоит основное различие подхода, который продвигается x-tags, polymer и т.д. Прочтите о декораторах (не custom tags) из Web Components по ссылке из статьи, они решают схожую проблему.
Это не заблуждения, это опыт, который я реально получил от создания аналогичной библиотеки и использования ее в течении приблизительно с июля этого года внутри собственной команды и в нескольких дружественных.
Подход «один тэг — один инициализатор» верен и в таких условиях единственно правилен, так как ты никогда не знаешь, какая из команд отработает первой. Собственный недавний горький пример научил меня этому: на один селектор были навешаны подгрузка контента (естественно, с заменой innerHTML) и создание скроллбокса. В итоге скроллбокс заменялся контентом, и отладить это было практически нереально.
То же самое с порядком выполнения: если внутри шаблона объявлен видео-инициализатор, вполне возможно, что он отработает первым, и на выходе будет некорректно сформированный тэг video, который уже в дальнейшем не сможет корректно отшаблонизироваться. Подход с @keyframes может казаться удобным, но он лишает вас возможности управлять этим сценарием.
Передавать элемент в качестве this в подобных условиях неразумно: можно создать два совпадающих инициализатора, в которых будет подменяться onMouseOver, например. В итоге будет работать только одно из событий. В моем случае это разруливалось через создание constructor.call(node[directiveName] = Object.freeze(constructor), node, arguments).
Кстати, совсем забыл: у вас нет деструкторов. Это окажется большой проблемой для всех тех элементов, где используется setInterval или requestAnimationFrame. О просторе полета в элементах с window.onresize я молчу.
Еще раз — мне продолжать тыкать в ваши ошибки, которые в итоге затруднят отладку и сделают использование библиотеки сложным или невозможным в многих сложных случаях, или вы задумаетесь, наконец, о том, что не просто так именно к элементам, а не к селекторам присматриваются Mozilla и Google?
Мне весь этот подход, который наблюдается в better-dom, напоминает завывания начинающих разработчиков, которые искренне убеждены, что краткость и чистота кода куда важнее, чем статическая типизация, например, и в панике убегают при виде что Dart или TypeScript, которые на самом деле js с обвесом, что Scala.
Подход «один тэг — один инициализатор» верен и в таких условиях единственно правилен, так как ты никогда не знаешь, какая из команд отработает первой. Собственный недавний горький пример научил меня этому: на один селектор были навешаны подгрузка контента (естественно, с заменой innerHTML) и создание скроллбокса. В итоге скроллбокс заменялся контентом, и отладить это было практически нереально.
То же самое с порядком выполнения: если внутри шаблона объявлен видео-инициализатор, вполне возможно, что он отработает первым, и на выходе будет некорректно сформированный тэг video, который уже в дальнейшем не сможет корректно отшаблонизироваться. Подход с @keyframes может казаться удобным, но он лишает вас возможности управлять этим сценарием.
Передавать элемент в качестве this в подобных условиях неразумно: можно создать два совпадающих инициализатора, в которых будет подменяться onMouseOver, например. В итоге будет работать только одно из событий. В моем случае это разруливалось через создание constructor.call(node[directiveName] = Object.freeze(constructor), node, arguments).
Кстати, совсем забыл: у вас нет деструкторов. Это окажется большой проблемой для всех тех элементов, где используется setInterval или requestAnimationFrame. О просторе полета в элементах с window.onresize я молчу.
Еще раз — мне продолжать тыкать в ваши ошибки, которые в итоге затруднят отладку и сделают использование библиотеки сложным или невозможным в многих сложных случаях, или вы задумаетесь, наконец, о том, что не просто так именно к элементам, а не к селекторам присматриваются Mozilla и Google?
Мне весь этот подход, который наблюдается в better-dom, напоминает завывания начинающих разработчиков, которые искренне убеждены, что краткость и чистота кода куда важнее, чем статическая типизация, например, и в панике убегают при виде что Dart или TypeScript, которые на самом деле js с обвесом, что Scala.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О создании улучшенной JavaScript-библиотеки для работы с DOM