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

[@Keyten]

О внутренностях jQuery уже писал кстати TheShock на хабре.

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

> Именно из-за свойства length многие почему-то заблуждаются и думают о том, что это — на самом деле массив
Подобных объектов в js много, например arguments.

[@return]

Чорт. Автора знаю, а вот статьи его про jQuery не видел. У него лучше написано, прячу свой в черновик, спасибо.

[@Evengard]

Не надо, не прячьте!

[@Keyten]

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

[@return]

Добавил приписку вначале статьи, в черновик поздновато :[

[@limon_spb]

Что-то жирное тестовое задание получится. Все-таки кандидат ищет работу, а не желает «прокачаться» :-)

[@antonydevanchi]

Одно другому не мешает. Плюс я не уверен что комментатор имел ввиду предложение написать свой велосипед «здесь и сейчас»… Просто как совет для прокачки как раз таки.

[@Keyten]

> Все-таки кандидат ищет работу, а не желает «прокачаться»
Ну тогда просто задайте вопрос — сможет ли он написать свой jQuery?.. Или хотя бы обойтись без него (и др. подобных фреймворков) в реальном проекте.

[@beduin01]

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

[@return]

Я бы сказал что jQuery нужен только там, где нужна поддержка большого зоопарка разных браузеров (в том числе и старых). В новых браузерах необходимости в jQuery толком нет — все уже есть из коробки, просто чуть менее лаконично, чем в варианте с jQuery. Возможно, оттуда и такое мнение — Dart'а кроме как в последних версиях Chrome, по-моему, больше нигде нет :)
Вообще, Dart, на мой взгляд, не взлетел и вряд ли взлетит.

[@return]

А вот и более точный ответ на Ваш вопрос — github.com/theblacksmith/dQuery
Раз пишут, значит хоть у кого-то в этом необходимость есть. Там, конечно, там какой-то совсем куцый функционал :)

[@MuLLtiQ]

В стандартной библиотеке Dart есть «свой jQuery». Посмотрите здесь — в разделе «jQuery» (прямой ссылки не нашел, извините)

[@return]

Если под «свой jQuery» выподразумеваете поиск по селекторам, работу с DOM и событиями, то у меня для Вас плохие новости — в обычном Javascript такое тоже можно делать! :)

[@MuLLtiQ]

Я знаю :) В обычном JavaScript тоже есть «свой jQuery» :)

[@gro]

следующий код значительно улучшит восприятие статьи:

text = text.replace(', собственно,', '');

[@zimorodok]

Вы хотели остроумно пошутить, но ваш код заменит только первое вхождение подстроки.

[@return]

В статье два упоминания. Возможно, он и хотел убрать только одно.
Убрал одно, надеюсь значительно помог :)

[@TheShock]

Сводится до смешного

[@return]

Искал сегодня этот топик, тоже не нашел. Плохо у меня сегодня с поиском :)

[@empr]

И с чувством юмора тоже.

[@return]

Простите что задел.

[@TheShock]

Статья отличная, не удаляйте однозначно — всегда хорошо, когда есть несколько взглядов на одно и то же (несколько, а не десятки, как про прототипы! =) )

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

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

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

Слышал аргумент: так чётко, английским языком написано, что я хочу сделать, без всякой магии: "когда документ будет готов".

[@return]

Спасибо, рад Вашему отзыву :)

[@zBit]

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

[@merlin-vrn]

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

Потому, что так написано в первом попавшемся туториале на jquery.com от самого Джора Ресига.

[@merlin-vrn]

(Ошибку в имени заметил уже после того, как истекло время редактирования комментария. Простите. Конечно, «Джона».)

[@zelibobla]

Может быть потому что длина их беспокоит меньше читабельности?

[@return]

Сомнительный довод. Но если это так, то я только рад.

[@creage]

Я тут оставлю полезную ссылку для быстрого просмотра кода jQuery — лишним, думаю, не будет.

[@return]

Ну, на самом деле с большой вероятностью все методы ищутся по коду вот таким паттерном «methodName:», а прыгать туда-сюда по тому просмотрщику — вряд ли удобнее.
Хотя, конечно, на вкус и цвет…

[@mapron]

Ну как сказать — там переходы кликом, по всему упоминаниям, как в IDE ) так что вполне удобно.

[@maxic]

Это больше похоже на статью про внутренности, а про архитектуру, как-то поверхностно.

[@return]

Как глубоко Вам бы хотелось чтобы я погрузился в описании?

[@maxic]

Может быть я, как говориться, старой школы, и меня больше интересует архитектура, чем «внутренности», про которые можно всегда прочитать в справочнике (зачем все в голове держать), а вот схематика (алгоритм) архитектуры, должна быть в «голове». Так что достаточно будет «схематики» архитектуры.

[@freeart]

Я бы пожалуй описал архитектуру jquery паттернами программирования. Тема второй части статьи=). Такое исследование даст «прокачку» новичкам и не только

[@Mithgol]

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

По работе мне несколько раз доводилось участвовать в собеседовании кандидатов на должность оператора ЭВМ у нас в компании, смотреть на их познания в Windows. Удивительно, что никто из них не знал толком, как же работает изнутри драйвер видеокарты nVidia GeForce GTX 690 — даже те, кто объявил об отличном знании Windows, увы.

[@Wott]

Есть оператор, у которого должна быть инструкция, и есть программист у которого должно быть понимание.
jQuery — он такой, без лазания в исходники можно наворотить материала на пару анекдотов.

[@merlin-vrn]

Не, ну вы сами-то хоть знаете, как работает изнутри этот драйвер?

[@Mithgol]

Да нет, не знаю.

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

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

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

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

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

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

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

А исходный код Chromium я даже и не скачивал (вон там один субъект объявил, кажется справедливо, что на одно лишь скачивание придётся потратить четырнадцать гигабайтов), а о прочитывании и речи нет.

[@return]

Я тоже не читал исходный код jQuery целиком (и не призываю). Но мне интересно как что работает и я туда периодически поглядываю. Статья — для таких же, кому интересно.

[@return]

Как ни странно, если пользователь написал что знает работу драйвера nVidia GeForce GTX 690 на отлично, значит его можно об этом спросить.
Я не говорю о каких-то глубоких познаниях — в статье все не так и сложно, а на собеседованиях я просто в этом случае спрашиваю что-то вроде «что же получается, когда мы в консоли браузера набираем доллар, открываем кавычку, пишем селектор, закрываем кавычку и скобку и нажимаем enter». И не нужны мне в этот момент глубокие познания, а нужно понять, достаточно ли человек интересуется своей работой, чтобы хотя бы примерно представлять, что же произойдет, что не напишет всякой фигни, которая будет безбожно тормозить в проекте, которым пользуются миллионы.

Рад получить комментарий от самого Мицгола, спасибо!

[@merlin-vrn]

Ну, если строго говорить, в качестве ответа к вопросу Мицгола вполне подойдёт описание устройства nouveau, так как это драйвер указанной видеокарты.

[@VolCh]

«Удивительно, что никто из них не знал толком, что происходит при запуске .exe файла — даже те, кто объявил об отличном знании Windows, увы.»

fixed :)

[@TheShock]

Знаете, я думаю, если программист в резюме пишет «Отличное знание Win.API», то он должен знать, что происходит при запуске .exe файла )

[@VolCh]

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

А вообще, по-моему, если человек не интересуется устройством своих основных инструментов, то это говорит о его слабой мотивации в профессиональном росте.

[@matiouchkine]

Mithgol правильно говорит, на самом деле (хоть и утрирует).

на Хабре видел статью про рисование на Canvas, где автор подключил jQuery и использовал его только один раз — для того, чтобы получить доступ к Canvas по его идентификатору. И не считал это чем-то ненормальным.

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

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

[@return]

В статье было что-то вроде $('#canvas')[0].
document.getElementById никогда никто не отменит.

А жалуюсь я, в общем-то, просто на бездумное (ключевое слово) использование, на нежелание даже просто в консоли набрать console.dir( $('p') ) просто ради интереса, чтобы посмотреть, что же там вернулось.

[@matiouchkine]

В статье было что-то вроде $('#canvas')[0]

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

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

[@return]

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

[@vitalets]

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

[@zelibobla]

Плюс к этому интересно было бы еще узнать в продолжение первого абзаца статьи числа из серии «Сколько подходящих кандидатов мы упустили, потому что они не знали как изнутри устроен JQuery».

[@return]

Это — не главный критерий отбора, так что нисколько.

[@zelibobla]

От прочтения статьи сложилось впечатление, что вы недоумеваете несколько от того, как много людей не знают устройства JQuery. Мне же кажется, что тут нет повода для недоумения. Вы же не расстраиваетесь от того, что повар не знаком с тем, что вообще такое огонь, на котором он готовит вашу яичницу или как холодильник генерирует холод. Для общего развития было бы полезно, конечно, но обязаловки я, честно говоря, тут не вижу. То есть меня несколько смутил тон вашей статьи.

[@return]

У Вас некорректное сравнение. Повар и рецепт — вот хорошее сравнение, рецепт за него написали и ему нужно с помощью него сделать какое-то блюдо. Хороший повар если и пользуется чужими рецептами, то он сам знает, почему из этого рецепта получается то, что получается, а что в нем следует изменить, чтобы получилось еще лучше.
А удивляет в людях — простое отсутствие интереса :) Наличие его — жирный плюс на собеседовании.

[@zelibobla]

Почему же некорректное. JQuery – это инструмент, и, если он работает настолько хорошо, что вам не требуется его разбирать – хвала такому инструменту. Огонь, на котором готовится еда – это инструмент тоже. А рецепт – это совсем не инструмент. По всей видимости в вашем привратном понимании роли JQuery в жизни разработчика и кроется причина вашего удивления.

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

Фактически вы удивляетесь тому, что все люди разные. Я удивляюсь, чему вы удивляетесь :)

[@return]

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

То, что люди разные — я не удивляюсь, а удивляюсь тому, что очень мало людей ничего не интересует.

[@return]

Оговорка, извините :) Удивляет что таких людей слишком много

[@zelibobla]

Эти люди, о которых вы говорите, они просто не интересуются тем, чем интересуетесь вы. Наверное они интересуются чем-то другим. Это нормально. Ничего в этом удивительного нет.

[@freeart]

Скажу как инженер общепита, сравнение правильное, и судя по даваемым знаниям в институтах повар общепита должен знать как холодильник генерирует холод…

[@merlin-vrn]

Полезно, по крайней мере. А то ещё глядишь вздумает охладить помещение, открыв дверцу.

[@TheShock]

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

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

[@zelibobla]

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

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

[@TheShock]

В англиском языке есть два варианта слова «должно» — «should» и «must». Вот я считаю, что такое базовое понимание должно («should») быть в голове каждого, кто пользуется jQuery.

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

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

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

Зависит, конечно, от работодателя. У нас на предприятии не держат людей, которые не интересуются такими деталями. Даже в качестве Junior.

[@VolCh]

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

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

[@zelibobla]

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

Ссылка для информации:
en.wikipedia.org/wiki/Overqualified

[@return]

Ветка понеслась с собеседования на должность с очень хорошей зарплатой

[@VolCh]

От того, что человек несколько раз заглянул в исходники фреймворка и примерно представляет, что внутри происходит, его зарплатные ожидания увеличиваться не должны

[@zelibobla]

Хорошо. И второй вопрос. У вас есть 5 специалистов фронтендеров, которые знают как устроен JQuery (развитые такие ребята, интересуются всем) и 5 специалистов фронтендеров, которые не знают как устроен JQuery и не интересуются (т.к. для их задач в жизни им это никогда не требовалось).

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

[@agentx001]

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

[@return]

А я упомянул в заключении.

[@VolCh]

habrahabr.ru/post/164433/#comment_5659369

[@Keyten]

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

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

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

Нужно использовать jQuery только если вы постоянно его используете (причём сразу в нескольких направлениях — селекторы, анимация, удобный DOM, ajax...).

[@VolCh]

Критерии использования практически такие же как и для любых сторонних библиотек/фреймворков. Если их использование позволяет значительно сократить время на разработку и(или) поддержку кода и, при этом, некритично увеличивает ресурсоемкость (скорость, память), то лучше использовать. Причём время на поддержку может быть куда важнее времени на разработку.

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

P.S. Упс, промахнулся.

[@vitkon]

Есть ощущение, что это не очень вдумчивый перевод и вот почему:

эта — не передается, оттого и undefined

не передается не эта, а this вообще-то

[@return]

( function(window, undefined) {
    ...
}(window) );

Наверное не очень хорошо выразился, поправлю, спасибо.

[@brammator]