jQuery изнутри — введение

  • Tutorial
По работе мне несколько раз приходилось участвовать в собеседовании кандидатов на должность клиент-сайдера у нас в компании, смотреть на их познания в Javascript. Удивительно что никто из них не знал толком как же работает jQuery изнутри, даже те, кто отметил свои знания jQuery уровнем «отлично», увы.

У jQuery очень низкий порог вхождения, о нем часто пишут и используют всюду, где только можно (и даже там, где, в общем-то, не нужно), поэтому некоторые даже не смотрят на чистый Javascript. Зачем, мол, его знать, когда есть jQuery, а по нему — тонны примеров и готовых плагинов? Даже на Хабре видел статью про рисование на Canvas, где автор подключил jQuery и использовал его только один раз — для того, чтобы получить доступ к Canvas по его идентификатору. И не считал это чем-то ненормальным.

Извините, отвлекся. Суть поста и следующих частей серии в том, чтобы рассказать о том, как же работает библиотека изнутри и что же в ней происходит по мере выполнения каких-то методов.

Исходники


Исходники проекта лежат вот тут. Все разбито на несколько модулей, собирается (у кого-то даже успешно) в одно целое с помощью Grunt. Для разбора в статье я буду использовать код последней стабильной версии (на момент написания статьи это — 1.8.3).

Образно, в этой статье мы рассмотрим скрипт, который можно получить склейкой intro.js. core.js, [sizzle] (мельком), sizzle-jquery.js, support.js (так же, мельком) и outro.js.

Скрипты intro.js и outro.js нужны просто чтобы обернуть код библиотеки в анонимную функцию, дабы не мусорить в window. В функцию передаются параметрами window и undefined (этот параметр — не передается, оттого и undefined). Зачем? У таких переменных не меняется названия в ходе минификации, а названия параметров функции — сжимаются и от таких манипуляций в итоге получается серьезный профит.

Инициализация


Первым делом при загрузке jQuery у нас отрабатывается core.js, ядро фреймворка. Что же происходит на этапе инициализации кроме объявления тонны использованных далее RegExp'ов и переменных:

Первым делом сохраняются ссылки на jQuery и его алиас $, в случае, когда они уже есть в window. Делается это на случай вызова функции noConflict, которая возвращает объект $ (а если в noConflict передан параметром true, то и jQuery) обратно на свое место, а в результате своей работы отдает нам jQuery, описанный уже в этом самом скрипте. Функция полезна, когда Вы планируете использовать свой код и jQuery на стороннем ресурсе и не хотите ничего поломать людям.

Создается локальная функция jQuery, которая и является своего рода «конструктором», которая принимает себе селектор и контекст. Функция, с которой разработчики и работают большую часть своего времени. Именно она будет в самом конце экспортирована в window.jQuery и window.$ (exports.js). Далее этот объект и будет расширяться, путем подмешивания в его прототип (jQuery.prototype, он же — jQuery.fn) дополнительных методов. Вышеупомянутый «конструктор», вызывает один из методов в jQuery.fninit, о нем чуть ниже.

Внимание, магия:
jQuery.fn.init.prototype = jQuery.fn
Именно поэтому из результата работы этого самого «конструктора» всегда можно достучаться до всех методов jQuery.

Собственно, jQuery.fn расширяется базовыми методами, среди которых jQuery.extend, с помощью которого осуществляется расширение объектов, в том числе и дальнейшее расширение функционала самого же jQuery.

Создается служебный хеш class2type, который необходим фреймворку для работы функции type и ее производных (isArray, isFunction, isNumeric и т.д.). Тут можно обратить внимание на особую магию — обычный typeof не очень удобен для определения некоторых типов переменных, поэтому в jQuery для этого и существует этот метод. Соответственно, и реализация его немножко отличается от обычного typeof.

Ну и напоследок, создается rootjQuery, переменная, в которой лежит результат выполнения jQuery(document), именно относительно него будут искаться элементы из init, если контекст не задан разработчиком напрямую.

Вроде бы все и относительно просто, но все это касается только core.js. Любой модуль что-то делает при загрузке и их лучше рассматривать отдельно. Отдельно упомянем support.js, в котором сразу же при инициализации проводится масса тестов для определения возможностей браузера.

Объект jQuery


Итак, что же представляет из себя объект jQuery и зачем?

Обычно результат работы $([какой-то селектор]) представляет собой примерно такой вот объект:

{
    0: Элемент,
    1: Элемент2,
    context: Элемент
    length: 2,
    selector: ‘тот самый какой-то селектор’
    __proto__: (как и писали выше, прототип у объекта - jQuery.fn)
}

Именно из-за свойства length многие почему-то заблуждаются и думают о том, что это — на самом деле массив. На самом деле свойство length поддерживается внутри jQuery вручную и является количеством возвращенных элементов, которые располагаются в нумерованных с нуля ключах-индексах объекта. Делается это именно за тем, чтобы с этим объектом можно было работать как с массивом. В свойство selector помещается строка-селектор, если мы искали по ней, а в context — контекст, по которому искали (если не задан, то он будет — document).

Запомните, что любая функция jQuery, которая не предназначена для возвращения каких-то специальных результатов, всегда возвращает объект, прототип которого — jQuery.fn, благодаря чему можно строить довольно большие цепочки вызовов.

jQuery.fn.init


Итак, что проиcходит, когда мы выполняем что-то вроде $([какой-нибудь селектор])? Внимательно читали? Правильно, вызовется тот самый «конструктор». Если быть точнее — нам вернется new jQuery.fn.init([тот самый селектор]).

Сначала в функции будет проверено, передан ли ей вообще селектор и в случае, если не передан (или передана пустая строка, null, false, undefined) — в этом случае нам вернется пустой объект jQuery, как если бы мы обратились к нему через window.$.

Затем будет проверено, является ли селектор — DOM-элементом. В этом случае jQuery вернет объект прямо с этим элементом. Пример с $(document.body):
{
    0: <body>,
    context: <body>,
    length: 1,
    __proto__: ...
}

В случае, если селектор является строкой, то относительно контекста (если контекста нет, то это — document, см. о rootjQuery выше) будет выполнен метод find указанного селектора, т.е.:
$('p', document.body) -> $(document.body).find('p')
$('p') -> rootjQuery.find('p')

В случае, если селектор представляет из себя что-то вроде #id, то для поиска элемента будет вызван обычный document.getElementById (привет, чувак с Canvas из начала статьи).

А вот если вместо селектора передается html-код (это определяется по наличию знаков открытия тега вначале строки и закрытия — в конце), jQuery попытается его распарсить (parseHTML, который мы рассмотрим в в следующей части более подробно) и на основе него создать эти элементы и результат вернуть уже с ними. Вот что мы получим в результате работы $('

Йо-хо-хо

я - на втором уровне')
:
{
    0: <h1>
    1: <p>
    length: 2
    __proto__: ...
}

Обратите внимание на span внутри параграфа — в результатах он тоже будет внутри него, в элементе с индексом 1.

Для случаев, когда вместо селектора на вход поступает функция, jQuery вызовет ее, когда документ будет готов к работе. Тут использованы promise, которым следует выделить отдельную главу. Многие зачем-то пользуются чуть более длинным аналогом — $(document).ready( callback ) (в комментариях говорят что так — более читабельно), но в итоге получается то же самое.

jQuery.find


Для поиска по документу в jQuery пользуется библиотека Sizzle, так что find, а так же методы expr, unique, text, isXMLDoc и contains либо напрямую ссылаются на соответствующие им методы из Sizzle, либо представляют простые методы-обертки над ними. Как работают селекторы в jQuery писалось уже неоднократно и на Хабре все это найти можно. В итоге работы find мы получим все тот же объект jQuery со всеми найденными элементами.

Отдельной строкой решусь сказать что ни jQuery, ни Sizzle не кешируют результаты работы метода find. Да и с чего бы им это делать? Не дергайте метод часто без нужды, если есть возможность заранее все найти — найдите и положите в отдельную переменную.

Если Вас чем-то не устраивает Sizzle, а такое бывает, вместо нее можно использовать что-то свое (или чужое), см. sizzle-jquery.js, именно там создаются ссылки на методы из Sizzle. Не забудьте в этом случае выкинуть Sizzle из билда.

Заключение


jQuery все растет и растет, уже сейчас библиотека разрослась почти до 10 тысяч строк кода (без учета Sizzle). Тем не менее исходники разбиты на несколько файлов, аккуратно написаны и даже местами прокомментированы. Не бойтесь подсматривать туда, а даже наоборот — если чувствуете, что не знаете как работает то, что Вы хотите использовать, не поленитесь посмотреть в исходники библиотеки. Это касается не только jQuery, но и вообще любой библиотеки.

Помните, что jQuery — это библиотека, цель которой не только облегчить разработчику жизнь лаконичностью кода, который получается с ее помощью, но и сделать один интерфейс для работы во всех возможных браузерах, включая доисторические, что добавляет определенный оверхед. Именно поэтому важно знать, что же делает за тебя библиотека. В некоторых случаях можно обойтись и без этих ста килобайт (помните что до сих пор видите значок Edge на своих телефонах) и без оверхеда на вызовах и тестировании возможностей браузера. К примеру, при написании расширения для Chrome или Firefox вам с вероятностью в 90% оно не принесет какого-то профита.

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

P.S. Как оказалось, на Хабре уже есть статья на эту тему от замечательного автора TheShockКак устроен jQuery: изучаем исходники. Свою статью оставляю потому, что кто-то уже добавил ее в избранное и вряд ли обрадуется надписи «статья помещена в черновики».

Содержание цикла статей


  1. Введение
  2. Манипуляции с DOM
  3. Атрибуты, свойства, данные
Метки:
  • +129
  • 92,9k
  • 80
Поделиться публикацией
Похожие публикации
Комментарии 80
  • –4
    О внутренностях jQuery уже писал кстати TheShock на хабре.

    А вообще предложите своим кандидатам написать свой jQuery. Причём весь, включая анимацию и ajax. (всякие дополнения вроде deferred или callbacks не нужно, движок css-селектором тоже не обязательно, можно Sizzle взять, другой какой или querySelectorAll). Такое задание здорово прокачивает (помимо прочего) знание js.

    > Именно из-за свойства length многие почему-то заблуждаются и думают о том, что это — на самом деле массив
    Подобных объектов в js много, например arguments.
    • 0
      Чорт. Автора знаю, а вот статьи его про jQuery не видел. У него лучше написано, прячу свой в черновик, спасибо.
      • +23
        Не надо, не прячьте!
        • 0
          Согласен с вами, не стоит убирать. Здесь просто написано более простым языком, для новичков самое то.
      • +2
        Добавил приписку вначале статьи, в черновик поздновато :[
        • +18
          Что-то жирное тестовое задание получится. Все-таки кандидат ищет работу, а не желает «прокачаться» :-)
          • –3
            Одно другому не мешает. Плюс я не уверен что комментатор имел ввиду предложение написать свой велосипед «здесь и сейчас»… Просто как совет для прокачки как раз таки.
            • +1
              > Все-таки кандидат ищет работу, а не желает «прокачаться»
              Ну тогда просто задайте вопрос — сможет ли он написать свой jQuery?.. Или хотя бы обойтись без него (и др. подобных фреймворков) в реальном проекте.
          • +2
            Я слышал, что в языке Dart нет необходимости использовать jQuery-подобные фреймворки. Не могли бы рассказать про это более подробно.
            • +3
              Я бы сказал что jQuery нужен только там, где нужна поддержка большого зоопарка разных браузеров (в том числе и старых). В новых браузерах необходимости в jQuery толком нет — все уже есть из коробки, просто чуть менее лаконично, чем в варианте с jQuery. Возможно, оттуда и такое мнение — Dart'а кроме как в последних версиях Chrome, по-моему, больше нигде нет :)
              Вообще, Dart, на мой взгляд, не взлетел и вряд ли взлетит.
              • 0
                А вот и более точный ответ на Ваш вопрос — github.com/theblacksmith/dQuery
                Раз пишут, значит хоть у кого-то в этом необходимость есть. Там, конечно, там какой-то совсем куцый функционал :)
                • 0
                  В стандартной библиотеке Dart есть «свой jQuery». Посмотрите здесь — в разделе «jQuery» (прямой ссылки не нашел, извините)
                  • +1
                    Если под «свой jQuery» выподразумеваете поиск по селекторам, работу с DOM и событиями, то у меня для Вас плохие новости — в обычном Javascript такое тоже можно делать! :)
                    • +1
                      Я знаю :) В обычном JavaScript тоже есть «свой jQuery» :)
                • +3
                  следующий код значительно улучшит восприятие статьи:
                  text = text.replace(', собственно,', '');
                  
                  • +23
                    Вы хотели остроумно пошутить, но ваш код заменит только первое вхождение подстроки.
                    • +20
                      В статье два упоминания. Возможно, он и хотел убрать только одно.
                      Убрал одно, надеюсь значительно помог :)
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • +18
                      Сводится до смешного


                      • +5
                        Искал сегодня этот топик, тоже не нашел. Плохо у меня сегодня с поиском :)
                        • –6
                          И с чувством юмора тоже.
                          • +2
                            Простите что задел.
                      • +3
                        Статья отличная, не удаляйте однозначно — всегда хорошо, когда есть несколько взглядов на одно и то же (несколько, а не десятки, как про прототипы! =) )

                        Статья вышла у меня не такая большая, как я боялся и это очень хорошо — читать будет легче (надеюсь). Следующая статья так и напрашивается и я ее напишу, если она будет востребована. О чем именно в первую очередь — можете подсказать.

                        Пишите обязательно)

                        Многие зачем-то пользуются чуть более длинным аналогом — $(document).ready( callback ), не знаю зачем, но в итоге получается совсем то же самое.

                        Слышал аргумент: так чётко, английским языком написано, что я хочу сделать, без всякой магии: "когда документ будет готов".
                        • +1
                          Спасибо, рад Вашему отзыву :)
                        • +3
                          Я, конечно, не супер-гуру и в анкетах на собеседованиях напротив jQuery ставил всегда 6/10. Но данная статья показалась мне невероятно познавательной. Например, я не знал, что $(document).ready( callback ) = $( callback ). Вернее я знал как работает короткий вариант, но не думал, что длинный вариант и короткий просто напросто идентичны! Сейчас начал более подробно разбираться в документации jQuery.
                          Знания — самый лучший подарок на НГ)
                          И пользуясь случаем, хочу поздравить всех уже почти с наступившем Новым Годом!)
                          Надеюсь в следущем году смогу с уверенностью ставить 7-ку на против пункта с jQuery.
                          • +2
                            Многие зачем-то пользуются чуть более длинным аналогом — $(document).ready( callback ), не знаю зачем, но в итоге получается совсем то же самое.

                            Потому, что так написано в первом попавшемся туториале на jquery.com от самого Джора Ресига.
                            • +3
                              (Ошибку в имени заметил уже после того, как истекло время редактирования комментария. Простите. Конечно, «Джона».)
                              • +1
                                Может быть потому что длина их беспокоит меньше читабельности?
                                • 0
                                  Сомнительный довод. Но если это так, то я только рад.
                              • +3
                                Я тут оставлю полезную ссылку для быстрого просмотра кода jQuery — лишним, думаю, не будет.
                                • 0
                                  Ну, на самом деле с большой вероятностью все методы ищутся по коду вот таким паттерном «methodName:», а прыгать туда-сюда по тому просмотрщику — вряд ли удобнее.
                                  Хотя, конечно, на вкус и цвет…
                                  • 0
                                    Ну как сказать — там переходы кликом, по всему упоминаниям, как в IDE ) так что вполне удобно.
                                • +2
                                  Это больше похоже на статью про внутренности, а про архитектуру, как-то поверхностно.
                                  • 0
                                    Как глубоко Вам бы хотелось чтобы я погрузился в описании?
                                    • +1
                                      Может быть я, как говориться, старой школы, и меня больше интересует архитектура, чем «внутренности», про которые можно всегда прочитать в справочнике (зачем все в голове держать), а вот схематика (алгоритм) архитектуры, должна быть в «голове». Так что достаточно будет «схематики» архитектуры.
                                  • +1
                                    Я бы пожалуй описал архитектуру jquery паттернами программирования. Тема второй части статьи=). Такое исследование даст «прокачку» новичкам и не только
                                    • +10
                                      По работе мне несколько раз приходилось участвовать в собеседовании кандидатов на должность клиент-сайдера у нас в компании, смотреть на их познания в JavaScript. Удивительно, что никто из них не знал толком, как же работает jQuery изнутри, даже те, кто отметил свои знания jQuery уровнем «отлично», увы.
                                      По работе мне несколько раз доводилось участвовать в собеседовании кандидатов на должность оператора ЭВМ у нас в компании, смотреть на их познания в Windows. Удивительно, что никто из них не знал толком, как же работает изнутри драйвер видеокарты nVidia GeForce GTX 690 — даже те, кто объявил об отличном знании Windows, увы.
                                      • +2
                                        Есть оператор, у которого должна быть инструкция, и есть программист у которого должно быть понимание.
                                        jQuery — он такой, без лазания в исходники можно наворотить материала на пару анекдотов.
                                        • +1
                                          Не, ну вы сами-то хоть знаете, как работает изнутри этот драйвер?
                                          • +1
                                            Да нет, не знаю.

                                            Более того: я никогда не читал исходный код jQuery целиком, и не буду читать до тех пор, пока я не найду в этой библиотеке ошибку или недостаток — иными словами, пока у меня не возникнет необходимость переменить её код и затем выслать её разработчикам pull request.

                                            Считаю, что пользователю jQuery (то есть программисту, использующему jQuery для веборазработки) достаточно прочесть документацию.

                                            Даже сочинение плагинов для jQuery проще освоить по пособию, нежели по исходному коду библиотеки.

                                            (Из всего кода jQuery я читал ровно столько, сколько необходимо для того, чтобы убедиться в том, какие глобальные переменные в jQuery используются.)

                                            И код Underscore.js я также не читал целиком, а просто использую согласно документации.

                                            (Из всего кода Underscore.js я читал ровно столько, сколько необходимо для того, чтобы уяснить разницу между функциями throttle и debounce в том случае, когда последний параметр debounce равен true.)

                                            И код Underscore.string я также не читал целиком, а просто использую согласно документации.

                                            А исходный код Chromium я даже и не скачивал (вон там один субъект объявил, кажется справедливо, что на одно лишь скачивание придётся потратить четырнадцать гигабайтов), а о прочитывании и речи нет.
                                            • 0
                                              Я тоже не читал исходный код jQuery целиком (и не призываю). Но мне интересно как что работает и я туда периодически поглядываю. Статья — для таких же, кому интересно.
                                          • +2
                                            Как ни странно, если пользователь написал что знает работу драйвера nVidia GeForce GTX 690 на отлично, значит его можно об этом спросить.
                                            Я не говорю о каких-то глубоких познаниях — в статье все не так и сложно, а на собеседованиях я просто в этом случае спрашиваю что-то вроде «что же получается, когда мы в консоли браузера набираем доллар, открываем кавычку, пишем селектор, закрываем кавычку и скобку и нажимаем enter». И не нужны мне в этот момент глубокие познания, а нужно понять, достаточно ли человек интересуется своей работой, чтобы хотя бы примерно представлять, что же произойдет, что не напишет всякой фигни, которая будет безбожно тормозить в проекте, которым пользуются миллионы.

                                            Рад получить комментарий от самого Мицгола, спасибо!
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                            • 0
                                              Некорректное сравнение. Исходники jQuery открыты, в отличие от исходников драйверов nVidia. Вследствие чего желающие разобраться, как изнутри работает драйвер видеокарты nVidia, вынуждены заниматься существенно более трудоёмким реверсингом как собственно драйвера, так и самой железки.
                                              • 0
                                                Ну, если строго говорить, в качестве ответа к вопросу Мицгола вполне подойдёт описание устройства nouveau, так как это драйвер указанной видеокарты.
                                                • –1
                                                  не подойдёт — в контексте упоминается виндавс
                                              • +1
                                                «Удивительно, что никто из них не знал толком, что происходит при запуске .exe файла — даже те, кто объявил об отличном знании Windows, увы.»

                                                fixed :)

                                                • 0
                                                  Знаете, я думаю, если программист в резюме пишет «Отличное знание Win.API», то он должен знать, что происходит при запуске .exe файла )
                                                  • +1
                                                    Речь шла всё же об операторе ЭВМ, о пользователе, но если он пишет, что отлично знает Windows, но даже «на пальцах» не может объяснить, что происходит при дабл-клике по екзешнику в Проводнике (хотя бы: екзешник копируется с диска в оперативную память и процессор начинает его исполнять), я бы усомнился в этом «отлично». Аналогично с фреймворками или библиотеками для программиста. Если он знает только внешние API, то максимум это хорошее знание, но не отличное — «уверенный пользователь ПК фреймворка».

                                                    А вообще, по-моему, если человек не интересуется устройством своих основных инструментов, то это говорит о его слабой мотивации в профессиональном росте.
                                              • +1
                                                Mithgol правильно говорит, на самом деле (хоть и утрирует).
                                                на Хабре видел статью про рисование на Canvas, где автор подключил jQuery и использовал его только один раз — для того, чтобы получить доступ к Canvas по его идентификатору. И не считал это чем-то ненормальным.

                                                Во-первых, автор же наверняка выдрал кусок из проекта, в котором уже есть jQuery. Во-вторых, я тоже не считаю это чем-то ненормальным. Более того, я даже считаю это правильным. Если завтра я улечу на месяц в отпуск, а ребята из, например, WebKit’а поломают получение канвы, костыль в CDN обновится быстрее, чем мой код.
                                                Отношение jQuery → Canvas — примерно такое же, как C → assembler. Можно (и нужно) писать современный код на C/jQuery, ибо уровни абстракции, меньшая зависимость от архитектуры ОС/браузера, и так далее. При этом, если рассматривать jQuery как язык, интерпретируемый в js, а не как библиотеку (что, если вдуматься, совершенно легитимно), то и ужас от того, что кто-то владеет jQuery, не понимая, во что он интерпретируется, — пройдет.

                                                Все вышесказанное, разумеется, относится исключительно к формулировкам и гиперболизации; никто не спорит, что лучше быть богатым и здоровым, чем бедным и больным, знание потрохов еще никогда никому не вредило.
                                                • +7
                                                  В статье было что-то вроде $('#canvas')[0].
                                                  document.getElementById никогда никто не отменит.

                                                  А жалуюсь я, в общем-то, просто на бездумное (ключевое слово) использование, на нежелание даже просто в консоли набрать console.dir( $('p') ) просто ради интереса, чтобы посмотреть, что же там вернулось.
                                                  • +2
                                                    В статье было что-то вроде $('#canvas')[0]

                                                    Мамадорогая. Беру свои слова обратно. Хотя, как обычно, SO виноват.

                                                    Я с вами-то согласен, в принципе. Но иногда лучше и безопаснее вызвать какой-нибудь метод доступа и забыть про многообразие браузеров, чем вникать в проблемы каждого недодвижка.
                                                    • 0
                                                      Да, поэтому я сам пользуюсь jQuery, но не стесняюсь посмотреть в исходники чтобы понять, как сделать что-то лучше. Я об этом писал в заключении.
                                                • +4
                                                  Я думаю, что будущие статьи стоит фокусировать на «Как знание внутренностей jQuery поможет мне в моих проектах». Т.е. более прикладной уровень. Ведь смысл хорошей библиотеки как раз в том, чтобы взять и использовать, не копаясь глубоко в ее исходниках.
                                                  • +1
                                                    Плюс к этому интересно было бы еще узнать в продолжение первого абзаца статьи числа из серии «Сколько подходящих кандидатов мы упустили, потому что они не знали как изнутри устроен JQuery».
                                                    • 0
                                                      Это — не главный критерий отбора, так что нисколько.
                                                      • +1
                                                        От прочтения статьи сложилось впечатление, что вы недоумеваете несколько от того, как много людей не знают устройства JQuery. Мне же кажется, что тут нет повода для недоумения. Вы же не расстраиваетесь от того, что повар не знаком с тем, что вообще такое огонь, на котором он готовит вашу яичницу или как холодильник генерирует холод. Для общего развития было бы полезно, конечно, но обязаловки я, честно говоря, тут не вижу. То есть меня несколько смутил тон вашей статьи.
                                                        • 0
                                                          У Вас некорректное сравнение. Повар и рецепт — вот хорошее сравнение, рецепт за него написали и ему нужно с помощью него сделать какое-то блюдо. Хороший повар если и пользуется чужими рецептами, то он сам знает, почему из этого рецепта получается то, что получается, а что в нем следует изменить, чтобы получилось еще лучше.
                                                          А удивляет в людях — простое отсутствие интереса :) Наличие его — жирный плюс на собеседовании.
                                                          • 0
                                                            Почему же некорректное. JQuery – это инструмент, и, если он работает настолько хорошо, что вам не требуется его разбирать – хвала такому инструменту. Огонь, на котором готовится еда – это инструмент тоже. А рецепт – это совсем не инструмент. По всей видимости в вашем привратном понимании роли JQuery в жизни разработчика и кроется причина вашего удивления.

                                                            Что же такое рецепт, если не инструмент, спросите вы. В переводе этой аллегории на язык программирования рецепт – это tutorial, это howto, программка hello world. Вот как она работает – знать конечно необходимо. Она и писалась-то для того, чтобы вы побуквенно изучили ее устройство. Как инструмент ее использовать даже и нельзя. Подозреваю, что хорошие повора кулинарные книги в гробу видали.

                                                            Фактически вы удивляетесь тому, что все люди разные. Я удивляюсь, чему вы удивляетесь :)
                                                            • 0
                                                              Огонь как инструмент — слишком низкий уровень и годился бы если бы я ожидал знания ассемблера или хотя бы внутренностей V8 :) С рецептом тоже не очень ок. Пусть будет кухонный комбайн :)

                                                              То, что люди разные — я не удивляюсь, а удивляюсь тому, что очень мало людей ничего не интересует.
                                                              • 0
                                                                Оговорка, извините :) Удивляет что таких людей слишком много
                                                                • 0
                                                                  Эти люди, о которых вы говорите, они просто не интересуются тем, чем интересуетесь вы. Наверное они интересуются чем-то другим. Это нормально. Ничего в этом удивительного нет.
                                                            • +2
                                                              Скажу как инженер общепита, сравнение правильное, и судя по даваемым знаниям в институтах повар общепита должен знать как холодильник генерирует холод…
                                                              • 0
                                                                Полезно, по крайней мере. А то ещё глядишь вздумает охладить помещение, открыв дверцу.
                                                            • +2
                                                              Вы же не расстраиваетесь от того, что повар не знаком с тем, что вообще такое огонь, на котором он готовит вашу яичницу или как холодильник генерирует холод

                                                              Сравнения, притянутые за уши — это всегда плохо и повод для холиваров. Базовое понимание устройства инструмента необходимо для программиста, который им пользуется. Тут и оптимизации своего кода и непонимание апи, возможные баги. У нас в приложении был баг, который закрался аж в веб-сервере. Если бы программисты совершенно не понимали устройства системы — это было бы печально.
                                                              Так само и здесь — базовое понимание просто необходимо. Плюс оно показывает, что человек не просто «кодер на результат», как описывали в соседней статье, а действительно интересуется тем, чем занимается.
                                                              • 0
                                                                Рассмотрите вашу ситуацию с позиции работодателя. Предположу, что он будет держать в штате одного ниндзю для таких проблем (а может и со стороны наймет на конкретную проблему) и 9 кодеров на результат, как вы выразились. Быть кодером на результат тоже не приговор, не вешайте штампов.

                                                                Вся суть вашего сообщения в неточной формулировке «базовое понимание». Если вы хотите сказать, что содержание данной статьи должно быть (подчеркиваю слово «должно») в голове каждого, кто пользуется JQuery – вы ошибаетесь.
                                                                • +2
                                                                  В англиском языке есть два варианта слова «должно» — «should» и «must». Вот я считаю, что такое базовое понимание должно («should») быть в голове каждого, кто пользуется jQuery.

                                                                  Быть кодером на результат тоже не приговор, не вешайте штампов

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

                                                                  Предположу, что он будет держать в штате одного ниндзю для таких проблем (а может и со стороны наймет на конкретную проблему) и 9 кодеров на результат, как вы выразились

                                                                  Зависит, конечно, от работодателя. У нас на предприятии не держат людей, которые не интересуются такими деталями. Даже в качестве Junior.
                                                                  • +1
                                                                    Я бы сказал, что оно должно быть в голове каждого, кто претендует на профессиональное использование jQuery, да ещё на отличном уровне. Никто, вроде, не требует знаний такого уровня от сервер-сайд программиста или верстальщика, которым изредка приходится заниматься не совсем своим делом (хотя это и может быть ощутимым плюсом при участии в конкурсе на должность при прочих равных), в том числе использовать jQuery. Но если человек претендует на должность фронтендера (не уровня «всему научим лишь бы человек хороший был»), да ещё ставит в резюме «отличное знание jQuery», то незнание подобных нюансов может стать большим минусом в конкурсе.

                                                                    И с позиции работодателя я бы предпочел иметь в команде пускай одного ниндзю и 9 кодеров, но чтобы эти кодеры имели внутреннюю мотивацию ниндзями стать, причем не по материальным или карьерным соображениям. А если они не интересуются своим основным инструментом, то наличие такой мотивации весьма сомнительно. На безрыбье, конечно, и рак рыба, но лучше я возьму на должность кодера того, кто, грубо говоря, эту статью хотя бы осилил прочитать, а не того, кто скажет «видел статью в ленте, но не читал — пока знания как оно работает внутри мне не требуются».
                                                                    • 0
                                                                      Вам легко рассуждать с позиции работодателя, т.к. судя по всему вы не очень хорошо понимаете эти позиции. В существенной степени они касаются бюджета. Какие у вас соображения по этому поводу? У нас еще впереди вопрос по мотивации, но сначала я бы хотел от вас про бюджет послушать.

                                                                      Ссылка для информации:
                                                                      en.wikipedia.org/wiki/Overqualified
                                                                      • 0
                                                                        Ветка понеслась с собеседования на должность с очень хорошей зарплатой
                                                                        • 0
                                                                          От того, что человек несколько раз заглянул в исходники фреймворка и примерно представляет, что внутри происходит, его зарплатные ожидания увеличиваться не должны
                                                                          • 0
                                                                            Хорошо. И второй вопрос. У вас есть 5 специалистов фронтендеров, которые знают как устроен JQuery (развитые такие ребята, интересуются всем) и 5 специалистов фронтендеров, которые не знают как устроен JQuery и не интересуются (т.к. для их задач в жизни им это никогда не требовалось).

                                                                            В силу специфики вашего предприятия, работа для всех у вас одинаковая. То есть знаний всех специалистов для этой работы достаточно. Вопрос, как вы думаете, специалисты из какой группы скорее начнут от вас сваливать (при прочих равных)?
                                                          • 0
                                                            Вообще не использую jQuery. Это плохо? Просто действительно смотрю так, везде его тулят, что у меня прям комплекс неполноценности возникает… Вы бы написали, когда его стоит использовать, а когда — нет.
                                                            • 0
                                                              А я упомянул в заключении.
                                                                • +1
                                                                  Его стоит использовать, когда он нужен. Если вы его держите ради одной-двух функций — не нужно, напишите их сами или подключите специальные микрофреймворки для этого.

                                                                  Небольшое отступление: на днях мне понадобился небольшой слайдер. Я уже пошёл искать плагин jQuery, но вспомнил муки с jScrollPane и махнул рукой на плагин — пошёл и написал его сам.

                                                                  Возвращаясь к случаям, когда не стоит юзать jQuery. Например, ради движка селекторов. Не смейтесь, часто jQ подключают только ради него. А нужно смотреть, в большинстве случаев достаточно querySelectorAll. А если вдруг почему-то недостаточно — Sizzle, Sly и ещё миллион движков селекторов. Или анимация. Если не можете написать сами или использовать css-transitions / animations — целая куча спец. микрофреймворков, например emile. И для ajax есть куча микрофреймворков.

                                                                  Нужно использовать jQuery только если вы постоянно его используете (причём сразу в нескольких направлениях — селекторы, анимация, удобный DOM, ajax...).
                                                                • +1
                                                                  Критерии использования практически такие же как и для любых сторонних библиотек/фреймворков. Если их использование позволяет значительно сократить время на разработку и(или) поддержку кода и, при этом, некритично увеличивает ресурсоемкость (скорость, память), то лучше использовать. Причём время на поддержку может быть куда важнее времени на разработку.

                                                                  Лично для меня три главных плюса jQuery — отсутствие (почти) необходимости поддерживать кроссбраузерность, большое количество готовых плагинов с единой архитектурой и поддерживаемых большим сообществом, и, как бы не самое важное, он является стандартом де-факто в индустрии — в код с использованием jQuery сферический новый разработчик «въедет» быстрее, чем при использование самописных библиотек или большого количества сторонних с разными API, разными способами работы и т. п.

                                                                  P.S. Упс, промахнулся.
                                                                  • 0
                                                                    Есть ощущение, что это не очень вдумчивый перевод и вот почему:
                                                                    эта — не передается, оттого и undefined


                                                                    не передается не эта, а this вообще-то
                                                                    • 0
                                                                      ( function(window, undefined) {
                                                                          ...
                                                                      }(window) );


                                                                      Наверное не очень хорошо выразился, поправлю, спасибо.
                                                                    • 0
                                                                      It can take a site a while to figure out that there's a problem with their 'report a bug' form.

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