Re[10]: jQuery – Javascript нового поколения
От: Zeroglif  
Дата: 09.08.07 12:21
Оценка:
M>Ну я Javascript-программист. Я увидел, что у мнея появился инструмент, который позволяет мне без геморроя решать огромное количество задач.

Программирование на javascript — это геморрой? Понятно. Легче внедрять да инклюдить. Тот же копипаст, только вид сбоку. Без обид, это в философском смысле.

M>Зачем мне читать исходник? Исходник я читал два раза — когда дебагил Ajax + XML (оказалось, проблема не в jQuery, а на серваке была) и когда смотрел, как реализована jQuery.extend.


Ага, то есть если даже ты не читал исходники, тогда чего знают о jQuery не-javascript-программисты? Выходит, что знают они, как чегой-то-там-куда-то вызвать...

M>Рассказываю по порядку. Это истина жизни, странно, что ее не все понимают.


Истины жизни не бывает. На то она и жизнь.

Z>>Лично мои задачи решаются проще мною же лично, как ты говоришь, ручками. И масса людей со мной солидарны, благо jQuery и проч. пока ещё не захватили мир (не удалось это ни DHTML библиотекам, не выйдет это и у нынешних новомодных).


M>Не завоевывают именно из-за таких людей, которые готовы тратить уймы времени и писать тонны кода, когда можно в десятки раз увеличить свою производительность


Да, ты прав, из-за нас, мы тратим время, пишем код, учим других писать код, бизнесу не учим, виноваты.

Z>>Чтобы я головой отвечал за свою работу на базе чужого фреймворка, я должен знать досконально не только все эти детско-садовские туториалы про нанизывание вызовов и проч., а предназначение каждой из 2345 строк jQuery, что и зачем там делается (потому что это javascript, стеклянные замки на зыбучем песке).


M>


M>Посмотри на список сайтов, которые пользуются jQuery: http://docs.jquery.com/Sites_Using_jQuery По-моему, это — достаточный аргумент в пользу библиотеки.


Достаточный? Посмотри на миллионы сайтов, где нет jQuery, но есть (ты не поверишь) javascript. Это достаточный аргумент, чтобы не использовать этот фреймворк? Или только вам открылось...


M>Исходников там не так уж и много, их можно наискосок, не вдаваясь в детали, прочитать минут за 15, а то и меньше. Почитай, советую. Потом посмотри на тонны своего собственного кода и задайся вопросом: а почему у меня не так.


Что ж ты мне всё на мои тонны намекаешь. Если кто-то не умеет писать "не тонны", от этого страдает и вынужден искать фреймворки — это его неотъемлемое право.

M>Более того, цитирую
Автор: Sinclair
Дата: 21.07.06

M>

M>Из всего этого следуют Правила большого пальца:
M>1. Все, что можно купить, нужно покупать (cюда же входит подбор бесплатных компонентов, при их наличии)
M>2. Все, что нельзя купить, нужно аутсорсить
M>3. Нельзя аутсорсить "core" — то, за что тебе платят деньги.

M>Т.е., если ты продаешь программу для бухгалтерии:
M>1. СУБД, компилятор, визуальные компоненты, инсталлер, хелп вьювер и т.п. — приобретаются
M>2. Документация, саппорт, скины, кастомные кофигурации — аутсорсятся.
M>3. Ядро пишется твоей командой высококлассных специалистов, проверяется твоей командой профессионального QA.

M>Сейчас большинство народу, не принявшего п.1, уже вышли из бизнеса. Сейчас идет освоение п.2.


M>И это — так. Пока ты на каждый чих пишешь 10-20-30 строк "чистого JS", мы уже написали весь необходимый функционал и продаем свой продукт


M>Еще советую здесь: http://www.rsdn.ru/Forum/?mid=2027495
Автор: Sinclair
Дата: 27.07.06


Так это бизнес-форум, не знал. Тогда это из серии, эй, твой код хреновый, избыточный и не в кассу. Ну и что, зато я его за минуту подцепил и продаю, продаю, продаю...

Z>>К тому же мне нужно оттянуть время на изучение, потом на сопровождение развития всего этого дела, каждый фреймворк развивается и поддерживается по-разному, нужно следить, вычитывать, увольте. Мораль — не всем проще и удобнее с фреймворком.


M>Знаешь среднее время выучивания jQuery? 2-5 дней Проверено на 11 людях, включая меня


Верю, вы ж в исходники не лезете.

M>Учти, что твой код тоже надо учить. Особенно, если ты, напимер, уволишься или перейдешь на другой проект, а твой код кому-то придется сопровождать и/или править.


Это правда, тут я согласен. Тогда контрвопрос. Работаете вы, 11 друзей Оушена, годами интенсивно с jQuery, потом вас неблагодарные бизнесмены увольняют и вы приходите, предположим, ко мне, где рай для javascript-программистов от сохи, чистых, стерильных. Внимание, вопрос, на кой ляд мне ваш jQuery-шный опыт?

Z>>>>Почему не пишешь ниже код всей т.н. фабрики рядом? А весь остальной код, что будет участвовать в решении задачи? Посмотри в профайлере, кто работает и рядышком их, рядышком, это и есть код, который можно справедливо противопоставлять 'чистому' javascript.


M>>>Зачем? Любой фреймворк — это всегда overhead. Цель люого фреймворка — упростить разработку, спрятав "чистый" код от разработчика. Кому надо, посмотрит в код фреймворка, благо в jQuery его не так уж и много. Заметь, что если ты будешь реализовывать ту же функциональность на чистом JS — то есть настолько же гибкую, легкую и т.п., то все равно ты придешь к тому же, если не большему, количеству кода и вызовов.


Z>>Кому надо посмотрит? И чего он там увидит? Если взгляд его будет осмыслен, то какого рожна он не потратил пару-тройку дней, чтобы этот смысл вложить в свой собственный код?


M>Ну-ну. Я очнеь хочу посмотреть на того человека, который с нуля ручками за 2-3 дня напишет функционал, равный jQuery. Кстати, я из jQuery уже выдирал куски кода (типа extend, например), для использования в "чистом JS". Ничего, не умер. Во всех остальных случаях, когда надо было использовать хотя бы три-четыре функции, аналогичные jQuery, легче (и оправданнее) использовать jQuery.


Подожди, средней руки javascript-программист написал jQuery, талантливый программист, но при этом плохой javascript-программист, написал Prototype.js, ты считаешь, что в мире нет людей, способных на такие "подвиги"? Есть. Только видимо это им не надо, у каждого свои смыслы жизни.

Z>>Ну, не идеализируй пожалуйста, своего любимца, не такой уж он и гибкий, не такой уж и лёгкий и т.д.


M>Аргументы, пожалуйста. Мой аргумент вот:

M>
M>$("a.ajax").click(
M>    function(){
M>        $.get(
M>            $(this).attr("href"),
M>            {},
M>            callback
M>        )
M>    }
M>);

M>function callback(result){
M>    $("#mydiv").append(result);
M>}
M>


M>Этот код понятен даже человеку, который jQuery в глаза не видел. Для того, чтобы написать такой код, надо прочитать статью — и все.


Аргументы негибкости? Так чего тут гибкого ты же не объясняешь, приводишь "типа-гибкий" код. Мне этот код по большому счёту не понятен, вижу ряд вызовов, вижу некорректное использование в качестве идентификатора доллара (с этим уже поспоришь, развратили всех), вижу какие-то ещё идентификаторы, вижу аргументы, вижу... и чего дальше... надо идти к самодельным туториалам и смотреть, кто есть кто. Не говоря уж о гибкости.

M>Аналог на JS я уже приводил: http://jqueryjs.googlecode.com/svn/trunk/jquery/src/ajax/ajax.js, функция ajax. Попрошу обратить внимание на такие строчки, как:

M>

M>// IE likes to send both get and post data, prevent this

M>// Create the request object; Microsoft failed to properly
M>// implement the XMLHttpRequest in IE7, so we use the ActiveXObject when it is available

M>// Set the correct header, if data is being sent
M>// Set the If-Modified-Since header, if ifModified mode.


M>и так далее. Ты уверен, что твой код будет все это делать и делать правильно?


Не уверен. А ты уверен в jQuery, не читая исходников? И эта уверенность зиждется видимо на том, что сотня сайтов не докладывает об ошибках. Что ж, тоже подход.

Z>>Если я буду реализовать такую же функциональность, то я приду совершенно к другому результату, он может быть и хуже, а может и лучше, who knows. Единственное, что меня раздражает в твоём посыле — это то, что jQuery позиционируется, как сгусток идеальных простых решений, дескать, проще уже не бывает. Рискну предположить обратное.


M>Аргументируй, плиз. На данный момент по соотношению размер/качество jQuery действительно является таковым.


Проще чистого javascript нет ничего. Вспоминаем пример с алертом.

M>>>Ключевое здесь — гибкое и легкое.

M>>>При этом "ручками" мы теряем гибкость. Как только мы добавляем в код гибкость, мы получаем что? Правильно — jQuery, prototype.js, mochikit, dojo или какую иную библиотеку.

Z>>Неправильно. Если подразумевается re-use, то нормальный программист всегда будет писать в таком ключе, ничего в этом нет революционного, он сделает себе пакет, под себя, без мусора и избыточной функциональности. И то, что он сделает, просто останется вне зоны твоего/моего/мирового внимания, что никак не говорит о том, что этот код хоть чем-то проигрывает в гибкости и т.п. фреймворкам.


M>Правильно. И нанаписание и отладку такого кода у него уйдет сколько? Месяц? Два? А работать в это время кто будет?


Отлаживать 2 месяца пару-тройку функций, раскрашивающих строки у таблицы???

M>>>Нет такого понятия, как "отдельно взятая задача". Есть такое понятие, как "отдельно взятый проект". Прикажешь для каждой страницы писатьотдельно ручками с нуля? Это ж сколько кода ты понапишешь? Намного больше, чем 20 килобайт. И намного менее гибкого. И намного менее "reusable" (ключевое слово, кстати).


Z>>Дружище, я же тебя не уговариваю писать код, завязанный на страницу, смешно право. У каждого, кто пишет много на javascript-е, есть свой собственный типа-фреймворк, он может быть в виде проверенных сниппетов, в виде алгоритмов внутри головы, в виде библиотеки и т.п. Вот где гибкость, взял, что нужно и используешь, и будет этого кода точно меньше, и будешь ты его точно знать, и не будешь лишний раз учить язык фреймворков, и не будешь рабом чужих кривых идей и т.д. и т.п.


M>Так вот. jQuery — это точно такой же "типа-фреймворк". Только его предложили использовать не только внутри отдельно взятой компании, а всему миру. Это — плохо? Учитывая, что этот фреймворк — компактный и быстрый.


Ключевая фраза — "предложили использовать миру", у других могут быть свои решения не менее компактные, не менее быстрые, определённой функциональности, только они "не предлагают это миру", у всех свои смыслы. Я не говорю, что предлагать фреймворк — это плохо, меня убивает противопоставление его по лже-простоте "чистому" javascript и пропаганда фреймворков.

M>>>Покажи мне ньюба, который сможет без подсказки написать приведенный в самом начале аналог $('a.ajax'). Или ньюба, который сможет написать кроссбраузерный Ajax. А если делать его грамотно, то меньше кода, чем здесь особо и не напишешь. Ты готов весь этот код писать сам, ручками? Я — нет. Мне достаточно того, что он есть в jQuery, и я им могу пользоваться.


Z>>Что же за пренебрежение к ручкам-то? Я готов ко всему, было бы желание. Про "меньше кода не напишешь" повторюсь — сие нам не ведомо.


M>А у тебя что за пренебрежение к фреймворкам? :

M>

M>Лично мои задачи решаются проще мною же лично, как ты говоришь, ручками. И масса людей со мной солидарны, благо jQuery и проч. пока ещё не захватили мир (не удалось это ни DHTML библиотекам, не выйдет это и у нынешних новомодных)


Это не пренебрежение, это сопротивление.

M>Чем твой собственный фреймворк лучше, чем jQuery? Я тебе сразу скажу, чем он хуже:

M>- У тебя нет возможности протестировать его на всех комбинациях популярных браузераов

Есть.

M>- У тебя нет возможности проводить интенсивное выявление ошибок: http://dev.jquery.com/report/16, потому что у тебя просто нет такого количества пользователей (например, у тебя есть закрытый баг репорт типа такого: http://dev.jquery.com/ticket/1341 ). Под пользователями я имею в виду не посетителей сайта, а разработчиков, использующих твой код.


Это верное замечание. Как jQuery пытается втащить в себя отутюженные решения, так и я при сомнениях оценю и воспользуюсь тем подходом в jas-сообществе, который считается наиболее безопасным, не вижу сложности.

M>- У тебя нет возможности привлечь к разработке других разработчиков: http://groups.google.com/group/jquery-dev


Не аргумент.

M>Чувствую, что что-то еще упустил.


M>ЗЫ. Разработчики всегда будут пользоваться сторонними библиотеками. Потому что это повышает производительность. Потому что обычно нет времени на разработку аналогичного функционала. Потому что проекты надо здавать завтра, а не через полгода. Потому что велосипеды интересно писать, когда только изучаешь технологию, потом велосипеды просто не оправдывают себя.


Тема велосипедов не раскрыта. Если ты в своих проектах пользуешься jQuery, которая абсолютно всё для тебя изобрела, то что тогда остаётся для твоего javascript-программирование? Что интересного осталось?
Re[10]: jQuery – Javascript нового поколения
От: Zeroglif  
Дата: 09.08.07 12:38
Оценка:
Здравствуйте, ionicman, Вы писали:

I>Рыбята не ссортесь :D

I>to Zeroglif — я также тему начал, просто вы с разных сторон подходите. Ты подходишь как программер, т.е. тебе важен свой "гладкий" код. А господин Mamut подходит с точки зрения бизнеса. Ему не важно незначительное замедление, ему важно два самых главных в бизнесе программирвания задачи, а именно — ПРЕЕМСТВЕННОСТЬ и СКОРОСТЬ НАПИСАНИЯ.

Согласен, навeрное, про скорость написания (для привычных к jQuery), но преемственность может таковой совсем и не быть.

I>Так вот, мы тут уже с г-ном Sincalir-ом вскользь затронули другие фреймворки — они обычно неповоротливые, со своим здоровым и разбухшим синтаксисом, в который требуется долго и трудно въезжать. Вот тут я готов поспорить что лучше — использовать эту гору, либо же написать самому, ибо последнее, на мой взгляд, гораздо лучше.


Согласен. Последнее лучше.

I>Однако jQuery в данном случае не совсем фреймворк. Это по сути самые необходимые фии для аомфортной работы в JS, и на самом деле у каждого программера, долго работающего с JS прототипы этого есть. Так вот смысл в том, что он реально быстро учится, он реально дает выигрыш во времени и реально дает преемственность. А если ты поглядишь код его — то удивишься нсколь ко гладко написан :D


Да глядел я глядел. "Гладкость" подтвердить не могу, могу только предположить, что это такое (в моём предположении код такой же не гладкий, как и в большинстве либ). И скорее всего научиться обращаться к определённым функциям jQuery будет не сложно, но "вообще не учиться" будет ещё проще.

I>Но вот использовать его везде никтож не просит, однако если у тебя на 5 страничках исть вызов данной библиотеки и все равно пользвателю утянется 20 кил, то в этом случае им можно пользоваться и для остальных 5 ) даже в тривиальных случаях.


I>Щас не принято ( к счастью или к сожелению ) заботится о миллисекундах — может оно и действительно не нужно при таких скоростях.


Как это не принято, ещё как принято... и в отношении javascript, и в отношении самих фреймворков, вон они на слике друг с другом соревнуются.

I>И каждый выбирает свой вариант использования библиотек. Я например всегда стараюсь использовать только то, что надо и не забивать лишние скрипты в страницы, но чувствую, что таких осталось мало :D


Зачёт.
Re[11]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 09.08.07 13:47
Оценка: 1 (1) +1
M>>Ну я Javascript-программист. Я увидел, что у мнея появился инструмент, который позволяет мне без геморроя решать огромное количество задач.

Z>Программирование на javascript — это геморрой? Понятно. Легче внедрять да инклюдить. Тот же копипаст, только вид сбоку. Без обид, это в философском смысле.


Повторю еще раз:

// jQuery
$('a.ajax');

// аналог
var links = getElementsByTagName('a');
var selectedLinks = [];
for(i = 0; i < links.length; i++)
{
    // split потому что может быть class="ajax links other_class"
    elemClasses = links[i].className.split(/\s+/);
    if(inArray(elemClasses, "ajax") > -1)
    {
        selectedLinks.push(links[i]);
    }
}

// функция взята из jQuery
function inArray(a, и)
{
    for ( var i = 0, al = a.length; i < al; i++ )
        if ( a[i] == b )
            return i;

    return -1;
}


Так вот. Код на jQuery — это не геморрой. Код на чистом JS — это геморрой. Если я код на JS оберну в функцию/объект и засуну его в свой собственный фреймворк, то он перестанет быть "чистым JS". Он станет частью моего фреймворка.

M>>Зачем мне читать исходник? Исходник я читал два раза — когда дебагил Ajax + XML (оказалось, проблема не в jQuery, а на серваке была) и когда смотрел, как реализована jQuery.extend.


Z>Ага, то есть если даже ты не читал исходники, тогда чего знают о jQuery не-javascript-программисты? Выходит, что знают они, как чегой-то-там-куда-то вызвать...


Причем тут не-javascript-программисты? Да, jQuery иногда предлагается и не-программистам. И что из этого? Я исходники jQuery благодаря разным спорам уже вдоль и поперек изучил, благо их там мало.

M>>Рассказываю по порядку. Это истина жизни, странно, что ее не все понимают.

Z>Истины жизни не бывает. На то она и жизнь.

В области разработки ПО быстро понимаешь, что истина только одна — велосипеды себя не оправдывают и не окупают.

M>>Не завоевывают именно из-за таких людей, которые готовы тратить уймы времени и писать тонны кода, когда можно в десятки раз увеличить свою производительность


Z>Да, ты прав, из-за нас, мы тратим время, пишем код, учим других писать код, бизнесу не учим, виноваты.


При чем тут бизнес? Еще раз повторю, с нуля многое писать интересно, пока технологию только изучаешь. Если ты действительно хороший программист и можешь себе это позволить, то можно написать самому себе фреймворк типа jQuery, mochkit или любого другого (как это сделали John Resig (jQuery), Jack Slocum (Ext) и другие). В любом другом случае написание своего собственного, но аналогичного, функционала себя не оправдывает.

M>>Посмотри на список сайтов, которые пользуются jQuery: http://docs.jquery.com/Sites_Using_jQuery По-моему, это — достаточный аргумент в пользу библиотеки.


Z>Достаточный? Посмотри на миллионы сайтов, где нет jQuery, но есть (ты не поверишь) javascript. Это достаточный аргумент, чтобы не использовать этот фреймворк? Или только вам открылось...


Из этих миллионов весьма немногие ухитряются уложиться в 20КБ да еще работать под всеми браузерами.

M>>Исходников там не так уж и много, их можно наискосок, не вдаваясь в детали, прочитать минут за 15, а то и меньше. Почитай, советую. Потом посмотри на тонны своего собственного кода и задайся вопросом: а почему у меня не так.


Z>Что ж ты мне всё на мои тонны намекаешь. Если кто-то не умеет писать "не тонны", от этого страдает и вынужден искать фреймворки — это его неотъемлемое право.


Хорошо. Не тонны. Можешь оценить, сколько времени у тебя уйдет на написание своего собственного фреймворка, по возможностям не уступающего jQuery. Да, это будет твой собственный фреймворк, в котором ты бдешь уверен в каждой строчке кода. Пока ты его будешь писать, я сдам свой проект и начну новый

M>>Более того, цитирую
Автор: Sinclair
Дата: 21.07.06

M>>И это — так. Пока ты на каждый чих пишешь 10-20-30 строк "чистого JS", мы уже написали весь необходимый функционал и продаем свой продукт
M>>Еще советую здесь: http://www.rsdn.ru/Forum/?mid=2027495
Автор: Sinclair
Дата: 27.07.06


Z>Так это бизнес-форум, не знал. Тогда это из серии, эй, твой код хреновый, избыточный и не в кассу. Ну и что, зато я его за минуту подцепил и продаю, продаю, продаю...


Разработка ПО — это всегда бизнес, если только проект не пишется для себя и явно будет некоммерческим. Еще раз повторю:

— Предположим, ты работаешь в какой-нибудь компании. Зарплата у тебя — 1000 долларов в месяц.
— Ты решил не брать jQuery, а написать свой, похожий по функционалу, фреймворк
— Во главу угла ты ставишь скорость, кроссбраузерность, легкость в использовании

Такой проект пишется не день и не два. Особенно, если надо тестировать в разных браузерах и выискивать интересные мелкие баги.

Месяц спустя тебя начальство спрашивает: "Этааа, чем ты последний месяц занимался". Что ты ответишь? Что проел 1000 долларов, реализуя что-то, что можно получить бесплатно и уже месяц тому назад?

Z>>>К тому же мне нужно оттянуть время на изучение, потом на сопровождение развития всего этого дела, каждый фреймворк развивается и поддерживается по-разному, нужно следить, вычитывать, увольте. Мораль — не всем проще и удобнее с фреймворком.

M>>Знаешь среднее время выучивания jQuery? 2-5 дней Проверено на 11 людях, включая меня
Z>Верю, вы ж в исходники не лезете.

При чем тут исходники? Ты не поверишь, но в любом фреймворке надо знать не исходники, а публично доступные функции. Это относится к любому фреймворку или библиотеке. В исходники лезут, когда библиотека работает некорректно. Для того, чтобы работать с jQuery достаточно документации по ее функциям.

В исходники можно залезть, чтобы посмотреть, не творит ли библиотека что-нибудь непотребное. На это в случае с jQuery уйдет максимум час.

M>>Учти, что твой код тоже надо учить. Особенно, если ты, напимер, уволишься или перейдешь на другой проект, а твой код кому-то придется сопровождать и/или править.


Z>Это правда, тут я согласен. Тогда контрвопрос. Работаете вы, 11 друзей Оушена, годами интенсивно с jQuery, потом вас неблагодарные бизнесмены увольняют и вы приходите, предположим, ко мне, где рай для javascript-программистов от сохи, чистых, стерильных. Внимание, вопрос, на кой ляд мне ваш jQuery-шный опыт?


В случае с jQuery все просто. Берется в руки документация и уже под конец рабочего дня новый программист, даже не глядя в туториалы, начинает активно работать как со старым кодом, так и начинает писать новый. У тебя к твоему фреймворку есть централизованная документация?

M>>Ну-ну. Я очнеь хочу посмотреть на того человека, который с нуля ручками за 2-3 дня напишет функционал, равный jQuery. Кстати, я из jQuery уже выдирал куски кода (типа extend, например), для использования в "чистом JS". Ничего, не умер. Во всех остальных случаях, когда надо было использовать хотя бы три-четыре функции, аналогичные jQuery, легче (и оправданнее) использовать jQuery.


Z>Подожди, средней руки javascript-программист написал jQuery, талантливый программист, но при этом плохой javascript-программист, написал Prototype.js, ты считаешь, что в мире нет людей, способных на такие "подвиги"? Есть. Только видимо это им не надо, у каждого свои смыслы жизни.


Я верю, что есть люди, способные написать второй jQuery/Prototype и.т.п. Но, как ты верно подметил, "видимо это им не надо, у каждого свои смыслы жизни". Поэтому они берут тот же jQuery и на его сонове творят... Ну, например Ext

Z>>>Ну, не идеализируй пожалуйста, своего любимца, не такой уж он и гибкий, не такой уж и лёгкий и т.д.


M>>Аргументы, пожалуйста. Мой аргумент вот:

M>>
M>>$("a.ajax").click(
M>>    function(){
M>>        $.get(
M>>            $(this).attr("href"),
M>>            {},
M>>            callback
M>>        )
M>>    }
M>>);

M>>function callback(result){
M>>    $("#mydiv").append(result);
M>>}
M>>


M>>Этот код понятен даже человеку, который jQuery в глаза не видел. Для того, чтобы написать такой код, надо прочитать статью — и все.


Z>Аргументы негибкости? Так чего тут гибкого ты же не объясняешь, приводишь "типа-гибкий" код. Мне этот код по большому счёту не понятен, вижу ряд вызовов, вижу некорректное использование в качестве идентификатора доллара (с этим уже поспоришь, развратили всех), вижу какие-то ещё идентификаторы, вижу аргументы, вижу... и чего дальше... надо идти к самодельным туториалам и смотреть, кто есть кто. Не говоря уж о гибкости.


Читается так: Элементом A с классом ajax присвоить обработчик события "click" такой: вызвать ajax метод get к url'у, который берется из аттрибута href; по зваершению вызова вызвать функцию callback. В функции callback найти элемент с id="mydiv" и дописать ему в конец полученный с сервера ответ.

Для понятия этого кода максимум, что нужно, это документация по методам jQuery.

M>>Аналог на JS я уже приводил: http://jqueryjs.googlecode.com/svn/trunk/jquery/src/ajax/ajax.js, функция ajax. Попрошу обратить внимание на такие строчки, как:

M>>

M>>// IE likes to send both get and post data, prevent this

M>>// Create the request object; Microsoft failed to properly
M>>// implement the XMLHttpRequest in IE7, so we use the ActiveXObject when it is available

M>>// Set the correct header, if data is being sent
M>>// Set the If-Modified-Since header, if ifModified mode.


M>>и так далее. Ты уверен, что твой код будет все это делать и делать правильно?


Z>Не уверен. А ты уверен в jQuery, не читая исходников? И эта уверенность зиждется видимо на том, что сотня сайтов не докладывает об ошибках. Что ж, тоже подход.


Да, я уверен в jQuery хотя бы поэтому: http://dev.jquery.com/report/16
Я вижу активное исправление ошибок, связанных, в частности, с кроссбраузерностью.

M>>Аргументируй, плиз. На данный момент по соотношению размер/качество jQuery действительно является таковым.

Z>Проще чистого javascript нет ничего. Вспоминаем пример с алертом.

Не надо приводить синтетические примеры. Я привел пример с $("a.ajax") и его реализацию на чистом JS. Как только сложность кода вылазит за простой alert(), код на чистом JS начинает расти в геометрической прогрессии. Его приходится оборачивать в функции, объекты и т.п., получая такой же фреймворк, вид сбоку.

M>>>>Ключевое здесь — гибкое и легкое.

M>>>>При этом "ручками" мы теряем гибкость. Как только мы добавляем в код гибкость, мы получаем что? Правильно — jQuery, prototype.js, mochikit, dojo или какую иную библиотеку.

Z>>>Неправильно. Если подразумевается re-use, то нормальный программист всегда будет писать в таком ключе, ничего в этом нет революционного, он сделает себе пакет, под себя, без мусора и избыточной функциональности. И то, что он сделает, просто останется вне зоны твоего/моего/мирового внимания, что никак не говорит о том, что этот код хоть чем-то проигрывает в гибкости и т.п. фреймворкам.


Что будем делать, когда понадобится дополнительная функциональность? В jQuery я получаю всего 20KB кода и функциональность, которая покрывает до 90% моих нужд. Чем он плох?

M>>Правильно. И нанаписание и отладку такого кода у него уйдет сколько? Месяц? Два? А работать в это время кто будет?

Z>Отлаживать 2 месяца пару-тройку функций, раскрашивающих строки у таблицы???

Это он на одной странице таблицу раскрашивает. На другой — он оперирует многострочной формой на сложных правилах. Так как он и так закеширован браузером, не вижу смысла использовать самописный код на 2-3 из сотни страниц.

M>>Так вот. jQuery — это точно такой же "типа-фреймворк". Только его предложили использовать не только внутри отдельно взятой компании, а всему миру. Это — плохо? Учитывая, что этот фреймворк — компактный и быстрый.


Z>Ключевая фраза — "предложили использовать миру", у других могут быть свои решения не менее компактные, не менее быстрые, определённой функциональности, только они "не предлагают это миру", у всех свои смыслы. Я не говорю, что предлагать фреймворк — это плохо, меня убивает противопоставление его по лже-простоте "чистому" javascript и пропаганда фреймворков.


Тьху. Если у каждого программиста и так есть свой "типа-фреймворк", то где же тут пропаганда?

А фреймворк jQuery действительно позволяет находить решения быстрее, чем аналогичные на чистом JS. Кстати, как только ты написал свой "типа фреймворк", то у тебя уже тоже не "чистый JS". В этом отношении jQuery ничем не грязнее твоего фреймворка — он тоже на JS написан.

M>>А у тебя что за пренебрежение к фреймворкам? :

M>>

M>>Лично мои задачи решаются проще мною же лично, как ты говоришь, ручками. И масса людей со мной солидарны, благо jQuery и проч. пока ещё не захватили мир (не удалось это ни DHTML библиотекам, не выйдет это и у нынешних новомодных)


Z>Это не пренебрежение, это сопротивление.


Чему сопротивляться, если у тебя такой же фреймворк написан, пусть и ручками?

M>>Чем твой собственный фреймворк лучше, чем jQuery? Я тебе сразу скажу, чем он хуже:

M>>- У тебя нет возможности протестировать его на всех комбинациях популярных браузераов

Z>Есть.


У тебя есть время протестировать его, скажем, на Konqueror 3.5? Тебе на это отдельно выделяют время и деньги? Если да, то тогда нельзя не порадоваться за тебя. У нас такой возможности нет. И у 90% прораммистов в целом тоже нет. Поэтому свои собственный фреймворки изобретать мы не просто не можем — мы не имеем права. Потому что есть такая вещь, как time to market.

M>>- У тебя нет возможности проводить интенсивное выявление ошибок: http://dev.jquery.com/report/16, потому что у тебя просто нет такого количества пользователей (например, у тебя есть закрытый баг репорт типа такого: http://dev.jquery.com/ticket/1341 ). Под пользователями я имею в виду не посетителей сайта, а разработчиков, использующих твой код.


Z>Это верное замечание. Как jQuery пытается втащить в себя отутюженные решения, так и я при сомнениях оценю и воспользуюсь тем подходом в js-сообществе, который считается наиболее безопасным, не вижу сложности.


На это нужно время. У нас же основное направление разработки — не разработка собственного js-фреймворка и его отладка.

M>>- У тебя нет возможности привлечь к разработке других разработчиков: http://groups.google.com/group/jquery-dev

Z>Не аргумент.

Вполне аргумент. В рассылке пробегали предложения, как увеличить скокрость селекторов на 3-5 миллисекунд от различных разработчиков. Эти изменения потом внедряются в jQuery

M>>ЗЫ. Разработчики всегда будут пользоваться сторонними библиотеками. Потому что это повышает производительность. Потому что обычно нет времени на разработку аналогичного функционала. Потому что проекты надо здавать завтра, а не через полгода. Потому что велосипеды интересно писать, когда только изучаешь технологию, потом велосипеды просто не оправдывают себя.


Z>Тема велосипедов не раскрыта. Если ты в своих проектах пользуешься jQuery, которая абсолютно всё для тебя изобрела, то что тогда остаётся для твоего javascript-программирование? Что интересного осталось?


Мое поле деятельности — не создание javascript фреймворков. Я пишу конкретный проект для конкретных целей. Нам jQuery позволил решить интереснейшие проблемы по созданию ajax-based shopping cart, и сложнейшую форму создания изменений цен.

Если бы я был именно javascript-разработчиком, я бы начал писать для себя легковесный аналог Ext.

jQuery — очень низкоуровневый фреймворк. Он позволяет мне обратить внимание на более приятные вещи, чем кросс-браузерный аякс, кросс-браузерная анимация или кросс-браузерная манипуляция DOM-ом. Последние три вещи мне предоставляет jQuery и мне нет смысла писать их заново с нуля.


dmitriid.comGitHubLinkedIn
Re[6]: jQuery – Javascript нового поколения
От: ddocker Россия www.codelab.ru
Дата: 10.08.07 07:14
Оценка: +3
Z>А мы разве говорили о вычислительной сложности? Мой посыл был продемонстрировать, что за обыкновенным тупым алертом стоит работа многих-многих-многих функций, которые при этом 139!!! раз вызываются....
Z>Ой, мама, дорогая, мне нужно было только показать 1 алерт с текстом "Превед вам, медведы, от jQuery?", ты мне советуешь для этого использовать jQuery? А что, подумаешь, куча работы в фоне, зато милисекунды никто не заметит. Извращённое несоответствие кода задаче. По всем статьям: загрузка, излишняя работа интерпретатора, создание сотни объектов, 139 вызовов и проч. Этот пример — квинтэссенция бездумного javascript. C такими примерами нужно бороться, а не пропагандировать похожее примитивное использование библиотек. Так, как пока безуспешно стараются побороть с "bad practice" (eval, with и т.п.) в javascript, пользователь хреновый код без ошибок тоже не заметит, но это ж не отменяет тот факт, что код хреновый. Неужели это неочевидно?

Так в чем проблема, думаю, вам тут совсем не пытаются навязать полностью заменить javascript на jquery и в этих вырожденных случаях показа alert-а например, когда в js-е мы делам одну операцию а через jq делается более сотни... — использовать jq, даже самые заядлые jq-щики напишут тут просто alert() без всяких фреймворков и все!
Действительно зачем, если на js это одна строчка кода, а на jq — хотя и тоже 1 (как обычно впрочем ), но под собой она дергает более сотни вызовов?
По-моему, до вас тут пытаются донести совсем другие случаи, типа хитрых выборок и итераций по сложному dom-у и т.д., когда на чистом js, у вас было бы ненамного меньшее количество вызовов чем в jq — только в jq это были бы интуитивные пара логических строк (+кроссбраузерный, оптимизированный код), а у вас бы вероятней всего была бы некая портянка на пару экранов, в которой затем ваши же коллеги пол-дня будут разбираться, при том, что если понадобится другая подобная хитрая выборка — будете писать еще одну подобную простыню...
А потом еще копипайстить из одного проекта в другой — если снова заходите использовать...

Странные посты против фрейворков вообще, вы вот и на сервер-сайд наверное никаких фреймворков не используете, сами GET/POST валидируете и популируете, постинг каждой формы по новой все этапы реализуете, различные утилитные функции, велосипеды изобретаете на каждом шагу наверное...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: jQuery – Javascript нового поколения
От: AKS.  
Дата: 10.08.07 08:30
Оценка: :))
Здравствуйте, Mamut, Вы писали:

M>Тьху. Если у каждого программиста и так есть свой "типа-фреймворк", то где же тут пропаганда?


Название Вашей статьи "jQuery – Javascript нового поколения" — это и есть "пропаганда". Причем с "отягчающими последствиями".

Поясню на своем примере. Я, интересуясь Javascript, сразу же обратил внимание на броское название в надежде прочесть действительно о чем-то новом. Не буду скрывать — я расчитывал найти в фреймворке нечто, похожее на эмуляцию нововведений для Javascript 1.6, только на этот раз думал, что Джон изобрел что-нибудь и для Javascript 1.8. Естественно я был разочарован — никакого "Javascript нового поколения" мне найти не удалось.

Так зачем вообще использовать такие громкие названия для статей? Это ни что иное, как пиар и пропаганда. И ничего более на ум не приходит, поскольку все, о чем здесь пишут, ни коим образом не относится к Javascript.

Как доказательство того, что JavaScript здесь лишь "мимо пробежал" — это пример обработки onmouseover/onmouseout/click на строках таблицы. В вашем случае на каждый ряд таблицы навешивается обработчики трех событий. Позвольте, но это совершенно бездумный подход. Достаточно обработать те же события на самой таблице. На пропиаренном фреймворке это делается так:

$(document).ready(
    function () {
        $('#blocks').mouseover(paintRow)
                    .mouseout(paintRow)
                    .click(paintRow);
    }
);

Здесь paintRow — это небольшая функция, которая и будет в зависимости от типа события раскрашивать столбики...

Напоследок хочу пожелать следующее. Пишите про свой любимый фреймворк и про то, как ловко Вы им пользуетесь. Но не пытайтесь, пожалуйста, спекулировать на модном нынче JavaScript — для того, чтобы о нем писать, придется познать его во всех ипостасях...
Re[13]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 10.08.07 10:18
Оценка:
M>>Тьху. Если у каждого программиста и так есть свой "типа-фреймворк", то где же тут пропаганда?

AKS>Название Вашей статьи "jQuery – Javascript нового поколения" — это и есть "пропаганда". Причем с "отягчающими последствиями".




AKS>Поясню на своем примере. Я, интересуясь Javascript, сразу же обратил внимание на броское название в надежде прочесть действительно о чем-то новом. Не буду скрывать — я расчитывал найти в фреймворке нечто, похожее на эмуляцию нововведений для Javascript 1.6, только на этот раз думал, что Джон изобрел что-нибудь и для Javascript 1.8. Естественно я был разочарован — никакого "Javascript нового поколения" мне найти не удалось.


"Яваскрипт нового поколения" — всего лишь перевод слогана jQuery "a new wave javascript". Если быть до конца честным, то jQuery — первая Javascript-библиотека, предлагающая, например, селекторы для выборки элементов. Аналогичные решения в других библиотеках, емнип, появились позже.

AKS>Так зачем вообще использовать такие громкие названия для статей? Это ни что иное, как пиар и пропаганда. И ничего более на ум не приходит, поскольку все, о чем здесь пишут, ни коим образом не относится к Javascript.


А, ну да, код на Яваскрипте, библиотека на Яваскрипте, но это никоим образом не Яваскрипт

AKS>Как доказательство того, что JavaScript здесь лишь "мимо пробежал" — это пример обработки onmouseover/onmouseout/click на строках таблицы. В вашем случае на каждый ряд таблицы навешивается обработчики трех событий. Позвольте, но это совершенно бездумный подход. Достаточно обработать те же события на самой таблице. На пропиаренном фреймворке это делается так:


AKS>
AKS>$(document).ready(
AKS>    function () {
AKS>        $('#blocks').mouseover(paintRow)
AKS>                    .mouseout(paintRow)
AKS>                    .click(paintRow);
AKS>    }
AKS>);
AKS>

AKS>Здесь paintRow — это небольшая функция, которая и будет в зависимости от типа события раскрашивать столбики...

Спасибо, учту.

AKS>Напоследок хочу пожелать следующее. Пишите про свой любимый фреймворк и про то, как ловко Вы им пользуетесь. Но не пытайтесь, пожалуйста, спекулировать на модном нынче JavaScript — для того, чтобы о нем писать, придется познать его во всех ипостасях...


По-моему, статья описывает именно фреймворк. Или не так? Возможно, следовало бы назвать статью типа "jQuery — новый фреймворк для JavaScript", но кого таким названием заинтересуешь? Этих фреймворков — как грязи. И от слова Javascript никуда не уйдешь — как ни крути, а jQuery — это все же фреймворк, написаный на Яваскрипте

Я все равно так и не понял, в чем выражается протест против статьи, фреймворков вообще и фреймворка jQuery в частности


dmitriid.comGitHubLinkedIn
Re[7]: jQuery – Javascript нового поколения
От: Zeroglif  
Дата: 10.08.07 10:28
Оценка: -2
Здравствуйте, ddocker, Вы писали:

Z>>А мы разве говорили о вычислительной сложности? Мой посыл был продемонстрировать, что за обыкновенным тупым алертом стоит работа многих-многих-многих функций, которые при этом 139!!! раз вызываются....

Z>>Ой, мама, дорогая, мне нужно было только показать 1 алерт с текстом "Превед вам, медведы, от jQuery?", ты мне советуешь для этого использовать jQuery? А что, подумаешь, куча работы в фоне, зато милисекунды никто не заметит. Извращённое несоответствие кода задаче. По всем статьям: загрузка, излишняя работа интерпретатора, создание сотни объектов, 139 вызовов и проч. Этот пример — квинтэссенция бездумного javascript. C такими примерами нужно бороться, а не пропагандировать похожее примитивное использование библиотек. Так, как пока безуспешно стараются побороть с "bad practice" (eval, with и т.п.) в javascript, пользователь хреновый код без ошибок тоже не заметит, но это ж не отменяет тот факт, что код хреновый. Неужели это неочевидно?

D>Так в чем проблема, думаю, вам тут совсем не пытаются навязать полностью заменить javascript на jquery и в этих вырожденных случаях показа alert-а например, когда в js-е мы делам одну операцию а через jq делается более сотни... — использовать jq, даже самые заядлые jq-щики напишут тут просто alert() без всяких фреймворков и все!


Пример с алертом был утрирован СПЕЦИАЛЬНО! Чтобы продемонстрировать избыточность кода задаче. Очень похожие утрированные примеры (подвесить клик на якорь или добавить класс и т.п.) используются в большинстве туториалов. Общий посыл при этом — смотрите и учитесь, как просто и легко можно это сделать по сравнению с чистым javascript. Хотя на самом деле (вообще не понимаю, как можно об этом ещё и спорить) отдельная задача и даже несколько связанных задач решаются руками проще/оптимальнее/качественнее, чем с использованием большого избыточного (априори всегда избыточного) пакета. Тем более чужого. Тем более javascript-пакета. Тем более в исходники которого, как оказалось, никто и не смотрит.

Но если количество и объём многомерных задач таковы, что мы уже подходим к раскрытию возможностей jQuery по-максимому, то фреймворк можно (заметьте, я не выступаю против, я говорю, что можно) использовать, на то он и большой пакет. Но в этом смысле сразу возникает парадоксальная ситуация — программист делает большой суръёзный javascript-проект, что предполагает всё-таки владение предметом, и при этом он не в состоянии предложить свои собственные решения, которые бьют строго в заданную оптимальную точку. Почему так происходит? Само собой, ни один из нас не признается в своей слабой подготовке или в нехватке времени, или в нехватке браузеров, или в недостатке кросс-браузерного опыта, или в ещё в чём, не знаю , подозреваю, что именно отсюда и торчат уши заступничества за фреймворк, где оный и самый идеальный, и самый оптимальный и ваапще жесть, какой полезный, а все остальные — дураки полные, ничего не понимают, им бы только портянки писать и тонну кода вываливать, нам этого не надо, мы велосипеды уже наизобретались. Хех, прям чуть было не поверил.

Заступайтесь на здоровье, друзья, но только в узком профессиональном мире фреймворков, сражаясь там в войне с Prototype.js или ещё с кем, но не учите мир жить. Не гоните волну на javascript, не отталкивайте он него людей, не учите псевдо-коду, не учите плохому псевдо-коду, вместо книг "Learning jQuery" пишите книги "Learning Javascript"...

D>По-моему, до вас тут пытаются донести совсем другие случаи, типа хитрых выборок и итераций по сложному dom-у и т.д., когда на чистом js, у вас было бы ненамного меньшее количество вызовов чем в jq — только в jq это были бы интуитивные пара логических строк (+кроссбраузерный, оптимизированный код), а у вас бы вероятней всего была бы некая портянка на пару экранов, в которой затем ваши же коллеги пол-дня будут разбираться, при том, что если понадобится другая подобная хитрая выборка — будете писать еще одну подобную простыню...


Не знаю, что до меня пытаются тут донести, но про портянки я уже понял, это типичный такой наезд в стиле "лучше уже не бывает, не выёживайся", а иначе — докажи. Во-первых, не судите по себе , а во-вторых, отказывать в профессионализме тем, кто не использует js-фреймворки в своей программистской работе (или большую часть работы делает руками), по меньшей мере неуважительно по отношению к вашим же коллегам. Люди пишут прекрасный код. Люди пишут ужасный код. Так было, есть и будет.

D>А потом еще копипайстить из одного проекта в другой — если снова заходите использовать...


Эти доводы я принимаю и не принимаю одновременно, согласитесь, что всё зависит от ситуации. Компании "A", построившей все свои проекты на базе JSLibrary №13 ваши jsQuery-наработки даром не нужны. Но, замечу, всегда будет нужен ваш опыт в отрыве от любой либы...

D>Странные посты против фрейворков вообще, вы вот и на сервер-сайд наверное никаких фреймворков не используете, сами GET/POST валидируете и популируете, постинг каждой формы по новой все этапы реализуете, различные утилитные функции, велосипеды изобретаете на каждом шагу наверное...


Это посты не против либ как таковых вообще, пользуйтесь, если нравится, а посты против того, что кто-то имеет смелость сравнивать javascript vs. jQuery или javascript-программирование vs. псевдо-программирование.
Re[14]: jQuery – Javascript нового поколения
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.08.07 10:56
Оценка: 2 (1) +3 :))) :)
Здравствуйте, Mamut, Вы писали:

M>Я все равно так и не понял, в чем выражается протест против статьи, фреймворков вообще и фреймворка jQuery в частности

Похоже, это все — когнитивный диссонанс. Ну как там хардкорные плюсовые программеры плевались (и до сих пор плюют) на джаву, потому как она противоречит всему их мировоззрению.
Я, честно говоря, от веб девелоперов этого не ожидал.
Ан нет — бывают всё же люди, которые привыкли к тому, что javascript — это ужос. Когда заради простейшей вещи трижды вспотеешь и восемь раз выматеришься. А потом тебе еще и пришлют что-то типа "а вот в FF 1.5.0.3 не работает". А потом наконец оно заработало — и вот оно щастье-то!

А тут какие-то негодяи делают из этого чудовищного приплясывания с жертвоприношениями вполне благопристойную среду! Конечно обидно понимать, что последние восемь мегабайт кода можно было вообще не писать. Конечно хочется доказать, что без тех восьми мегабайт ничего не получится. Что алерт можно вызвать и без jQuery (по секрету скажу: если у вас в приложении есть вызов alert — значит оно плохо спроектировано!). Что найти элемент можно и по ID. А если их несколько — то можно их найти через регексп. И вообще каждый уважающий себя джедай пишет себе фреймворк сам, и никогда не воспользуеся чужим фреймворком, потому что это то же самое, что и зубная щетка. Ну и вообще.

Ничего, из самых ярых противников обычно получаются самые активные сторонники
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: jQuery – Javascript нового поколения
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.08.07 10:56
Оценка:
Здравствуйте, Zeroglif, Вы писали:

Z>Но если количество и объём многомерных задач таковы, что мы уже подходим к раскрытию возможностей jQuery по-максимому, то фреймворк можно (заметьте, я не выступаю против, я говорю, что можно) использовать, на то он и большой пакет. Но в этом смысле сразу возникает парадоксальная ситуация — программист делает большой суръёзный javascript-проект, что предполагает всё-таки владение предметом, и при этом он не в состоянии предложить свои собственные решения, которые бьют строго в заданную оптимальную точку.

Потрясающее нежелание понимать аргументы противной стороны. Кто сказал, что не в состоянии? Просто стоимость своего "собственного" решения слишком высока. По сравнению с применением чужих.

Z>Почему так происходит? Само собой, ни один из нас не признается в своей слабой подготовке или в нехватке времени, или в нехватке браузеров, или в недостатке кросс-браузерного опыта, или в ещё в чём, не знаю

Из вас — это из кого? Я вот лично легко признаюсь: у нас не хватает ни времени, ни браузеров, ни подготовки. Причем всегда не хватает, и не будет хватать.

Z>Заступайтесь на здоровье, друзья, но только в узком профессиональном мире фреймворков, сражаясь там в войне с Prototype.js или ещё с кем, но не учите мир жить. Не гоните волну на javascript, не отталкивайте он него людей, не учите псевдо-коду, не учите плохому псевдо-коду, вместо книг "Learning jQuery" пишите книги "Learning Javascript"...

Почему плохому-то? Ты до сих пор не смог сформулировать свои претензии к jQuery. "Количество вызовов" — извини, это бред.

Z>Не знаю, что до меня пытаются тут донести, но про портянки я уже понял, это типичный такой наезд в стиле "лучше уже не бывает, не выёживайся", а иначе — докажи. Во-первых, не судите по себе , а во-вторых, отказывать в профессионализме тем, кто не использует js-фреймворки в своей программистской работе (или большую часть работы делает руками), по меньшей мере неуважительно по отношению к вашим же коллегам. Люди пишут прекрасный код. Люди пишут ужасный код. Так было, есть и будет.

Ну вот людей и пытаются научить писать прекрасный код. В чем проблема-то? А по поводу того, что в профессионализм входит умение воспользоваться чужими наработками, так я под этим подпишусь.

Z>Это посты не против либ как таковых вообще, пользуйтесь, если нравится, а посты против того, что кто-то имеет смелость сравнивать javascript vs. jQuery

А в чем проблема?
Z>или javascript-программирование vs. псевдо-программирование.
А чем отличается псевдо-программирование от настоящего? Тем, что волосы и зубы не выпадают, что ли? Типа если не вспотел — значит не поработал?
Вообще, если лично тебе не нравится jQuery — никто ее тебе не навязывает. Пиши себе. Или у тебя страшная ревность к тому, что раньше ты брал за advanced javascript effects мегабабло, а теперь это доступно любому пионеру через два дня обучения jQuery? Может ты боишься, что веб программисты встрянут и разучатся биндить обработчики вручную, без jQuery? Ну, до этого ой как далеко...
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: jQuery – Javascript нового поколения
От: Zeroglif  
Дата: 10.08.07 11:01
Оценка:
M>А фреймворк jQuery действительно позволяет находить решения быстрее, чем аналогичные на чистом JS. Кстати, как только ты написал свой "типа фреймворк", то у тебя уже тоже не "чистый JS". В этом отношении jQuery ничем не грязнее твоего фреймворка — он тоже на JS написан.

Интересный довод. Честно говоря, не я предложил термин "чистый javascript". Согласись, что если на грязный и чистый не делить, то тогда нужно показывать в своих статьях и "мясо", которое стоит за вроде-как-бы-простым-с-виду-вызовом. Чистый должен встать против чистого. А иначе я могу сказать, что вот мой новый javascript — f(), вот там всё и делается.

Вот кстати, если ты облазил исходники вдоль и поперёк, то возьми любой отдельный кусок, допустим, манипуляцию классами, что ты там увидишь — неоптимальный код (inArray, each и т.п.), или возьмём твою любимую isFunction, её что можно использовать на низком уровне (в отрыве от фреймворка)? Она что переварит всё, что угодно корректно? Конечно, нет. Это просто сейчас попалось на глаза. Не сомневаюсь, что там куча таких тонких мест, по своей природе супер-динамический язык, помноженный на весёлые интерпретаторы не оставляет нам никаких надежд поиметь устойчивую (не fragile) либу. Чужую. Лучше делать своё. А там и опыт нарисуется. Боевой.
Re[14]: jQuery – Javascript нового поколения
От: AKS.  
Дата: 10.08.07 11:18
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Я все равно так и не понял, в чем выражается протест против статьи, фреймворков вообще и фреймворка jQuery в частности


Да нет протеста — есть конкретное пожелание (я его высказал).
Для того чтобы меня было легче понять, напишу кое-что еще. Но перед этим — небольшая ремарка.
Мы с Вами прекрасно понимаем, что каждый из нас ведет свою игру — у Вас одна (в подробности из уважения не лезу), у меня — игра другая.
А теперь давайте рассмотрим гипотетическую ситуацию. Прихожу я, как соискатель вакантной должности javascript-программиста (той самой, о которой Вы писали чуть раньше, с интересной такой зарплатой в 1000$), ну, например, лично к Вам. Говорю:
— Готов взвалить на себя всю работу с клиентской частью проекта, т.к. JavaScript для меня — это открытая книга.
Тут Вы вспоминаете, что читали на днях интересную статью под названием "jQuery – Javascript нового поколения". Немного подумав и взвесив все "за" и "против" (прокалькулировав заодно фонд зарплаты в "новом свете", исходящем от jQuery), Вы мне отвечаете:
— Да вообще-то нам javascript-программист теперь скорее всего не понадобится — теперь нам его заменит jQuery.
На это я пытаюсь возразить:
— Но позвольте, неужели Вы собираетесь положиться на какую-то "дармовщинку" из инета?
— А почему бы и нет, — отвечаете Вы, — вот посмотрите статейку, люди рекомендуют!
Я, не оставляя попыток "зацепиться за штуку зеленых", продолжаю:
— Так Вы в самом деле думаете, что и авторам статей можно доверять?
— А почему бы и нет? Вот посмотрите, как удачно автор раскрашивает табличные строки, табличка реагирует на движения мыши, да и запросы к серверу он благодаря чудо-библиотеке обрабатывает легко и непринужденно. И все у него — буквально несколько строк.
И как Вы думаете, что мне останется напоследок? Да ничего более, как "перемыть кости" автору этой злополучной для меня статьи, не забыв отметить, что его знаний JavaScript пока не достаточно, чтобы давать советы направо и налево...

Надеюсь, Вы поймете меня верно — ничего личного, просто такое вот стечение обстоятельств...

Еще немного вот об этом:
M>А, ну да, код на Яваскрипте, библиотека на Яваскрипте, но это никоим образом не Яваскрипт

Я имел в виду то, что большинство попыток Zeroglif'а обсудить что-либо, касающееся непосредственно языка программирования, Вы просто "на корню" пресекали демонстрацией показателей экономии денег и времени...
Re[15]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 10.08.07 11:44
Оценка:
Здравствуйте, AKS., Вы писали:

AKS>Здравствуйте, Mamut, Вы писали:


M>>Я все равно так и не понял, в чем выражается протест против статьи, фреймворков вообще и фреймворка jQuery в частности


AKS>Да нет протеста — есть конкретное пожелание (я его высказал).

AKS>Для того чтобы меня было легче понять, напишу кое-что еще. Но перед этим — небольшая ремарка.
AKS>Мы с Вами прекрасно понимаем, что каждый из нас ведет свою игру — у Вас одна (в подробности из уважения не лезу), у меня — игра другая.
AKS>А теперь давайте рассмотрим гипотетическую ситуацию. Прихожу я, как соискатель вакантной должности javascript-программиста (той самой, о которой Вы писали чуть раньше, с интересной такой зарплатой в 1000$), ну, например, лично к Вам. Говорю:

дальше поскипано.

Вот ведь вам дался этот пример с таблицей Но это — в сторноу. Теперь рассказываю я, как работодатель. У меня есть программист, который за две недели напишет пользовательский интерфейс и программист, который за две недели только-только закончит выправлять ошибки (в основном, связанные с кроссбраузерностью, скорее всего) в своем, родном, с нуля написанном фреймворке. Второй программист в конце этой второй недели вылетит на улицу, потому что моя основная задача — это написание продукта, а не борьба с Яваскриптом.

Вообще фраза

Да вообще-то нам javascript-программист теперь скорее всего не понадобится — теперь нам его заменит jQuery.

показывает либо полное непонимание того, что от javascript-программиста требуется, либо полное непонимание того, что такое фреймворк, либо и того и другого.

Например. Для того, чтобы написать вот это нужен javascript-программист. Но это не мешает такому программисту использовать jQuery.

— Но позвольте, неужели Вы собираетесь положиться на какую-то "дармовщинку" из инета?
— А почему бы и нет, — отвечаете Вы, — вот посмотрите статейку, люди рекомендуют!


Контрцитаты:

http://rsdn.ru/Forum/?mid=2015762
Автор: Sinclair
Дата: 21.07.06
и http://rsdn.ru/Forum/?mid=2027495:
Автор: Sinclair
Дата: 27.07.06

Из всего этого следуют Правила большого пальца:
1. Все, что можно купить, нужно покупать (cюда же входит подбор бесплатных компонентов, при их наличии)
2. Все, что нельзя купить, нужно аутсорсить
3. Нельзя аутсорсить "core" — то, за что тебе платят деньги.

Т.е., если ты продаешь программу для бухгалтерии:
1. СУБД, компилятор, визуальные компоненты, инсталлер, хелп вьювер и т.п. — приобретаются
2. Документация, саппорт, скины, кастомные кофигурации — аутсорсятся.
3. Ядро пишется твоей командой высококлассных специалистов, проверяется твоей командой профессионального QA.

Сейчас большинство народу, не принявшего п.1, уже вышли из бизнеса. Сейчас идет освоение п.2.




1. Определиться с основными требованиями к решению. Как правило, происходит на этапе написания SRS, который, вообще говоря, не зависит от того, собственный будет велосипед или готовое решение.
2. Пойти в инет и выбрать некоторое количество решений-кандидатов.
Это делается при помощи Google; как правило более 4х часов на поиски отводить смысла нет. Иногда, в особо запущенных случаях (не удается подобрать хороший запрос для гугла) кидается вопрос в тематический форум(ы). Это удешевляет данный шаг, но делает его дольше (надо дать хотя бы неделю, чтобы завсегдатаи ответили)ю
3. Полученный на предыдущем шаге список просеивается на предмет получения двух-трех кандидатов, которые похожи на то, что надо. Как правило, на это достаточно 8 часов
4. Для отобранных финалистов достаются демы/триалы, и выполняется некоторый набор тестов для проверки п.1. Опять же, жедательно ограничить это дело максимум 8 часов на кандидата.
5. По результатам отбирается лучший вариант. Он и идет в проект — покупается необходимая лицензия и в бой.

Примечания:
— если на шаге 4 ни один из финалистов не выдержал испытания, то надо вернуться на шаг 3 и выбрать других.
— если на шаге 3 не удалось ничего найти, возвращаемся на шаг 2.
— если и здесь нас ждет облом, заключаем, что выхода нет и пишем свой велосипед.

В большинстве случаев, мы получаем готовый результат за одну рабочую неделю одного разработчика. Возможны, конечно, варианты:
1. Если ищется готовое решение для большой проблемы, то имеет смысл умножить оценки для этапа 4 на эмпирический коэффициент.
2. Если ищется какая-нибудь экзотика, то нужно увеличить оценки для этапа 2, т.к. гугл хорошо ищет только популярный контент.
3. В некоторых случаях имеет смысл не делить на шаги, а делать "поиск с возвратами": пытаться зайти как можно дальше с каждым из вариантов, возвращаясь назад в случае обнаружения нерешаемой проблемы. Симптомы того, что у вас и есть некоторый случай:
— не требуется выбрать самое лучшее решение. Достаточно удовлетворительного.
— рынок завален готовыми решениями, и анализ всего списка будет потерей времени.


Так вот. Моя задача — построить сайт, включающий разветвленную и достаточно сложную админку и местами не менее сложный фронтенд. Каким боком мне уперлась разработка своего собственного фреймворка? У меня нет лишних n месяцев и n килобаксов, чтобы из собственного кармана финансировать разработку оного. Обзор рынка на определенный момент показал, что всем нашим требованиям удовлетворяет jQuery. Мы ее и выбрали. Мало того, на нее перешел и соседний офис, переписав внутренние сайты со своих поделок на нее и переведя один крупный сайт внешний на нее же. Обратно возвращаться никто не хочет, потому что нет смысла: производительность возросла в разы, проблемы с различными браузерами уменьшились так же в разы. И не только соседний офис

AKS>Надеюсь, Вы поймете меня верно — ничего личного, просто такое вот стечение обстоятельств...


AKS>Еще немного вот об этом:

M>>А, ну да, код на Яваскрипте, библиотека на Яваскрипте, но это никоим образом не Яваскрипт

AKS>Я имел в виду то, что большинство попыток Zeroglif'а обсудить что-либо, касающееся непосредственно языка программирования, Вы просто "на корню" пресекали демонстрацией показателей экономии денег и времени...


Я не видел попыток обсуждения чего-то, касающегося непосредственно языка программирования. Может, я что-то упустил, ткните меня.


dmitriid.comGitHubLinkedIn
Re[13]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 10.08.07 11:51
Оценка:
Здравствуйте, Zeroglif, Вы писали:

M>>А фреймворк jQuery действительно позволяет находить решения быстрее, чем аналогичные на чистом JS. Кстати, как только ты написал свой "типа фреймворк", то у тебя уже тоже не "чистый JS". В этом отношении jQuery ничем не грязнее твоего фреймворка — он тоже на JS написан.


Z>Интересный довод. Честно говоря, не я предложил термин "чистый javascript". Согласись, что если на грязный и чистый не делить, то тогда нужно показывать в своих статьях и "мясо", которое стоит за вроде-как-бы-простым-с-виду-вызовом. Чистый должен встать против чистого. А иначе я могу сказать, что вот мой новый javascript — f(), вот там всё и делается.


Синклер уже говорил
Автор: Sinclair
Дата: 09.08.07
о разнице в терминах.

Цитирую еще раз:

Под простотой обычно понимают простоту применения. Поэтому никакой "кажущести" нет. Простой код — он и есть простой. Простота кода обеспечивает скорость разработки и дешевизну отладки.
...
Если мы говорим о вычислительной сложности, то оперировать количеством вызовов — бессмысленно. Потому что нас интересуют наблюдаемые характеристики. Простота прикладного кода — одна из таких наблюдаемых характеристик. Ее наблюдает программист, тестер, и менеджер проекта.


Z>Вот кстати, если ты облазил исходники вдоль и поперёк, то возьми любой отдельный кусок, допустим, манипуляцию классами, что ты там увидишь — неоптимальный код (inArray, each и т.п.),


чем он неоптимален?

Z>или возьмём твою любимую isFunction, её что можно использовать на низком уровне (в отрыве от фреймворка)?


можно. если где-то в своем коде необходимо узнать, функция ли передана в качестве параметра.

Z>Она что переварит всё, что угодно корректно? Конечно, нет.


Почему нет? У нее ровно одна задача — узнать, является ли передаваемый параметр функцией. Со своей задачей она справляется.

Z> Это просто сейчас попалось на глаза. Не сомневаюсь, что там куча таких тонких мест, по своей природе супер-динамический язык, помноженный на весёлые интерпретаторы не оставляет нам никаких надежд поиметь устойчивую (не fragile) либу.


Волков бояться — в лес не ходить. Свой собственный фреймворк, помноженный на супер-динамический язык, помноженный на весёлые интерпретаторы даст гораздо более нестабильную либу. Причины такого я уже приводил
Автор: Zeroglif
Дата: 09.08.07
(в конце сообщения)

Z> Чужую. Лучше делать своё. А там и опыт нарисуется. Боевой.


Пока вы будете писать свою либу, я уже сдам свой проект и возьмусь за другой.


dmitriid.comGitHubLinkedIn
Re[15]: jQuery – Javascript нового поколения
От: ddocker Россия www.codelab.ru
Дата: 10.08.07 12:07
Оценка: +1
AKS>Тут Вы вспоминаете, что читали на днях интересную статью под названием "jQuery – Javascript нового поколения". Немного подумав и взвесив все "за" и "против" (прокалькулировав заодно фонд зарплаты в "новом свете", исходящем от jQuery), Вы мне отвечаете:
AKS>— Да вообще-то нам javascript-программист теперь скорее всего не понадобится — теперь нам его заменит jQuery.
Это был бы очень неадекватный работодатель.
Нормальный решил бы примерно так: "Да, нам конечно нужен js-программист, а вот чтобы он быстрее реализовал всю нашу функциональность и требования — мы считаем что ему следует активно использовать jq (т.к. вот мы почитали, посмотрели, взвесили, попробовали и т.д.)"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 10.08.07 12:34
Оценка:
Z>Пример с алертом был утрирован СПЕЦИАЛЬНО!

И именно поэтому он некорректен. ПОтому что это — синтетический пример, который ничего не доказывает.

Я привел тебе гораздо более реальный пример, который ты благополучно проигнорировал.
Тултип в 36КБ против jQuery + тултип в 29.7КБ

Или тот же пример с $('a.ajax')...

Эти примеры ты активно игнорируешь, хотя они показывают, что код ручками проигрывает коду, основанному на jQuery.

Z> Чтобы продемонстрировать избыточность кода задаче. Очень похожие утрированные примеры (подвесить клик на якорь или добавить класс и т.п.) используются в большинстве туториалов. Общий посыл при этом — смотрите и учитесь, как просто и легко можно это сделать по сравнению с чистым javascript. Хотя на самом деле (вообще не понимаю, как можно об этом ещё и спорить) отдельная задача и даже несколько связанных задач решаются руками проще/оптимальнее/качественнее, чем с использованием большого избыточного (априори всегда избыточного) пакета. Тем более чужого. Тем более javascript-пакета. Тем более в исходники которого, как оказалось, никто и не смотрит.


Если хочешь, я напишу статью "Advanced uses of jQuery". Хотя она никому нафиг не сдалась, потому что через два дня после работы с jQuery люди сами начинают писать код любой сложности. Да в туториалах можно найти полезную инорамцию, идущую дальше, чем простые примеры (например, My First ExtJS DataGrid).

А насчет отдельных задач...

Задача 1. У меня на странице есть ссылки с классом .ajax. Необходимо сделать так, чтобы при щелчке на эти ссылки аяксом подгружалась страница, находящаяся по адресу в href соответствующей ссылки, а содержимое той страницы загружалось в элемент с id="ajax_result" (например, нечто похожее реализовано в этом тултипе и у меня на странице).

Показываю в последний раз :
<a href="/test1.html" class="ajax">Ссылка 1</a>
<a href="/test2.html" class="ajax">Ссылка 2</a>

// У меня на странице есть ссылки с классом .ajax
$("a.ajax")
    .click(           // Необходимо сделать так, чтобы при щелчке на эти ссылки
        function(){    
            $.get(     // аяксом подгружалась страница
                $(this).attr("href"), //находящаяся по адресу в href соответствующей ссылки
                callback
            )
        }
    );

function callback(result){
    $("#ajax_result").append(result); // а содержимое той страницы загружалось в элемент с id="ajax_result"
}


Задача 2. Изменить задачу 1 так, чтобы тоже самое работало для всех ссылок в элементе с id="other":

<div id="other">
    <a href="/test1.html">Ссылка 1</a>
    <a href="/test2.html">Ссылка 2</a>
</div>

$("#other a")... // остальной код такой же


Ваш ход. Можно использовать "чистый" JS или самописные фреймворки.

Z>Но если количество и объём многомерных задач таковы, что мы уже подходим к раскрытию возможностей jQuery по-максимому, то фреймворк можно (заметьте, я не выступаю против, я говорю, что можно) использовать, на то он и большой пакет.


Просто таки гигантский пакет. Целых 20КБ кода

Z>Но в этом смысле сразу возникает парадоксальная ситуация — программист делает большой суръёзный javascript-проект, что предполагает всё-таки владение предметом, и при этом он не в состоянии предложить свои собственные решения, которые бьют строго в заданную оптимальную точку.


Почему считается, что оптимальная точка — это, например, умение написать кроссбраузерный аякс, а не, например, taconite на основе уже готового и кроссбраузерного аякса и готовой кроссбраузерной выборки по селекторам? Я лучше напишу taconite, чем в очередной раз заново писать низкоуровневый код.

Z>Почему так происходит? Само собой, ни один из нас не признается в своей слабой подготовке или в нехватке времени, или в нехватке браузеров, или в недостатке кросс-браузерного опыта, или в ещё в чём, не знаю


Я, по-моему, уже не раз говорил, что наша задача — это не разрабатывать свой собственный javascript-фреймворк, а разрабатывать продукт.

Яркий пример. Wordpress с версии 2.2 используют jQuery. Почему они не написали свой собственный фреймворк? Потому что их задача — выпустить оптимальный кросс-браузерный форумный пакет, а не разрабатывать велосипеды. У них есть задачи поважнее и поинтереснее, чем бороться с браузерами и тестировать Javascript на двух десятках платформ. Им проблем с кросс-браузерным CSS хватает.


Z>Заступайтесь на здоровье, друзья, но только в узком профессиональном мире фреймворков, сражаясь там в войне с Prototype.js или ещё с кем, но не учите мир жить. Не гоните волну на javascript, не отталкивайте он него людей, не учите псевдо-коду, не учите плохому псевдо-коду, вместо книг "Learning jQuery" пишите книги "Learning Javascript"...


Расскажу сказочку. Из мира прикладного программирования. Есть такая вещь, как windows api, благодаря которому, ты, например, под виндой можешь открыть окно и читать это сообщение.

Окошки в windows api требуют кучи кода:
NT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
                   LPSTR lpCmdLine, int nCmdShow)
{
    MSG        Msg;
    HWND       hWnd;
    WNDCLASSEX WndClsEx;

    // Create the application window
    WndClsEx.cbSize        = sizeof(WNDCLASSEX);
    WndClsEx.style         = CS_HREDRAW | CS_VREDRAW;
    WndClsEx.lpfnWndProc   = WndProcedure;
    WndClsEx.cbClsExtra    = 0;
    WndClsEx.cbWndExtra    = 0;
    WndClsEx.hIcon         = static_cast<HICON>(LoadImage(hInstance,
                                        MAKEINTRESOURCE(IDI_ANATWND),
                                        IMAGE_ICON,
                    32,
                                        32,
                    LR_DEFAULTSIZE));
    WndClsEx.hCursor       = LoadCursor(NULL, IDC_ARROW);
    WndClsEx.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
    WndClsEx.lpszMenuName  = NULL;
    WndClsEx.lpszClassName = ClsName;
    WndClsEx.hInstance     = hInstance;
    WndClsEx.hIconSm       = static_cast<HICON>(LoadImage(hInstance,
                                       MAKEINTRESOURCE(IDI_ANATWND),
                                       IMAGE_ICON,
                                       16,
                                       16,
                                       LR_DEFAULTSIZE));

    // Register the application
    RegisterClassEx(&WndClsEx);

    . . . 

    return 0;
}


Потом всякие плохие дяди, которые не хотели писать эти кучи кода вручную, начали придумывать разные фреймворки, такие как wxWidgets, Qt и даже MFC и WTL или HTMLayout. Все для того, чтобы можно было написать что-то вроде
MainWindow mainWin;
mainWin.show();


И, не поверишь, люди мало того, что эти фреймворки используют, но даже в код им не смотрят. Почему? Потому что осознание того, что ты можешь быстро и эффективно создать крутое приложение гораздо важнее осознания того, что ты можешь потратить кучу времени, сил и денег, чтобы сделать... в общем-то тот же фреймворк.

В веб-программировании — то же самое. Почему бы не взять уже готовый, да еще и бесплатный, но дествительно хороший и быстрый фреймворк и сосредоточится на поставленных передо мной задачах, а не писать все то же самое с нуля? Только потому что оно "фи" чужое? Странные подходы. С такими подходами мы бы давно в DOS'е сидели...

Z>Не знаю, что до меня пытаются тут донести, но про портянки я уже понял, это типичный такой наезд в стиле "лучше уже не бывает, не выёживайся", а иначе — докажи. Во-первых, не судите по себе , а во-вторых, отказывать в профессионализме тем, кто не использует js-фреймворки в своей программистской работе (или большую часть работы делает руками), по меньшей мере неуважительно по отношению к вашим же коллегам. Люди пишут прекрасный код. Люди пишут ужасный код. Так было, есть и будет.


Я никому ни в чем не отказываю. Но, используя jQuery, можно направить свою энергию на решение гораздо более интересных задач, чем написание низкоуровневого кода.

D>>А потом еще копипайстить из одного проекта в другой — если снова заходите использовать...


Z>Эти доводы я принимаю и не принимаю одновременно, согласитесь, что всё зависит от ситуации. Компании "A", построившей все свои проекты на базе JSLibrary №13 ваши jsQuery-наработки даром не нужны. Но, замечу, всегда будет нужен ваш опыт в отрыве от любой либы...


Отучаемся говорить за всех. Мне известно много случаев, когда компания "А" с радостью переходила на грамотный фреймворк, потому что избавлялась от кучи геморроя и головной боли.

D>>Странные посты против фрейворков вообще, вы вот и на сервер-сайд наверное никаких фреймворков не используете, сами GET/POST валидируете и популируете, постинг каждой формы по новой все этапы реализуете, различные утилитные функции, велосипеды изобретаете на каждом шагу наверное...


Z>Это посты не против либ как таковых вообще, пользуйтесь, если нравится, а посты против того, что кто-то имеет смелость сравнивать javascript vs. jQuery или javascript-программирование vs. псевдо-программирование.


Что тако псевдо-программирование?

Например, taconite — это псевдо-программирование? Или, скажем, Interface. Или, скажем, Ext?


dmitriid.comGitHubLinkedIn
Re[14]: jQuery – Javascript нового поколения
От: Zeroglif  
Дата: 10.08.07 13:14
Оценка: 35 (2)
Z>>Вот кстати, если ты облазил исходники вдоль и поперёк, то возьми любой отдельный кусок, допустим, манипуляцию классами, что ты там увидишь — неоптимальный код (inArray, each и т.п.),

M>чем он неоптимален?


A посмотреть и подумать, можно ли его упростить?

Z>>или возьмём твою любимую isFunction, её что можно использовать на низком уровне (в отрыве от фреймворка)?


M>можно. если где-то в своем коде необходимо узнать, функция ли передана в качестве параметра.


Ну-ну.

Z>>Она что переварит всё, что угодно корректно? Конечно, нет.


M>Почему нет? У нее ровно одна задача — узнать, является ли передаваемый параметр функцией. Со своей задачей она справляется.


Ну передай ей для начала значения этих переменных:

var a, b, c;

a = /^\dfunction\d/;
b = new String('Wow, J(ava)Script is soooo functional...');
c = ['method', 'function', 'object'];
c.constructor = 'Lego';


Re[9]: jQuery – Javascript нового поколения
От: Zeroglif  
Дата: 10.08.07 13:46
Оценка: -1
Здравствуйте, Mamut, Вы писали:

Z>>Пример с алертом был утрирован СПЕЦИАЛЬНО!


M>И именно поэтому он некорректен. ПОтому что это — синтетический пример, который ничего не доказывает.


M>Я привел тебе гораздо более реальный пример, который ты благополучно проигнорировал.

M>Тултип в 36КБ против jQuery + тултип в 29.7КБ

M>Или тот же пример с $('a.ajax')...


M>Эти примеры ты активно игнорируешь, хотя они показывают, что код ручками проигрывает коду, основанному на jQuery.


Я не игнорирую, я сознательно отказываюсь играть по вашим правилам и доказывать что-то, впрягаясь в программирование ради доказательства. Пример с алертом некорректен в такой же степени, как и все те примитивные примеры, на базе которых показывается лже-простота пропагандистами, как и твой пример с раскраской строк, такой же не оптимальный и не требующий jQuery по большому счёту. Это и есть разговор о javascript и о программировании (который ты не увидел), разговор, на которой я настроился, а не на "про скорость разработки, зарплаты, бизнес и проч".

Z>> Чтобы продемонстрировать избыточность кода задаче. Очень похожие утрированные примеры (подвесить клик на якорь или добавить класс и т.п.) используются в большинстве туториалов. Общий посыл при этом — смотрите и учитесь, как просто и легко можно это сделать по сравнению с чистым javascript. Хотя на самом деле (вообще не понимаю, как можно об этом ещё и спорить) отдельная задача и даже несколько связанных задач решаются руками проще/оптимальнее/качественнее, чем с использованием большого избыточного (априори всегда избыточного) пакета. Тем более чужого. Тем более javascript-пакета. Тем более в исходники которого, как оказалось, никто и не смотрит.


M>Если хочешь, я напишу статью "Advanced uses of jQuery". Хотя она никому нафиг не сдалась, потому что через два дня после работы с jQuery люди сами начинают писать код любой сложности. Да в туториалах можно найти полезную инорамцию, идущую дальше, чем простые примеры (например, My First ExtJS DataGrid).


Хочу, полный разбор исходников, узкие места, сравнение всего кода со всем кодом, а не передёргивание с вызовами. Может тогда меньше по javascript тусовкам будет бродить привидений, который задают вопросы вроде, "а что это за синтаксис такой $(), а то не могу его в доках найти".

M>А насчет отдельных задач...


M>Задача 1. У меня на странице есть ссылки с классом .ajax. Необходимо сделать так, чтобы при щелчке на эти ссылки аяксом подгружалась страница, находящаяся по адресу в href соответствующей ссылки, а содержимое той страницы загружалось в элемент с id="ajax_result" (например, нечто похожее реализовано в этом тултипе и у меня на странице).


M>Показываю в последний раз :

M>
M><a href="/test1.html" class="ajax">Ссылка 1</a>
M><a href="/test2.html" class="ajax">Ссылка 2</a>
M>

M>
M>// У меня на странице есть ссылки с классом .ajax
M>$("a.ajax")
M>    .click(           // Необходимо сделать так, чтобы при щелчке на эти ссылки
M>        function(){    
M>            $.get(     // аяксом подгружалась страница
M>                $(this).attr("href"), //находящаяся по адресу в href соответствующей ссылки
M>                callback
M>            )
M>        }
M>    );

M>function callback(result){
M>    $("#ajax_result").append(result); // а содержимое той страницы загружалось в элемент с id="ajax_result"
M>}
M>


M>Задача 2. Изменить задачу 1 так, чтобы тоже самое работало для всех ссылок в элементе с id="other":


M>
M><div id="other">
M>    <a href="/test1.html">Ссылка 1</a>
M>    <a href="/test2.html">Ссылка 2</a>
M></div>
M>

M>
M>$("#other a")... // остальной код такой же
M>


M>Ваш ход. Можно использовать "чистый" JS или самописные фреймворки.


Хожу:

f();


Z>>Но если количество и объём многомерных задач таковы, что мы уже подходим к раскрытию возможностей jQuery по-максимому, то фреймворк можно (заметьте, я не выступаю против, я говорю, что можно) использовать, на то он и большой пакет.


M>Просто таки гигантский пакет. Целых 20КБ кода


Во-первых 60 скопейками, а не 20, но это модная манера такая сжатый код презентовать. И 20 много, если тебе нужно только то, что укладывается в 2-4-5-10...

Z>>Но в этом смысле сразу возникает парадоксальная ситуация — программист делает большой суръёзный javascript-проект, что предполагает всё-таки владение предметом, и при этом он не в состоянии предложить свои собственные решения, которые бьют строго в заданную оптимальную точку.


M>Почему считается, что оптимальная точка — это, например, умение написать кроссбраузерный аякс, а не, например, taconite на основе уже готового и кроссбраузерного аякса и готовой кроссбраузерной выборки по селекторам? Я лучше напишу taconite, чем в очередной раз заново писать низкоуровневый код.


Z>>Почему так происходит? Само собой, ни один из нас не признается в своей слабой подготовке или в нехватке времени, или в нехватке браузеров, или в недостатке кросс-браузерного опыта, или в ещё в чём, не знаю


M>Я, по-моему, уже не раз говорил, что наша задача — это не разрабатывать свой собственный javascript-фреймворк, а разрабатывать продукт.


Я с кем разговариваю? Ты менеджер, владелец, программист или всё вместе? Выдави из себя javascript-программиста и поговорим. А иначе я начинаю путаться в маркетологических смыслах.

M>Яркий пример. Wordpress с версии 2.2 используют jQuery. Почему они не написали свой собственный фреймворк? Потому что их задача — выпустить оптимальный кросс-браузерный форумный пакет, а не разрабатывать велосипеды. У них есть задачи поважнее и поинтереснее, чем бороться с браузерами и тестировать Javascript на двух десятках платформ. Им проблем с кросс-браузерным CSS хватает.


Опять про бизнес, теперь Wordpress-ный.

D>>>А потом еще копипайстить из одного проекта в другой — если снова заходите использовать...


Z>>Эти доводы я принимаю и не принимаю одновременно, согласитесь, что всё зависит от ситуации. Компании "A", построившей все свои проекты на базе JSLibrary №13 ваши jsQuery-наработки даром не нужны. Но, замечу, всегда будет нужен ваш опыт в отрыве от любой либы...


M>Отучаемся говорить за всех. Мне известно много случаев, когда компания "А" с радостью переходила на грамотный фреймворк, потому что избавлялась от кучи геморроя и головной боли.


Отучаемся передёргивать карты, я говорю не за всех, а о том, что всё зависит от ситуации. То есть говорю про то же, что и ты.

D>>>Странные посты против фрейворков вообще, вы вот и на сервер-сайд наверное никаких фреймворков не используете, сами GET/POST валидируете и популируете, постинг каждой формы по новой все этапы реализуете, различные утилитные функции, велосипеды изобретаете на каждом шагу наверное...


Z>>Это посты не против либ как таковых вообще, пользуйтесь, если нравится, а посты против того, что кто-то имеет смелость сравнивать javascript vs. jQuery или javascript-программирование vs. псевдо-программирование.


M>Что тако псевдо-программирование?


M>Например, taconite — это псевдо-программирование? Или, скажем, Interface. Или, скажем, Ext?


Псевдопрограммирование в смысле javascript — это то, что описывает твоя статья, это управление самодельным неоптимальным избыточным нетобойсделанным АРI от джона/пети/димы с отсутствующим прошлым и неясным будущим...
Re[9]: jQuery – Javascript нового поколения
От: Zeroglif  
Дата: 10.08.07 13:59
Оценка:
S>Вообще, если лично тебе не нравится jQuery — никто ее тебе не навязывает. Пиши себе. Или у тебя страшная ревность к тому, что раньше ты брал за advanced javascript effects мегабабло, а теперь это доступно любому пионеру через два дня обучения jQuery? Может ты боишься, что веб программисты встрянут и разучатся биндить обработчики вручную, без jQuery? Ну, до этого ой как далеко...

Грубишь, конечно, но отвечу по пунктам:

— я нормально отношусь к jQuery, во всяком случае это не так плохо написано, как Prototype;
— я не ревную к мегабаблу, так как в жизни не зарабатывал программированием;
— пионеры с jQuery в руках меня не пугают, меня пугают невежественные пионервожатые;
— и я не боюсь, что кто-то там что-то разучится биндить, я боюсь, когда вообще перестают учиться по наущению.
Re[9]: jQuery – Javascript нового поколения
От: AKS.  
Дата: 10.08.07 14:26
Оценка: -1
Здравствуйте, Mamut!

Что-то как-то не получается побеседовать. Вы, чуть что, сразу оправдываться: "Мне с jQuery хорошо, никогда раньше так не жил". Может хватит — ведь никто не собирается отнимать у Вас эту "игрушку". Более того, прочитав о ваших программерах, работающих с "черепашьей" скоростью (по две недели, да еще и оставляют Вас потом один-на-один с JavaScript, когда Вы их увольняете), я даже пустил скупую мужскую слезу из сочувствия, и решил — Вам jQuery сам бог послал!

Zeroglif предложил целую кучу различных вариантов развития этой темы в конструктивном ключе — выбирайте на свой вкус!

Кстати, насчет тултипа — чем плоха, к примеру Соуденовско-Шуркаевская классика? Почему люди изобретают "тяжеленный велосипед с рамой от jQuery"?
Re[15]: jQuery – Javascript нового поколения
От: Mamut Швеция http://dmitriid.com
Дата: 10.08.07 14:27
Оценка:
Z>>>Вот кстати, если ты облазил исходники вдоль и поперёк, то возьми любой отдельный кусок, допустим, манипуляцию классами, что ты там увидишь — неоптимальный код (inArray, each и т.п.),
M>>чем он неоптимален?
Z>A посмотреть и подумать, можно ли его упростить?

Зачем? Может, вместо того, чтобы "наискосок" читать код, может посмотришь, как и где эти функции используются? Вот неполюбившиеся тебе inArray и each:
    inArray: function( b, a ) {
        for ( var i = 0, al = a.length; i < al; i++ )
            if ( a[i] == b )
                return i;
        return -1;
    },

    each: function( obj, fn, args ) {
        if ( obj.length == undefined )
            for ( var i in obj )
                fn.apply( obj[i], args || [i, obj[i]] );
        else
            for ( var i = 0, ol = obj.length; i < ol; i++ )
                if ( fn.apply( obj[i], args || [i, obj[i]] ) === false ) break;
        return obj;
    }


Что именно в них не нравится?

Z>>>или возьмём твою любимую isFunction, её что можно использовать на низком уровне (в отрыве от фреймворка)?

M>>можно. если где-то в своем коде необходимо узнать, функция ли передана в качестве параметра.

Z>Ну-ну.


Что ну-ну?(обожаю такую аргументацию) Вот она:
    // This may seem like some crazy code, but trust me when I say that this
    // is the only cross-browser way to do this. --John
    isFunction: function( fn ) {
        return !!fn && typeof fn != "string" && !fn.nodeName && 
            fn.constructor != Array && /function/i.test( fn + "" );
    }


Что мешает ее использовать в своем коде?

Z>>>Она что переварит всё, что угодно корректно? Конечно, нет.

M>>Почему нет? У нее ровно одна задача — узнать, является ли передаваемый параметр функцией. Со своей задачей она справляется.
Z>Ну передай ей для начала значения этих переменных:

Z>
Z>var a, b, c;

Z>a = /^\dfunction\d/;
Z>b = new String('Wow, J(ava)Script is soooo functional...');
Z>c = ['method', 'function', 'object'];
Z>c.constructor = 'Lego';
Z>


Z>




a — функция
b — не функция
c — не функция

Что и следовало ожидать. Почему a — функция? Читаем ECMA-262 пункт 15.10.2:

A regular expression pattern is converted into an internal function using the process described below.

Паттерн регулярного выражения конвертируется во внутреннюю функцию используя описанный процесс.


Так же пункт 15.10.2.2:

A Pattern evaluates ("compiles") to an internal function value. RegExp.prototype.exec can then apply this function to a string ...

Паттерн вычисляется ("компилирутся") во внутренне функциональное значение. RegExp.prototype.exec может потом применить эту функцию к строковому литералу...


Какие еще "аргументы" будут?


dmitriid.comGitHubLinkedIn
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.