По-моему это замечательный ответ на вопрос ООП или функции :)
Меня это шокирует до сих пор. Но это уже другой холивар :)
Неа. Если что-то сделано оно уже кому-то нужно. А если этим пользуется несколько сотен тысяч разработчиков - то тем более оно нужно. Хотя можно конечно и обойтись.
В древних версиях оперы она по дефолту представлялась MSIE.
Либо девушка, либо не девушка. Либо пользоваться надстройкой на С(С++/ассеблер. Не знаю на чем PHP написан и знать не хочу) либо рассуждать об извращенности и неэффективности надстроек. А если уж не девушка, так почему бы не воспользваться наработками ZEND или каким другими типа Cake, CI, Cohana, YII.... Ну в крайнем случае PHPClasses.
Почему у всех прочих вопрос о необходимости ООП не возникает, а у php-программистов до сих пор дискутируется?
Если здесь пробежит Т.R.O.N. он обязательно всплывет относительно надстроек над JS. Он это любит :)
Любопытно почему такой вопрос применительно к WEB однозначно ассоциируется с PHP?
У вас баг на форме сообщения об ошибках :)
соотношение числа функций/разумности - вопрос времени. ТРОН до сих пор уверен что нет такого функционала ради которого нужно использовать стандартные средства разработки, А у вас планка дошла до 4+ функций.
Такие изыскания были в моде лет 5-10 назад. Потом поисковики поняли что их дурят и Footer/header/menu стали определять не по тому где они расположены в верстке, а по наличию повторяющегося/уникального контента на странице.
Влияние может и оказывает, но на фоне ссылочного ранжирования - оно нулевое.
При прочих равных, количество багов - это производная от интенсивности тестирования. Я нисколько не сомневаюсь в вашей квалификации, или квалификации большинства остальных критиков jQuery/Prototype, но самописные фреймворки как правило тестируются на много порядков менее интенсивно чем продукты массовые - типа jQuery. Поэтому вероятность нарваться на баг с использованием массового продукта намного ниже. К тому же известный баг - это не баг. Это фича.
Ну да. А код сгенерированный .NET или запросы построенные через ORM вменяемые? Их тоже в топку? Или все-же цена разработки и сопровождения на первом месте?
Да не для меня. фреймворки - основной вектор развития. В ASP или Ruby он был с самого начала, В PHP и JS он просочился 3-4 года назад.
Я плохо представляю надобность сложного js-функционала без наличия взаимодействия пользователя с интерфейсом. Придумать симулякр конечно можно, но если использовать готовые решения он будет дешевле и в разработке и в сопровождении.
Так ведь и php-программисты медленно но верно, переходят на опенсорсовские фреймворки. А там тоже самое - встраивают prototype и jquery (Например yii)
Теv кто сидит на Phyton и Ruby проще - у них фреймворки практически с самого начала были.
Такие сайты вообще мало кто сопровождает.
Я всегда считал, что интерфейс всегда первичен. Все остальное - клиентские скрипты или серверные - вторичны. В конце концов асинхронные запросы можно выполнять без всякого Ajax.
Если бы это было так параллельно аббревиатуре RTFM была бы аббревиатура RTFСode
Даже если в договоре есть пункт о составлении докуменатции, документация написанная среднестатистическим программистом никогда не сравнится с мануалами, и учебниками, которая сопровождает наиболее ходовые фреймворки типа jquery/prototype
желание использовать фреймворки аналогичны желанию использовать языки высокого уровня, и RAD-средств, вместо написания велосипедов на ассемблере.
Кроме скорости разработки (и соответственно снижению цены), фреймворки так же дают снижение стоимости сопровождения. ловить баги и модифицировать ассемблерный код, давно уволившегося программиста, существенно сложнее чем код написанный на языке высокого уровня с хорошо документированными библиотеками.
Хотя по эффективности кода они проигрывают. Если код небольшой, программист высококвалифицированный, и пишет не с нуля, а использует свой собственный фреймворк, который в сто раз лучше и безглючнее опенсорсовского, или MS/Yahoo/Google
К счастью на Richard Cornford свет клином не сошелся. Например MS интегрировали jQuery в состав .NET. Теперь у .NET разработчиков есть альтернатива более старой и родной ajax-библиотеки Atlas. Которая три года назад была страшно кривой. А сейчас говорят почти без багов.
