Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
поздравляю всех пользователей mootools
уж лучше бы они на производительности сосредоточились…
у мутулза что-то не так с производительностью? свамп?)
да, и сильно не так. Тот же jQuery в разы шустрее
на каких задачах?
выборка элементов, обслуживание событий, изменение DOM
кстати, недавно автор мутулза писал статью с сравнением мутулза и жиквери — мне лично очень понравилось первое сравнение — позиционирование фрэймворков самими авторами — мутулз для написания аккуратного яваскрипта, а жиквери — для обхода и манипуляции с домом. мне кажется достаточно четко
Чтобы писать аккуратный Javascript не нужен framework. Нужно просто аккуратно его писать :)
Видимо имелся ввиду jqueryvsmootools.com. Я бы это мусором не назвал. Вполне неплохой обзор.
сравните
jQuery is a fast and concise Javascript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write Javascript.
MooTools is a compact, modular, Object-Oriented Javascript framework designed for the intermediate to advanced Javascript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.
думаю пояснять откуда эти тексты взяты необходимости нет
jQuery is a fast and concise Javascript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write Javascript.
MooTools is a compact, modular, Object-Oriented Javascript framework designed for the intermediate to advanced Javascript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.
думаю пояснять откуда эти тексты взяты необходимости нет
то, как сами авторы позиционируют свои разработки. если вам эти тексты кажутся одинаковыми, мне придется применить мицголизм
меня в жиквери смущает неочевидность результатов методов $ объекта. в мутулзе и прототайпе как-то аккуратнее.
да, аккуратнее, но зато памяти жрет поболее и выполняется дольше. А так — да, все красиво и гладко.
странно, я jQuery отчасти как раз за это и люблю — за возможность работать с абстракциями, соответствующими селектору, а не с конкретными DOM-элементами.
я начал писать js когда еще не было прототайпа — мне кажется расширение дома более выгодной моделью
«более выгодной» в каком плане?
в плане возможностей для написания жаваскрипта
это как?)
мне, например, нравится jQuery именно своей расширяемостью. нет другого фреймворка, куда можно так легко встраивать свои расширения :)
мне, например, нравится jQuery именно своей расширяемостью. нет другого фреймворка, куда можно так легко встраивать свои расширения :)
ерунда. никто не мешает делать Element.extend({ myExtension: function(){} });
на выходе — аналог jq плагина $.fn.myExtension = function(){};
даже синтаксис получается похожим
moo — $('div').myExtension();
jq — $('#div').myExtension();
но в jq постоянно задалбывает, что нужно лепить # для выборки по id.
на выходе — аналог jq плагина $.fn.myExtension = function(){};
даже синтаксис получается похожим
moo — $('div').myExtension();
jq — $('#div').myExtension();
но в jq постоянно задалбывает, что нужно лепить # для выборки по id.
по мне так больше задалбывает необходимость оборачивать каждый елемент в $ для вызова жиквери фукций.
ну это тоже надуманая проблема
никто не мешает сохранить ссылку на выборку и работать с ней
var $element = $(element);
…
$element.addClass('mooo');
и это хорошая практика, потому что не тратится время на повторное заворачивание элемента в jq обёртку.
никто не мешает сохранить ссылку на выборку и работать с ней
var $element = $(element);
…
$element.addClass('mooo');
и это хорошая практика, потому что не тратится время на повторное заворачивание элемента в jq обёртку.
так в нормальных браузерах заворачивания не должно быть — в яваскрипте прототипы.
комрад, это неверное утверждение. никто ничего не должен. отстутствие лишних методов для элементов DOM — это по своему не плохо. экономит память, например. а доля «нормальных браузеров» слишком мала. нужно просто осознать, почему так сделано и жить дальше :)
споры на тему, «вот моя хрень лучше вон той хрени, потому что...» ни к чему не приведёт :) везде есть свои плюсы и минусы, идеологическая подоплёка и бла бла бла.
споры на тему, «вот моя хрень лучше вон той хрени, потому что...» ни к чему не приведёт :) везде есть свои плюсы и минусы, идеологическая подоплёка и бла бла бла.
неверное предположение
откуда такая категоричность? и при чём тут размер проекта? :) например, все проекты ТМ используют мутулз. и это круто!
поверь, но это очень удобно, когда весь функционал фреймворка доступен сразу.
поверь, но это очень удобно, когда весь функционал фреймворка доступен сразу.
а приведите пример, когда Вам бы понадобилось оборачивать элемент в $?
вас спасёт )
а вообще, мне наоборот, нравится единообразие синтаксиса CSS и $.
var $id = function(id)
{
return $('#' + id);
};
а вообще, мне наоборот, нравится единообразие синтаксиса CSS и $.
А мне так не кажется, и что? Где аргументы? Или вы авторитетом давите «я начал писать js когда еще…» :) Давайте не разводить holy war.
какую ошибку?
кстати, у jQuery есть также некая устойчивость…
например, можно выполнять операции над пустым множеством без ошибок.
например, когда нет элементов по указанному селектору.
Полезное свойство, например, для кода выше, если поле login существует только для неавторизованного пользователя.
например, можно выполнять операции над пустым множеством без ошибок.
например, когда нет элементов по указанному селектору.
Полезное свойство, например, для кода выше, если поле login существует только для неавторизованного пользователя.
«Полезное свойство, например, для кода выше, если поле login существует только для неавторизованного пользователя.» — такие вещи вообще нежелательно выполнять на клиенте если они там у этого пользователя не должны выполняться…
ну а то что они возвращают всегда пустые коллекции если ничего не найдено это на мой взгляд большой плюс… но в прототайпе метод $ возвращает не коллекцию а конкретный элемент… это альяс для getElementById() не надо его сравнивать с методом $ в jquery… они разные по назначению… сравнивайте тогда $$ прототайпа…
ну а то что они возвращают всегда пустые коллекции если ничего не найдено это на мой взгляд большой плюс… но в прототайпе метод $ возвращает не коллекцию а конкретный элемент… это альяс для getElementById() не надо его сравнивать с методом $ в jquery… они разные по назначению… сравнивайте тогда $$ прототайпа…
выше, где я писал про аккуратные скрипты имел ввиду как-раз такие возможности жиквери. это как в пыхпых отключить показ ошибок и все вызовы с @ начинать (кстати распространенная практика)
иногда такая устойчивость приводит к тому, что мозг отключается :)
вы видимо с мутулзом слабо знакомы
код $$('#login').addEvent('click',… будет вести себя практически так-же как ваша строка на жиквери. но так на мутулзе обычно не пишут.
код $$('#login').addEvent('click',… будет вести себя практически так-же как ваша строка на жиквери. но так на мутулзе обычно не пишут.
Интересное решение. Если бы я столкнулся с такой проблемой, то решил бы её через фрэйм: в скрытом фрэйме как в песочнице формируем задуманный контент страницы, затем перемещаем его в основной документ. Скрипты выполнились бы дважды, но обычно это не создст проблем. Хотя и document.write используется крайне редко. Теперь буду знать что лушче его не использовать, вдруг кто-то захочет мою страницу подгрузить к себе и огребет гемороя.
Из своей практики сознательного js, единственный раз когда использовал document.write — вставка банера. Хотя наверно есть другой способ вставить элемент в том место где стоит <script> </script>
Удивительно что все кто оставили комменты рассценили поняли топик как «В Муу добавили финтифлюшку, он стал нереально крут»
Если пользователям jq стало завидно, могу помочь адоптировать эту штуку для jq, хотя я в нем мало разбираюсь
Из своей практики сознательного js, единственный раз когда использовал document.write — вставка банера. Хотя наверно есть другой способ вставить элемент в том место где стоит <script> </script>
Удивительно что все кто оставили комменты рассценили поняли топик как «В Муу добавили финтифлюшку, он стал нереально крут»
Если пользователям jq стало завидно, могу помочь адоптировать эту штуку для jq, хотя я в нем мало разбираюсь
использование в таком случае iframe тоже несет многие неудобства, к примеру область видимости уже созданных переменных в JS, вообщем я думаю что решение с переопределением document.write в данном случае более преимущественно.
Если будет желание портировать функцию переопределения document.write под jQ советую портировать алгоритм из библиотеки Fullajax, он более универсален и решает проблемы с указанными в статье примерами.
Если будет желание портировать функцию переопределения document.write под jQ советую портировать алгоритм из библиотеки Fullajax, он более универсален и решает проблемы с указанными в статье примерами.
Эти крутые парни считают ОО подход для ЖС избыточным video.yahoo.com/watch/1041101/3881103
А вапще тайтл читается как мутулз убрали аджакс но добавили документ врайт ))
А вапще тайтл читается как мутулз убрали аджакс но добавили документ врайт ))
Поправьте меня, если я не прав, но это — как раз некорректная обработка. Корректная, это та, что определена стандартом (и по случаю реализована во всех браузерах).
Переопределять стандартные методы, которые ведут себя правильно на «что-то другое», тем более на такое, что и не работает-то почти — отличная дорога к дестабилизации системы и усложнению ее [возможной] интеграции. Вспомните известную проблему в prototype.js, связанную с переопределением в етой библиотеке глобального обьекта Element.
Переопределять стандартные методы, которые ведут себя правильно на «что-то другое», тем более на такое, что и не работает-то почти — отличная дорога к дестабилизации системы и усложнению ее [возможной] интеграции. Вспомните известную проблему в prototype.js, связанную с переопределением в етой библиотеке глобального обьекта Element.
поправляю, они добавили работоспособность данной функции там где она не работала, после того как формирования DOM законченно. если использовать после закрытия DOM document.write весь контент страницы затирается, вообщем обычный document.write и AJAX по умолчанию не совместимы.
подмена стандартной реализации метода на что-то, что ведет себя по-другому (более того, оно ведет себя не всегда) есть неправильно, ИМХО
вы поймите, вы сейчас мыслите по шаблону, включите соображаловку — после того как законченно формирование DOM функция document.write — мусор, ее невозможно использовать, она мертва, а тут появляется вторая жизнь. переопределение этой функции как раз и идет после того как DOM сформирован. что тут неправильного?
sirus, ну зачем вы спорите? :-) Ну не в курсе человек, что иногда требуется не просто отправить «вэб-дванольную» форму, но и еще произвести некоторые манипуляции с оставшейся перед физиономией посетителя страницей.
ilinsky, та проблема с Element-ами былв просто незадокументаминентированной фичей. Но, нужно отдать должное авторам prototype — они благодаря этой «фиче» предвосхитили многие возможности других JS-фреймворков в плане нормальной работы возвращаемых после AJAX-запроса построения DOM.
ilinsky, та проблема с Element-ами былв просто незадокументаминентированной фичей. Но, нужно отдать должное авторам prototype — они благодаря этой «фиче» предвосхитили многие возможности других JS-фреймворков в плане нормальной работы возвращаемых после AJAX-запроса построения DOM.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MooTools — AJAX + document.write