5 сентября 2007 в 23:40

jQuery для JavaScript-программистов перевод

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

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



Пространство имен (namespacing)



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

jQuery вводит единственный объект в глобальное пространство имен — функцию/объект jQuery. Все остальное — это либо непосредственное свойство jQuery, либо метод объекта, возвращаемого вызовом функции jQuery.

Что можно сказать об улучшениях языка? Большинство библиотек предоставляют некоторое подобие функций отображения, фильтрации и обрезания, которые, к несчастью, отсутствуют в тех движках JavaScript, которые включены в большинство браузеров. Некоторые библиотеки напрямую расширяют встроенные в JavaScript классы String и Array, но также не до конца безопасно. String.prototype и Array.prototype являются самостоятельными глобальными пространствами имен, и добавление в них каких-либо свойств влечет опасность коллизий, связанных с использованием одних и тех же имен переменных в разных контекстах.

В jQuery имеется некоторое количество функций, расширяющих возможность JavaScript, но каждая из них является доступной только как свойство объекта jQuery: jQuery.each, jQuery.extend, jQuery.grep, jQuery.map, jQuery.merge и jQuery.trim. Они по определению не будут конфликтовать с каким-либо другим кодом.

Печально известная функция $



Я был не до конца честен, когда заявил о том, что jQuery вводит только один символ в глобальное пространство имен, на самом деле есть еще и $: он используется как сокращение для jQuery. Слава богу, это производится достаточно мягко: если вам снова требуется ваша прежняя функция $ (например, если у вас есть часть кода, основанная на Prototype), вы можете вызвать jQuery.noConflict(), чтобы вернуть свою старую функцию $.

Если вам требуется ограничить использование функции $ для jQuery не опасаясь коллизий при каком-либо другом использовании глобальной функции $, документация по jQuery предлагает следующий способ:

(function($) {
    // Внутри этого блока <code>$</code> относится к jQuery
    // Изящно, правда?
})(jQuery);


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

Выбираем элементы



Каждый jQuery-оператор начинается с выбора одного или нескольких узлов DOM. Синтаксис селекторов jQuery (внутренний язык этой библиотеки) является интересным гибридом спецификаций CSS 1, 2, немного CSS 3, немного XPath и еще малость других расширений. Я не буду углубляться в детали, просто приведу несколько полезных примеров:

  • jQuery('div.panel')
    Все div'ы с class="panel"
  • jQuery('p#intro')
    Параграф с id="intro"
  • jQuery('div#content a:visible')
    Все видимые ссылки внутри div с id="content"
  • jQuery('input[@name=email]')

jQuery('table.orders tr:odd')
Все четные строки в таблице с class="orders"
jQuery('a[@href^="http://"]')
Все внешние ссылки (те, которые начинаются с http://)
jQuery('p[a]')
Все параграфы, в которых есть хотя бы одна ссылка


Наибольший интерес из вышеописанного представляют :visible и :odd, которые являются специфичными только для jQuery. Стоит также отметить, что выбор атрибутов использует знак @, что более соответствует XPath нежели CSS 2.

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

Чего-нибудь с ними делаем



Объект, который возвращают селекторы jQuery, является довольно интересным зверем. Он представляет собой набор DOM-элементов и ведет себя немного как массив: у него есть свойство length, к его элементам можно получить доступ по индексу и (что более важно) Firebug расценивает его именно как массив при отображении в своей консоли. Это не более, чем красивая иллюзия: набор элементов, на самом деле, — это объект jQuery, у которого есть большое число методов для выбора, изменения или расширения имеющегося набора.

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

Я не буду перечислять все доступные методы (эта можно посмотреть и на visualjquery.com), но хочу привести некоторые примеры. Если у вас есть Firebug, вы можете попробовать их самостоятельно: просто нужно воспользоваться закладкой «Вставить jQuery» ( javascript:void(function(){var s=document.createElement('script');s.src='http://code.jquery.com/jquery-1.1.2.js'; document.getElementsByTagName('head')[0].appendChild(s);}()) ) для загрузки самой библиотеки для любой страницы, а затем вставить примеры кода в консоль Firebug (прим.: можно и без Firebug: достаточно загрузить jQuery с помощью указанной ссылки и вызвать приведенные примеры в адресной строке браузера, не забыв в начале javascript: и какой-либо alert в конце (чтобы на страницу не выводилось возвращаемое значение)).

  • jQuery('div#primary').width(300);
    Выставляет ширину div id="primary" в 300 пикселей.
  • jQuery('p').css('line-height', '1.8em');
    Выставляет высоту строки в 1.8em для всех параграфов.
  • jQuery('li:odd').css({color: 'white', backgroundColor: 'black'});
    Применяет 2 CSS-правила для каждого пункта списка; заметьте, что функция css() может принимать объект таблицы стилей вместо двух строк.
  • jQuery('a[@href^="http://"]').addClass('external').attr('target', '_blank');
    Добавляет класс "external" для всех внешних ссылок (тех, что начинаются с http://), затем добавляет target="_blank", чтобы увеличить различие. В данном примере используется цепочка вызовов, описанная ниже.
  • jQuery('blockquote').each(function(el) { alert(jQuery(this).text()) });
    Для каждого тега blockquote на странице выводит сообщение (alert) с его текстовым содержанием (включая HTML-теги).
  • jQuery('a').html('Нажми здесь!');
    Заменяет весь текст в ссылках на странице призывом «Нажми здесь!».


Ниже несколько примеров методов, которые возвращают значение от первого элемента, найденного по шаблону:

  • var width = jQuery('div').width();
    Какая ширина у первого div на странице?
  • var src = jQuery('img').attr('src');
    Какое значение у атрибута src у первой картинки на странице?
  • var color = jQuery('h1').css('color');
    Какой цвет у первого h1?


Хочу отметить удобную симметрию таких методов: они используются как для выставления атрибутов (когда принимают 2 аргумента или у передаваемого объекта несколько свойств), так и для прочтения значений этих атрибутов (если передается только один аргумент). Такая симметрия используется во всей библиотеке jQuery, что очень сильно облегчает запоминание API.

Наконец, есть несколько методов, которые изменяют весь набор найденных элементов. Многие из них также обеспечивают перемещение по DOM-дереву:

  • jQuery('div').not('[@id]')
    Возвращает все div, у которых нет атрибута id.
  • jQuery('h2').parent()
    Возвращает все элементы, которые являются непосредственными родителями h2.
  • jQuery('blockquote').children()
    Возвращает все элементы, вложенные в blockquote.
  • jQuery('p').eq(4).next()
    Находит пятый параграф на странице, потом находит следующий элемент (т.е. непосредственного соседа справа).
  • jQuery('input:text:first').parents('form')
    Находит родительский элемент для формы, которая содержит первое поле input type="text" на странице. Опциональным параметром для parents() является другой селектор.


Цепочки вызовов



Команда разработчиков jQuery часто хвастается по поводу поддержки в этой библиотеке цепочки вызовов, доходя до заявлений типа «jQuery создана для того, чтобы изменить ваш стиль программирования на JavaScript» прямо на главной странице. Честно говоря, лично я нахожу эту технику скорее боковым ответвлением, чем дорогой в будущее, но с радостью заявляю, что вы можете использовать jQuery, избежав длинных цепочек вызовов.

Короче говоря, цепочки можно использовать для нескольких интересных трюков. В дополнение к использованию набора DOM-выборок вы можете применить jQuery-метод end() для перемещения по стеку объектов и выхода из текущего контекста. Это немного сложно объяснить, но когда вы используете метод, который изменяет текущий (объектный) контекст (например, children() или filter()), вы можете использовать end() чуть позже, чтобы вернуться к предыдущей выборке. Jesse Skinner приводит хороший пример использования этой возможности в своем учебнике Делаем разработку на AJAX проще с jQuery:

$('form#login')
    // прячем внутри формы все <code>label</code> с классом <code>optional</code>
    .find('label.optional').hide().end()
    // добавляем красную границу ко всем полям типа <code>password</code> в форме
    .find('input:password').css('border', '1px solid red').end()
    // добавляем обработчик на событие <code>submit</code> для формы
    .submit(function(){
        return confirm('Вы действительно хотите отправить данные?');
    });


Все это большое преобразование займет всего одну строку. Оно находит форму, находит некоторые элементы внутри нее, применяет к ним изменения, возвращается обратно к форме и добавляет к ней обработчик события submit().

Это милая концепция, но никто не заставляет ее использовать, если вы этого не хотите. Я был просто счастлив визуально разбить свой код с помощью нескольких достаточно красноречивых имен переменных.

Манипулируем с DOM



В jQuery имеется несколько способов для объемных манипуляций с DOM. Первый является несколько неожиданным: функция jQuery может принимать в качестве аргумента кусок HTML-кода, который преобразуется в DOM-элемент (фактически, это просто строка):

var div = jQuery('<div>Some text</div>');


Можно использовать цепочку вызовов, чтобы добавить атрибуты к div, как только он был создан:

var div = jQuery('<div>Some text</div>').addClass('inserted').attr('id', 'foo');


Теперь добавим его к тегу body:

div.appendTo(document.body)


Или вставим его, используя селектор, в имеющийся код:

div.prependTo('div#primary')


Перехватываем события



Все JavaScript-библиотеки нуждаются в методах для обработки событий, и jQuery не является исключением. Как и в случае attr() и css(), методы для событий могут служить двум целям: их вызов с функцией в качестве аргумента назначает обработчик события, вызов без аргумента эмулирует возникновение этого события:

  • jQuery('p').click(function() { jQuery(this).css('background-color', 'red'); });
    Выставляем для всех параграфов обработчик клика мыши, по которому они становятся красными.
  • jQuery('p:first').click()
    Эмулируем клик для первого параграфа на странице.


Похожие функции используются для других событий браузера: mouseover, keyup и т.д. Следует заметить, что при вызове обработчика событий ключевое слово this ссылается на элемент, который это событие вызвал; использование jQuery(this) является расхожим приемом, чтобы вызвать методы jQuery для этого элемента.

Пара функций, относящихся к событиям, заслуживает отдельного упоминания:

jQuery('a').hover(function() {
    jQuery(this).css('background-color', 'orange');
}, function() {
    jQuery(this).css('background-color', 'white');
});


hover() является сокращением для сразу двух событий: onmouseover и onmouseout.

jQuery('p').one('click', function() { alert(jQuery(this).html()); });


one() выставляет обработчик событий, который будет удален после первого своего вызова. В вышеприведенном примере всем параграфы должны сообщить (alert) свое содержание после первого клика по ним.

jQuery также поддерживает собственные события через методы bind() и trigger() (подобные click()). Собственные события могут принимать аргументы, передаваемые при помощи массива в вызове trigger():

jQuery(document).bind('stuffHappened', function(event, msg) {
    alert('Что прозошло: ' + msg);
});
jQuery(document).trigger('stuffHappened', ['Привет!']);


Ненавязчивое (unobtrusive) программирование



Эта тема мне очень близка. Я по-прежнему верую в то, что лучшие веб-приложения — это те, которые могут функционировать и при отключенных скриптах, и лучшим методом для достижения этой цели будет ненавязчивый JavaScript, когда события назначаются элементам только после того, как вся HTML-страница у пользователя загрузится (для более подробной информации можно ознакомиться с ненавязчивым программированием и Hijax).

В jQuery присутствует замечательная поддержка этого подхода. Во-первых, парадигма селекторов для выбора узла является основополагающей как для jQuery, так и для ненавязчивого программирования в целом. Во-вторых, jQuery обеспечивает решения для проблемы window.onload, основанной на исследованиях Dean Edwards по поводу работы события «DOM loaded» для различных браузеров (прим.: подробнее о данной проблеме можно посмотреть в моем переводе, опубликованном ранее). Вы можете выставить функцию-обработчик тогда, когда DOM уже будет к ней готов:

jQuery(document).ready(function() {
    alert('DOM готов!');
});


И даже больше, вы можете сократить эту запись, назначив вашу функцию напрямую jQuery():

jQuery(function() {
    alert('DOM готов!');
});


jQuery и AJAX



У jQuery лучший API для работы с AJAX, который я когда-либо видел в больших библиотеках. Наиболее простая форма AJAX-вызова выглядит следующим образом:

jQuery('div#intro').load('/some/fragment.html');


Он выполнит GET-запрос к /some/fragment.html и вставит в div#intro HTML-код, который получит.

Первый раз, когда я это увидел, то не был сильно впечатлен. Всего лишь красивое сокращение, но если требуется что-то более сложное, например, вывести индикатор AJAX-загрузки? jQuery предоставляет набор собственных событий (ajaxStart, ajaxComplete, ajaxError и другие) для использования в случае необходимости. Также в этой библиотеки есть и более продвинутый API низкого уровня для сложных AJAX-взаимодействий:

jQuery.get('/some/script.php', {'name': 'Simon'}, function(data) {
    alert('Сервер ответил: ' + data);
}); // GET-запрос к /some/script.php?name=Simon

jQuery.post('/some/script.php', {'name': 'Simon'}, function(data) {
    alert('Сервер ответил: ' + data);
}); // POST-запрос к /some/script.php

jQuery.getJSON('/some.json', function(json) {
    alert('JSON выдал: ' + json.foo + ' ' + json.bar);
}); // Возвращает и преобразует ответ от /some.json как JSON

jQuery.getScript('/script.js'); // GET-запрос к /script.js и eval()


Расширения



Рассматривая весь этот набор функций в стандартной поставке, стоит заметить, что ужатый вариант jQuery занимает всего 20 КБ, и даже еще меньше, если применить архивирование (.gz). Дополнительная функциональность, выходящая за пределы это поставки, может быть организована с помощью расширений, которые могут (и так и делают) добавить новые методы к существующему объекту jQuery. При желании можно выполнить что-то вроде этого:

jQuery('p').bounceAroundTheScreenAndTurnGreen();


Механизм расширений в jQuery обеспечивает задокументированные методы для их добавления в систему. Простота и удобство их использования привлекли большое сообщество авторов таких расширений; справочник расширений насчитывает уже более ста примеров.

Еще одной приятной особенностью является возможность добавлять собственные селекторы так же, как и собственные методы. Расширение moreSelectors добавляет методы типа div:color(red), который, например, выбирает все div с красным текстом.

Пара слов о дырах



Изучая jQuery со все большим уважением, я столкнулся с одной философской проблемой. В течение последних лет я советовал знакомым работать с JavaScript-библиотекой, только если они хотят разобрать исходный код и посмотреть, как же он в действительности работает. Моя позиция основывалась на классической статье Joel Spolsky — Закон Обобщенных Дыр. В ней автор базируется на том факте, что чем сложнее ваше API, тем труднее будет исправлять ситуацию, когда в нем обнаружатся дыры. Браузеры одни из наиболее ненадежных приложений, поэтому будьте готовы рвать на себе волосы, когда столкнетесь с подобной ситуацией для вашего приложения, от которого все будет зависеть.

В определенных случаях jQuery использует поистине уникальные методы, чтобы добиться той или иной функциональности: некоторые части (например, исходный код селекторов) этой библиотеки выглядят устрашающе. Если вам так требуется понимание того, как работает библиотека, то jQuery для большинства разработчиков мало поможет с этой задачей. Однако, громадная популярность jQuery вкупе с определенным отсутствием плохих отзывов о ней, по-видимому, говорит только в ее пользу.

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

В качестве заключения



Надеюсь, я высказал достаточно фактов для положительного заключения по поводу jQuery: она не является очередной библиотекой. В ней заложена масса интересных идей, которые способны удивить даже достаточно опытных JavaScript-программистов и научить их чему-то новому. Даже если вы не будут использовать ее в своей работе, стоит посвятить некоторое время и исследовать «экосистему» jQuery.

Спасибо всем, кто ознакомился со статьей. Буду признателен за комментарии по теме.

Web Optimizator: проверка скорости загрузки сайтов
Автор оригинала: Simon Willison
Николай Мациевский @sunnybear
карма
331,0
рейтинг 20,0
Технический директор, Айри.рф
Похожие публикации
Самое читаемое Разработка

Комментарии (121)

  • 0
    Ненавячивое (unobtrusive) программирование
    Про статью. Не хочу я ничего использовать. Я подожду более standard-compliant решения.
    • 0
      можно подробнее, с какими проблемами вы столкнулись в попытке поработать с jquery? о соответствии каким стандартам идет речь?
    • 0
      Лет так через ...цать будет. Стандартизируеться всё настолько долго, что успевает устареть)
    • 0
      Пока на свете есть Microsoft, и он выпускает свой браузер, никакого standard-compliant решения не будет. Так что ждите, мы тоже будем молиться, и может когда-нибудь этот светлый день придёт.

      Но пока prototype и jQuery очень помогают. И автору поста респект!
  • 0
    Уважаемый автор, было бы очень приятно получить список ссылок по теме, для тех, кто не так сильно разбирается в JS, но для кого библиотека могла бы принести пользу: разработчики мелочей на ее основе.
    • +1
      На официальном сайте jQuery есть все необходимое: tutorials, docs and API (да, все только на английском).
      Все материалы очень качественные, простые и понятные. Единственное, что меня не совсем устраивает — это API. Поэтому испльзую jQuery API Browser от Bassistance. Но там только версия 1.1.2.
      • +1
        А! Совсем забыл. Есть еще прекрасная книга Learning jQuery: Better Interaction Design and Web Development with Simple JavaScript Techniques by Karl Swedberg and Jonathan Chaffer.
        Кому жалко $39.99, может скачать из p2p сетей. eMule ссылка.
        • 0
          Или с rapidshare.com
          • +1
            Пардон, ссылка не вставилась - http://rapidshare.com/files/53745381/Packt.Publishing.Learning.JQuery.Jul.2007.eBook-BBL.rar
            • 0
              Увы, ужё потёрли. Можете выложить на ifolder.ru ?
              • 0
                Ссылка на рапиде на месте.
                На ifolder - http://ifolder.ru/3249552
                • 0
                  Хм. У меня упорно кричит "File not found".

                  Спасибо за айфолдер!
      • 0
        Похожая реализация АПИ для 1.1.2 - Visual Jquery
  • 0
    Хорошая библиотека, давно использую — ненарадуюсь.
    В свое время отказался от многих, в том числе от Prototype, как от монстра гигантского.
    • 0
      А можно от вас узнать, хотя бы несколько доводов, чем jQuery лучше Prototype?
      Просто я уже некоторое время использую Prototype и в принципе доволен, но вот упоминание jQuery в последнее время встречаю всё больше и больше. Реально, в чем плюсы и минусы?
      Мне кстати показалось, что под jQuery написано больше различных приблуд чем под prototype, так ли это?
      • 0
        Размером (20Кб всего в сжатом виде), "мусором" в глобальном адресном пространстве - всего одна функция. Собственно размер был основным фактором ухода от Prototype.

        Плагинов разных также много.
        • 0
          По функциональности не уступает Prototype?
          • +2
            1 в 1 сопоставлять сложно, конечно, но я пока не нашел чего то такого, что мне не хватало в jQuery, но было в Prototype.
            • 0
              Я вот тоже долгое время используя Prototype всё поглядываю на jQuery. И что-то у меня с каждым разом крепнет подозрение что скоро перепрыгну. Мне кажеться, или в jQuery селекторы посильнее? Размер — это важно, конечно, тоже. 20 кб против почти 100 кб.
  • –2
    jQuery сейчас похожа на церковь, в которую с помощью дурацких примитивных примеров и не менее дурацких увещеваний "про простоту и уникальность" ласково и нежно завлекают прежде всего бедных и несчастных js-ньюбов. А заодно и тех, у кого при острой нехватке времени (или ещё чего) на js-программирование есть время на изучение неоднозначного псевдо-кода-от-дяди-джона, что очевидно проще. Остаётся только сожалеть, что вся эта страсть и энергия, доки и вижуал-апи, туториалы и семинары, и даже книжки не направлены в сторону изучения и пропаганды старого доброго J(ava)Script.
    • 0
      Не знаю кто и кого там завлекает, но если кто-то говорит вам, что jQuery можно пользоваться не зная JavaScript'а - то он откровенно лжет. Либо не оканчивает фразу. Ибо полностью она должна звучать так: jQuery можно пользоваться мало что зная про JavaScript - но только тогда, когда у вас есть знакомый, который вас спасёт когда эта очередная абстракция "протечёт"...

      Вообще же от любого хорошего программиста требуется некоторое понимание всех уровней в компьютере - начина от транзисторов и вверх. Не доскональное знание (этим не обладает никто), но ответить, скажем, на вопрос: почему современные видеокарты не могут использовать RayTracing (и никогда не смогут использовать его в качестве основоного инструмента) он должен уметь...
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          LOL. Ваши ответы типичны для программиста - уж можете мне поверить. На этом этапе разницы между плохим и хорошим программистом нет. Разница появляется если объяснить человеку как устроен RayTracing и предложить вспомнить хоть чего-нибудь про транзисторы :-) Понимать простые алгоритмы хороший программист должен уметь (уж извините), а некоторые базовые факты про них он на самом деле тоже знает - чего бы там он ни заявлял по первости. К примеру:

          - транзисторы - это такие маленькие элементики, которые могут быть в двух состояниях
          - количество бит на транзистор в разных видах памяти - попадает в интервал (1, 4] (хотя ответ (1, 10] - тоже годится; за знание того что в некоторых "необычных" видах памяти типа флеша может быть и больше одного бита на транзистор - дополнительный маленький плюсик)
          - транзисторов в современнем процессоре - сотни миллионов, но не миллиарды (ответ "десятки миллионов" - тоже годится, хотя он и не вполне верен)
          - при переходе из состояния в состояние транзисторы выделяют тепло (за замечание про то что без переходов они тоже выделяют тепло, но значительно меньше - дополнительный маленький плюсик)
          - транзисторы могут переключаться очень быстро - самые быстрые делают это за несколько пикосекунд

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

          А оценивать кандидатов мне приходится частенько (не знаю как где, но во всех местах где я работал последние несколько лет программист при приёме на работу должен переговорить не только с HR'ами, но и с программистами которые будут его коллегами). Оценивать же программиста "по работам" - очень сложно в современном мире ибо мало кто разрабатывает что-то "от" и "до" и я видел много случаев когда люди участвовали в интересных проектах, но занимались там рутиной и просто не обладают знаниями позволяющими поручить им самостоятельный проект - по возможности таких не следует принимать на работу... А людей у которых были интересные идеи, но которые по независящим от них причинам не довели их до ума - наоборот нужно брать...
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              А по-моему программисту постоянно приходиться изучать "не свои" области. В первую очередь хотя бы потому, что он пишет программы для людей, а потребности у этих людей — разные.

              А то, что вы не хотите углубляться в основы, вешаете ярлыки на людей, да ещё и не можете воспользоваться хотя бы виртуальной клавиатурой, чтобы людям удобнее было читать ваши мысли, говорит о вас не самым лучшим образом.
            • 0
              Вы где-то меня поймали: я никогда не занимался "webdev"'ом в стиле "давай-давай быстрей, лишь бы хоть как-то работало" - "бог миловал" пока. А серьезные разработки (когда QPS меряется десятками тысяч и борьба идёт за миллисекунды) оказались поразительно близки к тому чем я занимался раньше (драйвера, железки всякие). И вот как раз с этой точки зрения jQuery весьма и весьма неоднозначен. Для прототипов мы его иногда используем, но в реальных проектах - очень редко.

              Возможно для программистов которые не знают основ и существует где-то ниша (даже скорее всего существует - хороших программистов мало, а миллионы визжащих и прыгающих сайтов кто-то ведь должен делать), но это не повод "навешивать ярлыки" ходу...

              Что же касается умения "разбираться в риторике" - тут согласен, есть такое дело: я переливать из пустого в порожнее не умею. Вы тут уже много раз высказывали ничем не подкреплённую мысль что "всё, кроме оценки по работам - это субъективизм", но я не увидел ни строчки обоснований. Оценка по работам - ещё больший субъективизм, чем любая другая. Оценить "по работе" человека можно только тогда, когда он эту работу сделал сам "от и до", а если он что-то сделал "от и до" - то это значит что эта работа была небольшой - это уже тоже внисит субъективизм: сделать неплохую маленькую фитюльку и систему, которая будет 10'000 транзакций в секунду "тянуть" - это разные вещи. Конечно если кто-то руководил стоящей разработкой - то это чуть объективнее, но и тут всё не на 100% прозрачно: зачастую бывает что реально всё проектирование осушествляется вовсе даже не формальной главой проекта...

              Тоже касается и фреймворков: с помощью некоторых откровенно отстойных сделаны интересные проекты - но это самр по себе фреймворки не красит (конечно когда таких проектов много - это повод посмотреть на фреймворк и понять - он реально хорош или просто "в струю попал")...
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  Zeroglif написал грамотный комментарий. jQuery (как и большая часть других фреймворков) пытается обойти тот печальный факт, что JavaScript в большинстве browser'ов не поддерживает XPath. И, соответсвенно, использование jQuery провоцирует написание кода, который будет безумно тормозить. И вам всё равно придётся спускаться на уровень JavaScript'а (хорошо если не ниже).

                  Вроде бы самые вопиющие проблемы со скоростью в 1.1.4 поправили - но эта версия ещё слишком молода, чтобы её можно было рекомендовать всем и вся, а 1.1.2 - просто слишком медленная в большинстве случаев. Но даже и 1.1.4 нельзя и сравнить с прямым использованием JavaScript'а. По моему ниша jQuery досточно узка: его стоит использовать тогда когда в проект нужно что-то добавить "сбочку" без больших переделок движка. Ну и для прототипов/внутренних проектов, когда скорость разработки важнее качества результата. Но для внутренних разработок можно просто использовать имеющийся в Mozilla (и движках на основе Mozilla) XPath - и не мучиться ни с какими фреймворками!

                  P.S. Оценка способностей человека к выполнению работы по выполненной работе - это ни в каком смысле не замер "прямых показателей" (если это не ACM contest или TopCoder). Ибо стартовые условия в реальной жизни у всех - разные и они вносят подавляющий вклад в результат. Гораздо больший чем способности самого человека. Умение грамотно решать задачки - гораздо более прямой показатель, так как они гораздо меньше зависят от предистории: тябе обычно мало волнует кем был человек - куда важнее кем он стал, а людям свойственно меняться и, увы, не всегда в лучшую сторону... "Идеал объективности", конечно, недостижим, но стремиться к нему стоит...
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      www.миллион-других-сайтов.com - нет Prototype.js
                      чем не аргумент?
                      • НЛО прилетело и опубликовало эту надпись здесь
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Рядом просится список сайтов, не использующих jQuery.
                      • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            "Элементики, которые могут быть в двух состояниях" это триггеры. Так, к слову. Транзистор я (да и не только я) себе несколько иначе представляю (+ С другой стороны, конечно, в процессоре в качестве триггеров используются транзисторы.
            Вообще говоря, я с вами полностью согласен. Без понимания основ, самих принципов работы компьютера говорить о программировании даже на высоком уровне не приходится.
            • 0
              Транзисторы могут находиться в двух состояниях, триггеры могут хранить два состояния.

              На самом деле и то и другое - не совсем правда (бывают транзосторы, которые могут находиться более, чем в двух состояниях, хранить состояние может не только триггер, etc) - но это уже тонкости, которые редко бывают полезны...
              • 0
                а еще есть разные триггеры, S,D.
              • 0
                Если бы транзисторы могли находиться только в двух состояниях, то на них невозможно было бы делать аналоговые усилители. Может конечно кому-то аналоговые усилители и не полезны совсем, но это не повод придумывать всякое.
      • 0
        а почему они никогда не смогут использовать RayTracing
        • 0
          Вы убрали из фразы важную часть: "в качестве основного инструмента". Просто потому что скорость света 300'000 километров в секунду - и она "протечёт" через любые абстракции. Достаточно очень простого описания алгоритма RayTracing'а и очень приблизительного знания об устройстве видеокарты, чтобы понять что они не стыкуются: заставить современную видеокарту считать RayTracing можно (через шейдеры), только вот 90% времени (хорошо если не 99%) она будет простаивать... Если человек знает про то какие абстракции есть в видеокарте - с ним можно поговорить про то, где конкретно в них в этом случае образуются "утечки" (высокоуровневые интерфейсы в GPU вроде как ничем для RayTracing'а не страшны - проблемы "протекают" через "дыры в абстракциях" с самого низу: из физики).
          • 0
            Офигеть, такие детали должен знать каждый хороший программист? Я думаю нет. От программиста, пишушего 3д движки и подобные вещи? это можно требовать, но от программиста, например, специализирующегося на базах данных, сетях, паралелльном программировании, экспертных системах и т.п., требовать такое, ну уж извините, перебор. Такой программист сам кого хочет завалит на глубинных вопросах своей области. В том числе и вас.
            • 0
              Вы читать умеете ? Где я написал что он должен всё это знать ? Он должен "ответить на вопрос". А для этого знать нужно очень мало. Причём вещи которые очень тяжело не знать: то есть можно себе представить программиста, который никогда в жизни не видел рекламного объявления где реклимровалась бы видеокарта с "512-битным доступом в память" (384bit, 256bit - неважно, важно что много - много больше 32-64bit) или "с 48-конвеерами" (32 или даже 16 - опять-таки важно что много) - но это само по себе плохой показатель: это значит что человек не просто этим не интересуется (что нормально), но сознательно избегает даже тех знаний которые ему пытаются "втюхать"... А это значит - что он либо просто ничего не умеет делать, либо он - суперузкий специалист (а это в IT - равносильно смертному приговору если только вы не спец по Коболу).
              • 0
                Собственно основной постулат прост: хороший программист имеет рудиментарные познания про всё что лежит "под ним", но главное - он умеет думать. Хороший ворос - не вопрос, требущий глубинных знаний (для ответов на такие вопросы есть Yandex и Google), а вопрос, на который можно ответить зная лишь основопологающие принципы и имею голову на пречах. Знать основопологающие принципы в смежных областях - всегда полезно, а голова на плечах - она просто необходима...

                Как раз для людей "пишущих 3д движкии и подобные вещи" часто подобные проблемы оказываются сложнее, чем для "простых смертных". Они слишком много знают - и потому начинают мыслить с уровня шейдеров, ограничений в Cg и прочих высокоуровневых вещей - а там не так всё ужасно и вроде бы RayTracing должен бы быть возможен, но нет: "протекают" сюда (через все слои абстракций) весьма глубинные вещи, тесно связанные с законами физики, а не подробности GPU, с которыми обычно имеет дело "программист, пишущий 3д движки"...
              • +1
                > Где я написал что он должен всё это знать ? Он должен "ответить на вопрос". А для этого знать нужно очень мало.
                Я совершенно не принимаю такие словесные игры. Вы уж простите ... и прекращайте.

                Дальше все спорно, но версия имеет право на жизнь. Поехали. Сеть:
                - Почему не используют OSPF или EGMP для межпровайдерной маршрутизации?
                - Почему не может существовать сети с маской 255.255.255.224 и адресом сети 192.168.0.16 ?
                - Объясните как работает серверное приложение на базе конечного автомата и основные плюсы и минусы такого решения по сравнению с другими (какими?).
                Первый вопрос, думаю, того же уровня что и ваш. А вот второй и третий полегче будут ...
                • 0
                  - OSPF использует Дейкстру для того чтобы уравлять роутингом, так что возникают проблемы с ресурсами, но есть у него и другие проблемы. Хотя на самом деле главная проблема в том что просто когда вопрос встал то было проще перейти от IGP к BGP чем придумать реализацию OSPF, которая бы скалировалась на весь Internet. К тому же BGP легко позволяет врать (не передавать соседям полную информацию о своей связности) и он остается при этом работоспособен, а с OSPF это сложнее.
                  - EGMP ? Если вы от "Ethernet Group Membership Protocol" (никакого другого EGMP, увы, не знаю) - то у него вообще ограничений масса (прямо из названия понятно)...
                  - 192.168.0.18&~255.255.255.224=0.0.0.16, а должно быть 0 (хотя это хороший вопрос для админа, а не для программиста: чистый вопрос на знание)
                  - последнего вопроса не понял, но наверное имеется ввиду CISCO/NGINX/TUX vs Apache/MySQL ? в первом случае одна нить обрабатывает десятки заданий - для этого нужно представить обработку каждого запроса как конечный автомат и аккуратно следить за состояниями оного, во втором - одна нить обслуживает одного клиента. Первый вариант требует меньше ресурсов, но гораздо сложнее в написании и отладке (в случае сложных сервисов большой проблемой становится влияние разных запросов друг на друга).

                  Не вижу в чём проблема с вашими вопросами: 1й и 3й хорошие вопросы чтобы поговорить о них с пристрстием (там есть о чём поговорить), 2й - простой тест на знание TCP/IP (в принципе какое-то понятие о нём у программиста должно быть, хотя не знаю - насколько оно реально нужно: ЭТА деталь из TCP/IP "наверх" почти никогда "наверх" не протекает)...
                  • 0
                    2-й вопрос действительно из разряда теории построения сетей на основе стека протоколов TCP/IP, он для админа годиться.
                    А вот последний вопрос действительно интересный касаемый сетевого программирования и опять же взят из книжки Стивенса того же. Где рассматриваются реализации приложений многопоточных и однопроцессорных(fork)
                  • 0
                    Аббревиатуру EGMP я перепутал с [E]IGRP, сорри.
                    Ответы нормальные, придираться не буду.
          • 0
            А не могли бы вы объяснить ПОЧЕМУ Intel в своем Larabee будет использовать трасировку лучей (это же она? ) в качестве основного инструмента?

            Хоть по-моему понял — вы имели ввиду именно текущие видеокарты, но тем не менее это уж точно не то что надо знать программисту работающему где-нибудь в гугле и разрабатывающему поисковый движок или BigTable.
            • 0
              А не могли бы вы объяснить ПОЧЕМУ Intel в своем Larabee будет использовать трасировку лучей (это же она? ) в качестве основного инструмента?
              Могу. Легко. Потому что маркетологи не обладают знаниями необходимыми для того, чтобы понять что этого не может быть. Потому фраза «Larrabee настолько крут что может даже обрабатывать простые сцены методом трассировки лучей в режиме реального времени» переродилась в их сознании в «Larrabee будет в основном заточен под использование трассировки лучей». И этот бред растиражировали в сотнях изданий, так что даже увещевания разработчиков которые прямым текстом говорят, что без сомнения Larrabee — самая крутая железяка для трассировки лучей, которая у нас есть… но эта функция абсолютно не является фокусом разработки Larrabee — и никогда не была фокусом — даже на мгновенье… это всеми фанатами игнорируется. Потому что люди хотят верить в чудо. А чуда не случится пока не будет изменена работа с памятью — и притом серъёзно изменена. Этого Larrabee не обещает. И не может обещать — потому что разрабатывают его (насколько мне известно) неплохие разработчики — и они знают чего в природе бывает, а чего нет.
            • 0
              точно не то что надо знать программисту работающему где-нибудь в гугле и разрабатывающему поисковый движок или BigTable
              Если программист, работающий в Гугле и разрабатывающий движок или BigTable не может за 15 прикинуть на листке бумаги — где будет «узкое место» в алгоритме рейтрейсинга реализованного в Larrabee и чем всё это ограничится, то зря его взяли в эту команду. Ибо и там и там самая главная задача одна — понять сколько информации и как именно нам надо прокачать через систему и понять — пролезет эта информация туда или нет.
              • 0
                Отвечу почему мне не нравится вариант с трассировкой лучей — для нахождения узкого места данной технологии требуется знать как минимум знание физики. И уж точно оно для большинства не является требуемым.

                Да, кому-то нужно знание технологии вплоть до железа, НО не всем. и очень далеко не всем.

                Я не спорю, что хороший программист должен уметь прикинуть чтолибо, оценить итд. Но нестолько насколько это пишете вы. Так мне кажется.
      • 0
        Зачем, например, web-программисту нужно знать, как устроена видеокарта? Чем это знание полезней, чем география Австралии, например?
        Просто любое рациональное обоснование.
        • 0
          Да низачем, в общем-то. Но дело в том что для ответа на этот вопрос нужно знать два с половиной факта:
          1. Видеокарты используют очень широкую шину
          2. Видеокарты используют много параллельных конвееров для рассчёта 3D
          3. Видеопамять оптимизирована под большую пропускную способность и [относительно] большие задержки (во-первых это уже не так важно, а во-вторых можно догадаться про это из пункта 1)

          Положа руку на сердце: вы действительно этих фактов не знаете ? Это как с задачами про мячики для гольфа, блендеры, мосты и прочее: формально про свойства этих объектов вы знать ничего не должны, но если вы совсем ничего про них не знаете - это вызывает недоумение. То же и с видеокартой: чтобы ответить на вопрос про неё знать нужно очень мало - примерно столько сколько знает нормальный человпек, который ежедневно общается с компьютером или даже чуть меньше (более подробные знания устройства видеокарты, конечно, помогут, но они не нужны!!!)...
          • 0
            На самом деле первого предложения достаточно. Незачем - так незачем. (К вопросу о рейтресинге - а чем вышеприведенные факторы делают его невозможным? Я ежедневно общаюсь с компом, более того, когда-то интересовался рейтресингом как таковым.)
            На самом деле ваша идея правильна, но пример категорически не подходит. Нужно знать основной стек технологии, с которой работаешь, а также основы. Архитектура видеокарты - явно побочная ветвь.
            • 0
              Рейтрейсинг на мало-мальски сложных объектах приводит к достаточно случайным обращениям к разным частям модели. Против этого восстаёт вся "потоковая" организация видеокарты (да и современных CPU, если уж на то пошло: никогда не задумывались почему RayTracing считают на кластерах и никогда - на суперкомпьютерах?)... Да, некоторые приёмы могут снизить эту проблему - но в едва достаточной степени чтобы его можно было эффективно на CPU исполнять (и даже там латентность памяти частенько доминирует), а его архитектура куда менее "заточена" под потоковые исполнения...
              • 0
                я думаю нет смысла доказывать вебмастерам, что такое многопоточное, параллелизм и т.д. Если они желают предел в своей з.п в 1000$ то им это не надо
                • 0
                  Не много грубовато с вашей стороны. Так уж получилось, что по образованию я железячник(хотя и работаю вебпрограммером) и потому большую часть из примеров знаю. Но меня этому учили.
                  Я знаю людей которые в своей области то что называется Гуру. Именно за счет умения воспринимать новую информацию и умению правильно распределять свое время. Те знания которые вы считаете фундаментальными, у них если и есть то появлялись в основном из случайных источников.
                  ЗЫ: И зарплаты у них на много выше килобакса при проживание совсем не в столицы нашей родины.
                  ЗЫ2: Отсутствие каких то знаний с лихвой компенсируются умением быстро найти и применить. Инет рулит
    • +2
      Не понимаю почему вы думаете что фреймворк может избавить от необходимости знания языка, он просто избавляет от необходимости изобретать велосипед в каждом проекте и уменьшает количество кода (чем меньше кода тем проще написать и протестировать), к тому же позволяет использовать код протестированный армией программеров вместо своих велосипедов с кривыми колесами (выравнивание колес иногда требует больше усилий чем сам проект).

      Конкретно в JavaScript фреймворки избавляют от проблем кроссбраузерности, с одними событиями проблем куча и, к несчастью, не с ними одними.
    • 0
      Вот она "власть большинства". Человека, открывшего глаза многим программистам на истинное поведение ECMA и прочих script, минусует за совершенно обоснованный комментарий, сообщество js-непрофессионалов.
      Наверное все таки стоило привести пару примеров из кода jQuery
    • 0
      Ваше право не любить надстройки над "старым добрым J(ava)Script", но я, как серверный программер, ненавижу JScript, потому, что написанный код не работает одинаково во всех браузерах.
      Данную библиотеку склонен рассматривать, как базу знаний о различиях разных браузеров и буду использовать хотя бы для того, чтобы исключить разночтения(разноинтерпретации) моей программы.
      А по поводу псевдокода приведу контрпример: Был машинный код, появился ASM...
      После ASMа появился..., короче, дошло дело до JScript и на этом не остановится...
      • 0
        Не стоит мифологизировать или идеализировать кроссбраузерность фреймворков. Несмотря на то, что действительно фреймворки считают эту тему важнейшей и на неё упирают рогом в расчёте на свою универсальность, нельзя однозначно сказать, что фреймворки в этом вопросе ушли дальше не-фреймворков. Они приблизительно там же, где и все, кто пишет кроссбраузерно. Там нет марсианского кода, он не зашифрован энигмой, просто посмотрите на него, если вы программируете плотно на js, то все эти решения, только вид сбоку, вы уже должны были видеть раньше не-о-дно-кра-тно.

        Ничего не должно вам помешать воплотить кроссбраузерность самостоятельно в лучшем качестве, с оглядкой на свои задачи, без копирования местами слабого кода фреймворка. Это не изобретение велосипеда, если кто-то говорит про велосипед - это значит, что он знает про него всё, а если он знает всё, то должен видеть в любом фреймворке недостающие детали - педали, цепь, а иногда и колёса. В этом смысле лучше изобрести велосипед самому (не заново, а в первый раз) и обращаться при этом лучше к той же "базе знаний", откуда черпают свои решения и создатели фреймворков - к google.com ;) . Хотя, объективности ради нужно сказать, что изучение любой либы может быть полезным...

        Что касается псевдокода, то ваш контрпример я учёл, но он меня не разубедил, с jQuery это как-то не вяжется...
        • 0
          Вполне вяжется.

          jQuery вполне можно воспронимать как метаязык. Это как ассемблер по сравнению с машкодом.

          На первый взгляд это неочевидно, но после десятка проектов это становиться неоспоримым.
          • 0
            *становится
  • 0
    Эх в рельсах прототайп :(, так что жикуери придется пока обойдти стороной.
    • 0
      jquery в рельсах, хоть и без rjs, но работает без проблем
  • +1
    Очень интересная статья. Опечатка: "сокращение, н оесли".
  • 0
    тоже использую jquery на нашем сайте. в данный момент жду багфикса и нового релиза. есть определенно проблема с событием document.ready в IE, когда страница долго грузится из-за баннеров. альтернативного решения я пока не нашел =(
    • 0
      В MS IE через document.readyState можно отловить момент когда страница уже загружена, хотя картинки, может быть, и нет. В Firefox нужно ловить событие "DOMContentLoaded" (правда в ним не всё гладко: в некоторых случаях событие может посылаться до загрузки всей страницы если страница очень большая и очень долго грузится, так что нужно ввести дополнительную проверку - скажем завести переменную document.FullyLoaded перед тегом и отлавливать её инициализацию)...
      • 0
        у меня почему-то все наоборот. в ИЕ jQuery ждет когда все загрузится и не хочет работать до этого. У нас есть некоторые баннеры, которые почему-то в последнее время долго загружаются. Самое что интересно, не везде долго грузятся. Мы тестировали на разных машинах, каналах. Результат везде разный. в ФФ все нормально у всех.

        John Resig писал в гугл-группе что такой баг замечен, вроде пофиксили, но релиз ещё не вышел
  • +1
    ссылка "Вставить jQuery" в разделе "Чего-нибудь с ними делаем" битая.
  • 0
    Господа, а простейшую проверку для формы как самому нагородить с помощью этой библиотеки, все решения, которые находил - уж очень тяжёлые, ещё 2-3 лишних скрипта подключать, покажите пример, как, например, проверить email на валидность.
    • 0
      попробуйте гугль
      если не знаете что такое "регулярные выражения" будет повод узнать :)
      для поиска готового решения добавьте в поисковый запрос JS или JavaScript
      • 0
        Да нувас :) Про регулярные выражения я слышал, конечно, но самому что-то на них сделать - это не знаю, как надо постараться, "я в этом деле не копенгаген" (с), просто хотел бы видеть пример.
        • 0
          Посмотрите в plugins для форм. Там несколько готовых решений.
          • 0
            Вот про них я и говорил, что это вообще на 90% избыточные решения. А что, если начать с приведённой в статье обработки submit-a и раскраски поля password? Что дальше делать?
        • 0
          ай, глупости говорите. стараться не надо, надо не бояться :)
          с ними очень удобно работать, особенно если под рукой имеется regexBuddy и Expresso.
          а готовые решения в выдаче гугля тоже присутствуют, в том числе и на JS:
          http://javascript.internet.com/forms/ema…
          http://javascript.internet.com/forms/che…
          http://www.4guysfromrolla.com/webtech/05…

          ну и дальше по списку
          • 0
            Разъясните, пожалуйста, как приведённые вами примеры используют JQuery?
            • 0
              Никак ибо даже при наличии очень хорошей электрифицированной отвертки гвозди приходится вколачивать молотком...

              jQuery можно использовать для того чтобы вызвать в нужный момент валидатор - а собственно проверка она чисто на JS пишелся. Но все эти решения, которые создают framework для проверки форм вам кажутся слишком тяжёлыми...
            • 0
              >Господа, а простейшую проверку для формы как самому нагородить с помощью этой библиотеки,
              "ЭТОЙ" заметил только после Вашего вопроса. изначально прочитал с точностью до наоборот, т.е. просто - "простейшую проверку для формы"
              :"(
  • 0
    Засорение глобального адресного пространства? Видимо, при использовании нескольких разнородных библиотек в качестве базы (что есть извращенство).
    Вообще, кто-нибудь сталкивался с такой проблемой?
    • 0
      Знаете, совсем не обязательно извращенство.

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

      Использование нэймспейсов самый очевидный выход. И код, кстати, приобретает человекоупотребимый вид. Инкапсуляция — наше всё )
      • 0
        Я говорил о базовой функциональности — расширении ядрёных объектов, системных фичах. Ипользовать здесь несколько разнородных библиотек, какими бы хорошими они ни были, мне кажется странным и без напильника не выполнимым.
        Расширение остальной функциональности — пожалуйста. Хорошо разложенная по классам она вызывать проблем, вроде, не должна.
    • 0
      Это известная проблема. По-моему, об этом пишут даже в JavaScript Essentials book.

      На прагматичном уровне для меня засорение глобального пространства имён резко сказывается на производительности и на отладке.
  • 0
    отличная вводная статья
    http://www.rsdn.ru/article/inet/jQuery.xml
    она есть и на jquery.com
  • 0
    sunnybear, большое спасибо за отличную статью.

    С jQuery ещё не сталкивался, пользовался Mootools и немного Prototype (но отказался из-за большого размера и не слишком изящных решений), но сейчас очень хочу попробовать именно jQuery. Ряд решений выглядят действительно удобными и иновационными.
  • 0
    Использую jQuery вместе с prototype. prototype для работы с AJAX. А для jQuery написано множество готовых плагинов. По поводу размера - prototype можно ужать любой из js-ужималок до тех же 25-30kb. По скорости prototype по многим критериям превосходит и jQuery, и mootools. (Тест). Перешел бы полностью на jQuery, но как-то уж сильно привык к prototype.
    • 0
      Отличный тест! Скопировал себе локально (и добавил еще новый JQuery 1.2). Запускал в IE6, FF2 и Opera 9.

      jquery 1.2 очень немного не дотягивает по скорости к jquery 1.1.3.
      А вот что очент интересно, prototype и mootools лидируют в FF2 и O9 (отрываются на ~500 мс по сравнению с jquery 1.1.3)
      Зато jquery 1.1.3 лидирует в IE6 (и отрывается здесь на ~2,500 мс по сравнению с prototype и mootools!!!)

      Так что выходит что в среднем (взвешенном) по браузерам jquery лидер. А особенно учитывая долю IE на рынкею
    • 0
      Prorotype никак не превосходит jQuery. У нас в компании раньше использовали Prototype+Srcipt.aculo.us, и ничего, весь код спокойно переписывается на jQuery + plugins. Никаких невозможных для перевода частей не обнаружено, всё, наоборот, становится читаемей и компактнее - что просто удивительно. Причём переход происходит постепенно и быстро.

      В этом отношении большой респект jQuery.noConflict().
  • 0
    Не знаю, к чему вся эта демагогия была разведена. Моя веб-студия использует и джей квери, и мутулс, и прототайп. Все работает, клиенты довольны, мы тоже довольны. Конечно, можно было бы и без всего этого обойтись. Но без АЯКСА НИКУДА!!!

    Что касается именно jQuery - очень отлично-прекрасная штука, однозначно.
  • 0
    Одна вкусность, о которой умалчивается в статье: функцию jQuery(document).ready можно вызывать по нескольку раз на странице, при этом ничего не теряя.
    Очень удобно, если сборка страницы идет из нескольких шаблонов: для общих событий вставляем jQuery(document).ready в самом элементе HEAD в каком-нибудь header.tpl, а ниже вызываем её-же для событий конкретной страницы, index.tpl например.
    Помню до jquery по этому поводу приходилось извращаться вроде:

    document.onload = function(){
    document.onload();
    //еще действия
    }
    • 0
      Поясните, пожалуйста, смысл бесконечного рекурсивного вызова.
      Также, вы знакомы с DOM-моделью событий?
      • 0
        Тут ключевое слово не вызов, а переопределение. Поясняю:
        Например есть у нас необходимость на всех страницах сайта провести некоторые манипуляции, и, среди прочих, окрасить ссылки в синий цвет:

        document.onload = function(){
        //do stuff
        paintLinksBlue();
        //do more stuff
        }

        И, как всегда нежданно-негаданно, выясняется, что на новоиспеченной странице фотогалереи надо к ссылкам еще и атрибут rel добавить, а возможность залезть в изначальную onload уже нет. Поэтому переопределяем её, да так, чтоб не потерять исходный код (см. выше) Это примитивный пример. После 2-3 таких случаев, начинаем использовать addLoadEvent
        Так вот отсутствие этой необходимости в jquery очень порадовало меня лично. Насколько я помню в прототайпе годичной давности такого не было. Как (почему-то) не было и простейшей trim() и еще всяких мелочей. Как сейчас там обстоят дела, честно сказать, не знаю, уже более полугода кроме jquery ничем не пользуюсь.
        • 0
          Не знаю, есть ли такая вещь в этих мощнейших и широко разрекламированных фреймворках, но в обычном JS, это делается элементарно — addEventListener/attachEvent не затирают старый обработчик, а добавляют новый к списку уже существующих.
          Либо я опять не правильно понял...
  • –2
    в общем-то я использую Prototype, jQuery как работает себе представлял, но ни разу не использовал.
    сейчас вот прочел статью, спасибо sunnybear, и окончательно решил, что это не для меня.
    с jQuery JS это уже не JS. это даже не программирование, это составление приложения. Ну, что-то вроде Visual Basic... когда всё настолько заморочено, становится уже неинтересно.. сам процесс _поиска решения и его воплощения_ теряет смысл.. остается только прописать jQuery('bla').bla('bla') и т.д.. это скучно и однообразно.

    считаю, что главное отличие Prototype от jQuery в том, что первый не меняет _концепцию программирования_. Он не меняет меня самого, он просто избавляет меня от рутинной работы. Но когда я пишу и использую prototype, я чувствую, что пишу _я_, а мне помогают. А когда видишь, что делается с помощью jQuery, чувтствуешь, что ты не _пишешь_, ты _составляешь код_. я бы это назвал так. в общем для меня в программировании главное программирование, а поэтому пока не вижу для себя повода для использования этого фреймворка.
    Главное в Prototype - это набор полезных методов, по какой-то причине отстутствующих в JavaScript, которые раньше были точно такими же, но приходилось писать их замены самому, а теперь они все в лучшем виде собраны в отдельном .js-файле.
    А jQuery - это нечто большее, изменяющее сам JavaScript.. и я не уверен, нужно это или нет.
    • 0
      Кажется, Вы не поняли сути jQuery.
      Да и суть работы программиста тоже...
  • 0
    большое спасибо за статью!
  • 0
    интересует, а есть ли в jQuery обработчик события для input поля типа onblur или onchange?
    • 0
      • 0
        спасибо, посмотррел, только у меня с английским плохо, не могли бы вы дать мне примерчик
        • 0
          Вообще, в документации этой есть и примеры. Ну, вот, например:
          $(function(){
          $("#name").blur(function(){
          alert( $(this).val() );
          });
          });
          <input id="name" value=""/>
          Можно уточнить:
          $("input#name").…
          • 0
            большое спасибо
  • 0
    Возникла проблема.

    Есть xhtml


    <table class="t_des dtable" cellspacing="5">
    <tr>
    <th>Строка/Столбец</th>
    <th>Столбец 1</th>
    <th>Столбец 2</th>
    <th>Столбец 3</th>
    </tr>
    <tr>
    <td>Строка1</td>
    <td>1</td>
    <td>2</td>
    <td>3</td>
    </tr>
    </table>


    Нужно проитись по всем ht.

    Включаем js файл :
    $(document).ready(init);

    var init= new function (){
    create_d_table('dtable');
    }

    function create_d_table(class){
    $('table.'+class).css("background-color", "#000");;
    }


    В итог ошибка firebug

    f has no properties
    ready()jquery.js (line 27)
    ready()jquery.js (line 27)
    nodeName([function()], function(), undefined)jquery.js (line 20)
    ready()jquery.js (line 27)
    [Break on this error] jQuery.readyList.push(function(){return f.apply(this,[jQuery]);});return this;}}...
    • 0
      подозреваю, что основная проблема в вызове сторонних функций, ибо вот такой подход

      $(document).ready(function(){$('table.dtable').css("background-color", "#000")});

      срабатывает
    • 0
      Очень просто.
      var init = function() {
      create_d_table('dtable');
      }

      function create_d_table(class) {
      $('table.'+class).css("background-color", "#000");
      }

      $(document).ready(init);
  • 0
    Я с презрением отношусь ко всяческим либам, но почитав статью, думаю рискну и попробую jQuery. Спасибо!
    • 0
      Все, конечно, хорошо, библиотека удобная.

      НО! стоит помнить следующее:
      jQuery работает в IE начиная с версии 6 и выше.
      В 5 она не работает совсем.
      В 5.5 работает в неполной реализации. Например, там не работает ajax
      • 0
        Те кто пользуетс IE5.5 сами в этом виноваты :)
        • 0
          Это неправильная позиция.
          Продуманная библиотека должна поддерживать работу с распространенными браузерами, точнее говоря с версиями яваскрипт не только 1.5, но и 1.2
          Это не так уж и сложно.
          Прототайп, кстати говоря с IE 5.5 работает.
          • 0
            Если честно, то с прототайпом не работал. А от оЙгукн не хочу отказываться по причинами:
            1. Скорость написания скриптов по взаимодействию объектов сократилась в разы
            2. Хорошая документация, хотя ижаль, что нет свежей offline версии
            3. Большое быстропомогающее community, хоть и на английском языке, но все равно полезно

            А по поводу IE5.5 - это меньше половины процента от всех посетителей сайта
            http://clip2net.com/clip/m2737/1199349055-3a56c-12kb.png

            Так что, не вижу смысла подстраиваться под столь малое меньшинство. Хотя, конечно, если речь зайдет о написании какого-то скрипта для аудитории, которая сидит на этом диназавре, то напишем в меру технических возможностей.
            • 0
              >> жаль, что нет свежей offline версии

              Ну к 1.2.1 нету,
              но есть же к 1.1.2 http://jquery.bassistance.de/api-browser/
      • 0
        Пользователей E 5.x даже microsoft давно не принимает в расчёт (их сайты под ним не пашут корректно).

        Их доля меньше 2%.
  • 0
  • 0
    Сталкнулся с такой проблемой рпи использовании jQuery:

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


    Пример кода:

    $(".princip").click(function(){
    $("div.krug").find("img").animate({left: "0"}, 500) // — 1-е
    var largePath = $(this).attr("href");
    $("#plbg").attr({src: largePath}) // — 2-е
    $("#earth1").animate({left: "170"}, 1300) // — 3-е
    return false;
    });
    • 0
      у animate есть параметр callback — я думаю, стоит воспользоваться им
    • 0
      прочесть документацию jQuery относительно анимации и очередей анимации (dequeue etc.).
  • 0
    Спасибо огромное. Разрабатывая все более громоздкие системы приходит идея о переходе на какой-то фреймворк. Данная статья помогла мне определить на какой фрейм ворк все-таки перейти;) благодарю)добавил в избранное.
  • 0
    Вопрос по селекторам. Допустим, такой XML приходит от сервера в callback ф-ию ajax-овского get запроса:

    <?xml version="1.0" encoding="UTF-8"?>
    <accounts>
      <account id="1">
          <account id="2"/>
      </account>
      <account id="3"/>
    </accounts>
    

    Как выбрать элементы account, являющиеся непосредственными детьми ноды account? Т.е. id 1 и 3.

    Такой xpath не работает:
    function(xml) {
        elements = $("/accounts/account");
    }
    
    Хотя, должен бы. Как ни бился, не смог получить детей ни через xpath, ни через xss селекторы.

    Такой
    elements = $("account");
    возвращает все элементы account, т.е. id 1, 2 и 3.
    • 0
      C этим разобрался. Подходит CSS селектор «> account».
  • 0
    И ещё вопрос: callback ф-ии, переданные в ф-ию animate вызываются не после анимации, как всюду в документации написано, а перед ней. Это у всех так или я что-то не так делаю? Даже такой код:

    <div id="d1">Hi there!</div>
    <script>
      $("#d1").hide("slow").append(" Wow!").show("slow");
    </script>
    

    Сначала добавляет « Wow!», только потом скрывает div, и потом снова его показывает.
  • 0
    Респект автору давно искал такую статью!

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