ну вообщем в каком то смысле это действительно колесо, которое не стоит изобретать заново, и которое по сути явялется стандартом де-факто. и конечно же ваш код это в лучшем случае 2% от возможностей prototypeJS.
Prototype.js очень распространён, поэтому самый главный бонус - это "всё, что может придумать заказчик уже реализовано до нас" - осталось это найти и начать использовать (я даже не говорю про миллион раз оттестированный код и тучу полезных функций работы с массивами, строками, DOM и т.д.)
я бы поставил под сомнение их использование. Стиль разработки меняется. Человек, знающий prototype «сядет» на jquery, или ext'e, или dojo, или mootool… Обратное верно. И все они вместе «сядут» на JS.
Это квадратное колесо является стандартом де-факто для людей, которые не понимают отличий в ООП-парадигме JS и в том, что они пытаются на неё натянуть.
Кроссбраузерность, первое, что указывают изготовители библиотек при указании их достоинств. Почему-то большинство воспринимает это, как что-то невероятное и не достижимое без использования дымящейся кучи кода сторонних библиотек.
Однако, любой сколько-нибудь квалифицированный JS-программист может писать свои сценарии кроссбраузерно, не сильно при этом напрягаясь и, в большинстве случаев, на автомате.
"Кроссбраузерность", это не то, что нужно писать в преимуществах. Это то, что должно подразумеваться по умолчанию для каждого уважающего себя продукта.
В современном мире, "кроссбраузерность" должна быть по умолчанию.
Квалифицированный программист знает большое количество граблей во многих браузерах. Что же касается других (коих большинство), то, резонный вопрос, зачем разработчику ковыряться и бороться с кучей браузеров, если это уже сделали другие. По своему опыту скажу, что большое количество времени отнимает именно борьба с особенностями браузеров, а не реализация какого нибудь функционала.
К тому же "может писать свои сценарии кроссбраузерно", конечно может. Только все в итоге сводится к написанию функций хелперов, для упрощения частых задач, которые есть в любом современном фреймворке. Смысл тратить на это время? Если вы реализуете unobtrusive, то все своими ручками имеет смысл (хотя нужно исходить из задачи). Если пишете большое приложение, вам так или иначе понадобится фреймворк. Не хотите использовать чужой, в процессе работы "родите" свой.
>>Если пишете большое приложение, вам так или иначе понадобится фреймворк. Не хотите использовать чужой, в процессе работы "родите" свой.
полностью согласен, причем скорее всего этот фреймворк будет неким обьединением вырезок из общеизвестных фреймворков + дописанный свой специфичный функционал для того или иного приложения. Причем, при написании нестандартных так скажем фишек на js (например недавно пришлось писать Rectangular Marquee Tool) фреймворки не сильно помогают, используешь их в данном конкретном примере на 2% процента от силы, то есть, если вынести тот функционал который ты используешь, код не сильно увеличивается.
Согласен. Большинство программистов пользуются универсальными фреймворками, в которых классовое ООП кустарным способом натягивается на прототипное. Я ничего не имею против этого.
Но, когда программист, который не боится "чистого" JS делает вещь, намного эффективнее работающую на его конкретной задаче, а после этого из всех щелей вылезают знатоки с криками: "Не изобретай велосипед! Лучше подключи полметра чужого кода, разберись в нем и наверни это всё поверх своей задачи", вот это меня немного нервирует.
Если не учитывать экономической составляющей, то +1
Я бы сказал "Не изобретай велосипед, если нужно сделать стандартные вещи, и сделать это нужно очень быстро"
Вы абсолюьно правы! Вот только есть, как всегда "но"...
Если ваш проект маленький и вы не предполагаете его роста и вам нужно реализовать какие-то мелочи показать/скрыть/вставить html (пример) - естественно нет смысла использовать накатаные фреймворки.
Я, как и вы противник, НО иногда, просто нет времени на реализацию фичек типа красиво скрыть/показать что-то и т.д., сроки горят или бюджет не позволяет разрабатывать свой фреймворк, или не хватает человекоресурсов - тогда фреймворки оправдывают себя на все 100%.
P.S.:Если использование фреймворка оправдано - используйте его!
думаю, дело не совсем во мне
большинство сайтов, которые используют prototype, не очень шустро работают. мозжно, проблема в других библиотеках, которые в связке с прототайпом только делают хуже
я вообще не фанат больших фреймворков. мне из прототайпа часто нужно только $, hide, show и ajax :)
сейчас себе сделал prototype.lite на 3 килобайта
Рядом с прототипом обычно еще aculous бегает.
А это уже анимации, драгидроп и тд и тп.
Сайты мазилы\mmm-tasty(особенно) и тд используют это легко и естесвенно.
А вот jquery я так и невкурил.
С прототипа начал.. и буду ему верен :P
Prototype + Script.aculo.us, конечно, хорошо, но весит много. Мне больше нравится MooTools, благодаря его модульности можно заметно выйграть на размере.
Сейчас на каникулах дома, в Перми с 64kbps, по сравнению со столичными 640kbps чуствую эту разницу. ~120Kb будет грузиться ~18 секунд. Или же 5 в моей сборке MooTools. Не дождётся посетитель и уйдёт.
1. 120kb это в несжатом виде, в сжатом будет раз в 5 меньше.
2. получается в перми попадая на 90% сайтов инета - разворачиваются и уходят? я думаю человек работающий на 64кб уже привыкает, что открыв заглавную нового сайта - можно пойти покурить или кофейку попить :)
Краткий справочник по PrototypeJS 1.6.0.2