Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Автор, вы много написали JSa, который работает в браузере?
По мимо IE, есть и другие браузеры, у которых есть баги и то что работает в Chrome, может по другому работать в Firefox.
По этому абстракцию нужна. Но уже более тонкая.
Я согласен что jQuery это очень тяжелая библиотека для этого, но она уже привычна. Брать AtomJS (как пример) и учить его, лишь из-за того что не нужна поддержка старых браузеров?
Я предпочту узкие места написать на нативном жс, чем писать всё на нативе и в будущем вылавливать фиче-баги.
Пока браузеры пишет с дюжина компаний, веб не лишиться вот таких вот медленных, но очень надежных абстракций.
По мимо IE, есть и другие браузеры, у которых есть баги и то что работает в Chrome, может по другому работать в Firefox.
По этому абстракцию нужна. Но уже более тонкая.
Я согласен что jQuery это очень тяжелая библиотека для этого, но она уже привычна. Брать AtomJS (как пример) и учить его, лишь из-за того что не нужна поддержка старых браузеров?
Я предпочту узкие места написать на нативном жс, чем писать всё на нативе и в будущем вылавливать фиче-баги.
Пока браузеры пишет с дюжина компаний, веб не лишиться вот таких вот медленных, но очень надежных абстракций.
На данный момент использую ООП и MVC подход в программировании интерфейсов на js, и проблем с описанием классов не наблюдается, все браузеры это делают одинаково.
Однако, согласен, баги имеют место быть, но в современных браузерах, эти отличия составляют по большей части разницу в API и решаются парой строк кода или парой условий. В отличии от старых IE/Opera с различными причудами по добавлению эвентов и ajax запросов и др.., где действительно необходимы эти абстракции, вот только речь идет про jQuery 2.0, в котором абстракции стали просто обертками для общих, нативных методов браузера.
Однако, согласен, баги имеют место быть, но в современных браузерах, эти отличия составляют по большей части разницу в API и решаются парой строк кода или парой условий. В отличии от старых IE/Opera с различными причудами по добавлению эвентов и ajax запросов и др.., где действительно необходимы эти абстракции, вот только речь идет про jQuery 2.0, в котором абстракции стали просто обертками для общих, нативных методов браузера.
var r = new XMLHttpRequest();
r.open("GET", "http://habrahabr.ru/", true);
r.onreadystatechange = function () {
if (r.readyState != 4 || r.status != 200) return;
// Профит?
};
r.send();var s = document.getElementById('thing').style;
s.opacity = 1;
(function fade(){(s.opacity-=.1)<0?s.display="none":setTimeout(fade,40)})();var $ = document.querySelectorAll.bind(document)
// для браузеров, поддерживающих bind или самостоятельно написанный bind(пара строк кода)Все эти чудесные парни рано или поздно уйдут на другую работу и возьмут им на замену Ваню (гигантище человек, соль земли, без преувеличения). Посмотрит Ваня на сайт, а там — анимация тормозит, JSONP в Опере 12 не работает, в ИЕ11 очередной баг, проявляющийся только при убывающей луне в четный четверг… Что подумает Ваня о своих чудесных предшественниках, открыв код, я здесь привести не могу, ибо за мат и эвфемизмы забирает НЛО.
Давайте я расскажу вам другую историю об этих героях.
Устраивается Петя на работу в аутсорс фирму, красочное резюме, знает множество технологий среди которых не малое место отведено js и jquery.
Ему дают свежий проект и ставят задачи, а сделай ка нам автокомплит. Петя программист умный и знает отличный плагин для jq, погуглив, покликав примеры, прикручивает он его к проекту, благополучно притянув в зависимостях одну из версий jquery. И разместив нужную запись в main.js:
$('.autocmoplete').autocomplete({...})
За это его ругать не стоит, вещь не из самых простых для начинающих.
На этом начальство не остановилось и просит сделать драг & дропы, Петя не долго думая вспоминает что для этого есть плагин jquery ui. Но зачем останавливаться на drag & drop, прикручивает Петя весь jquery ui в проект и использует d&d в одном месте.
Время идет в помощь Пете компания нанимает еще одно программисту Колю, Коля тоже «хороший знаток» javascript и с радостью помогает решать поставленные задачи Пете.
Таски все интереснее: добавить слайдеры, скролеры, карусели, зумеры, табы, дейтпикеры, маски… и еще с пару дюжин полезностей и красивостей, для которых 2 молодых программиста используют плагины для jquery.
Местами возникают конфликты с версиями jquery, что они решают подключением различных версия, для разных нужд.
А потом у двух программистов возникает идея, «мы такие умные и хорошие программисты», давайте сделаем SPA приложение. Подключают для этого Backbone который тащит дополнительно и underscore.
Бравые ребята ныряют с головой в разработку, прокачивают свои «скилы». Но никакой отдачи от начальства ни повышений? ни поощрений и они увольняются, перейдя в другую компанию на более высокие оклады, они же уже еще и в one page «разбираются».
Пользователи сайта начинают жаловаться на глюки и тормоза сайта на планшетах/телефонах, да и на нетбуках…
Компания в отчаянии, потеряли 2 хороших сотрудников работающих над проектом.
Проект у них очень хороший и сложный, а главное там много javasctipt, о чем они не забывают указать в вакансии и на собеседовании новому сотруднику Ване, рассказав что у них крутое SPA приложение и вообще работы завались и как все будет круто, интересно, а главное весело и познавательно.
Ваня хороший программист, отлично учился в универе, на профессиональном уровне освоил javascript на предыдущей работе, разбирается во многих его особенностях, отлично знает концепции многих фреймворков, из-за чего начал искоса поглядывать на jquery… он мог бы писать сам jquery, внося свой вклад в развитие фреймворка, но ему это просто не интересно, а концепция и политика jquery не внушает доверия.
И вот первый рабочий день Ваня скачивает проект и что он видит? Горы jquery плагинов, наскоро прикрученный на все Backbone, который еще вовсе не работает как SPA, в сочетании с кучей непонятной фигни. Ваня отлично знает javascript и разобраться с плагинами(на этот момент уже устаревшими, как и версия jquery) для него не представляет труда. Заглядывает в main.js файл в котором видит лишь
$('.date').datepicker()
$('#slider').slider()
$('.photo').zoom()
…
и так строк 50
и еще с десяток вспомогательных файлов, с синтаксисом, как в статей (про next), а также скрытыми вызовами прямо на вьюхах.
Ваня чувствует себя обманутым, ведь вместо крутого SPA приложения на javascript, получил кучу плагинов jquery.
Так что же теперь думает Ваня о своих чудесных предшественниках? и считает ли он их программистами?
Устраивается Петя на работу в аутсорс фирму, красочное резюме, знает множество технологий среди которых не малое место отведено js и jquery.
Ему дают свежий проект и ставят задачи, а сделай ка нам автокомплит. Петя программист умный и знает отличный плагин для jq, погуглив, покликав примеры, прикручивает он его к проекту, благополучно притянув в зависимостях одну из версий jquery. И разместив нужную запись в main.js:
$('.autocmoplete').autocomplete({...})
За это его ругать не стоит, вещь не из самых простых для начинающих.
На этом начальство не остановилось и просит сделать драг & дропы, Петя не долго думая вспоминает что для этого есть плагин jquery ui. Но зачем останавливаться на drag & drop, прикручивает Петя весь jquery ui в проект и использует d&d в одном месте.
Время идет в помощь Пете компания нанимает еще одно программисту Колю, Коля тоже «хороший знаток» javascript и с радостью помогает решать поставленные задачи Пете.
Таски все интереснее: добавить слайдеры, скролеры, карусели, зумеры, табы, дейтпикеры, маски… и еще с пару дюжин полезностей и красивостей, для которых 2 молодых программиста используют плагины для jquery.
Местами возникают конфликты с версиями jquery, что они решают подключением различных версия, для разных нужд.
А потом у двух программистов возникает идея, «мы такие умные и хорошие программисты», давайте сделаем SPA приложение. Подключают для этого Backbone который тащит дополнительно и underscore.
Бравые ребята ныряют с головой в разработку, прокачивают свои «скилы». Но никакой отдачи от начальства ни повышений? ни поощрений и они увольняются, перейдя в другую компанию на более высокие оклады, они же уже еще и в one page «разбираются».
Пользователи сайта начинают жаловаться на глюки и тормоза сайта на планшетах/телефонах, да и на нетбуках…
Компания в отчаянии, потеряли 2 хороших сотрудников работающих над проектом.
Проект у них очень хороший и сложный, а главное там много javasctipt, о чем они не забывают указать в вакансии и на собеседовании новому сотруднику Ване, рассказав что у них крутое SPA приложение и вообще работы завались и как все будет круто, интересно, а главное весело и познавательно.
Ваня хороший программист, отлично учился в универе, на профессиональном уровне освоил javascript на предыдущей работе, разбирается во многих его особенностях, отлично знает концепции многих фреймворков, из-за чего начал искоса поглядывать на jquery… он мог бы писать сам jquery, внося свой вклад в развитие фреймворка, но ему это просто не интересно, а концепция и политика jquery не внушает доверия.
И вот первый рабочий день Ваня скачивает проект и что он видит? Горы jquery плагинов, наскоро прикрученный на все Backbone, который еще вовсе не работает как SPA, в сочетании с кучей непонятной фигни. Ваня отлично знает javascript и разобраться с плагинами(на этот момент уже устаревшими, как и версия jquery) для него не представляет труда. Заглядывает в main.js файл в котором видит лишь
$('.date').datepicker()
$('#slider').slider()
$('.photo').zoom()
…
и так строк 50
и еще с десяток вспомогательных файлов, с синтаксисом, как в статей (про next), а также скрытыми вызовами прямо на вьюхах.
Ваня чувствует себя обманутым, ведь вместо крутого SPA приложения на javascript, получил кучу плагинов jquery.
Так что же теперь думает Ваня о своих чудесных предшественниках? и считает ли он их программистами?
Я правильно понимаю, что вместо того, чтобы за 5 минут прикрутить готовый плагин автокомплита, вы предлагаете потратить несколько часов (в лучшем случае, потому что потом надо будет еще убить время на тестирование) и написать его самому?
вы читаете между строк?
проблемы начинаются дальше, когда на каждую задачу, даже элементарную, прикручивается плагин и их кол-во зашкаливает
За это его ругать не стоит, вещь не из самых простых для начинающих.
проблемы начинаются дальше, когда на каждую задачу, даже элементарную, прикручивается плагин и их кол-во зашкаливает
Нет, я не читаю между строк. И не язвлю, в отличие от вас.
Но я в вашем топике не вижу решения проблемы. Окей, вы говорите, за это его ругать не стоит. Сколько тогда ему можно еще добавить плагинов, чтобы начать его ругать? Какой критерий отсечки, когда надо все бросить и с богатырским рыком переписать все на ваниллу?
Но я в вашем топике не вижу решения проблемы. Окей, вы говорите, за это его ругать не стоит. Сколько тогда ему можно еще добавить плагинов, чтобы начать его ругать? Какой критерий отсечки, когда надо все бросить и с богатырским рыком переписать все на ваниллу?
К сожалению, критерий бывает в виде потери производительности, вот только потом уже поздно что-то менять, или придет кто-то другой, кто не захочет или не сможет поменять, потому как уйдет на это куча времени. Опять таки, зависит от разрабатываемого приложения.
А решение проблемы, в использовании инструментов с умом.
А решение проблемы, в использовании инструментов с умом.
Все приходит со стажем. Вы просто не сможете молодого программиста, который 2 недели прикручивает плагины на jQuery, за еще 2 недели обучить всей подноготной JavaScript. Поэтому можно только рекомендовать литературу и делать намеки на не-оптимальные участки кода, вести дескуссию. Плохой программист — который начнет с вами спорить и прирекаться. Но к таким нужно относиться по-философски.
Ничего в jQuery плохого нет. Есть другие менее распространенные фреймверки, при использовании которых, код становиться на порядок прозрачней, но камнем преткновения всегда выступает jQuery. Почему?
Ничего в jQuery плохого нет. Есть другие менее распространенные фреймверки, при использовании которых, код становиться на порядок прозрачней, но камнем преткновения всегда выступает jQuery. Почему?
jQ — как самый популярный попадается на пути. Поэтому им и обобщают.
Ну и следовательно его знают больше людей, чтобы брать его в сравнение. Ведь глупо будет выглядеть если в статье будет для примера использоваться не известный автору фреймворк.
В общем — это плата за популярность. Паровозом он идет :D
Ну и следовательно его знают больше людей, чтобы брать его в сравнение. Ведь глупо будет выглядеть если в статье будет для примера использоваться не известный автору фреймворк.
В общем — это плата за популярность. Паровозом он идет :D
Nice try.
k12th всё правильно написал в комментарии выше. Это уже уровень стратегии развития проекта. Стабильность, популярность, экосистема, поддержка и кол-во спецов на рынке гораздо важнее сэкономленных килобайтов (тем более это всё относительно и со временем сойдёт на нет). Единственное, с чем соглашусь, что подключение увесистого jQuery UI ради одного компонента — моветон, если есть возможность найти аналогичный jQ/standalone-компонент.
Далее вы начали уже мешать архитектуру, фреймворки и UI. А jQuery — это база для кросс-браузерного UI (не путать с jQ UI).
Если веб-приложение тормозит, jQuery стоит в конце списка, где может быть проблема.
P.S. Есть хорошее английское выражение — «It depends ...». Всё зависит от требований, проекта, браузеров, команды, сроков (!) и т.п. Если проект делается под нормальные браузеры и сроки вменяемые, сами с удовольствием и по возможности делаем standalone-компоненты, там где это уместно.
Мне лично нравится концепт модульности небольших компонентов/либ проекта Component (что это такое, список плагинов, github) — своего рода unix-way для фронтенда (по большей части), но он пока только набирает обороты.
k12th всё правильно написал в комментарии выше. Это уже уровень стратегии развития проекта. Стабильность, популярность, экосистема, поддержка и кол-во спецов на рынке гораздо важнее сэкономленных килобайтов (тем более это всё относительно и со временем сойдёт на нет). Единственное, с чем соглашусь, что подключение увесистого jQuery UI ради одного компонента — моветон, если есть возможность найти аналогичный jQ/standalone-компонент.
Далее вы начали уже мешать архитектуру, фреймворки и UI. А jQuery — это база для кросс-браузерного UI (не путать с jQ UI).
Так что же теперь думает Ваня о своих чудесных предшественниках? и считает ли он их программистами?Если плагины хорошие, грамотно написаны и поддерживаются, то всё неплохо, как минимум. Гораздо хуже было бы, если
drag & drop, слайдеры, скролеры, карусели, зумеры, табы, дейтпикеры, маски…представляли из себя велосипеды не самого лучшего качества, которые никто кроме самих авторов поддерживать не может (и уже не будет). Есть, конечно, вариант, что эти самописные компоненты будут грамотно написаны, оттестированы и заопенсорсены (+ появятся контрибьюторы, соответственно и поддержка). 1) Вопрос: сколько на это потребуется времени? (а время — деньги) 2) Вероятность такого поворота, в контексте вашей версии истории, близится к 0 (пока не придёт Ваня :).
на профессиональном уровне освоил javascript на предыдущей работе, разбирается во многих его особенностях, отлично знает концепции многих фреймворков, из-за чего начал искоса поглядывать на jqueryНикто из коллег фронтендеров не смотрит искоса на jQuery (бывают, конечно, споры / ворчание, но всё же...). Наоборот, все прекрасно понимают его вклад в развитие и аргументы, изложенные выше. Главное понимать, где его использование будет уместно, а где нет.
Если веб-приложение тормозит, jQuery стоит в конце списка, где может быть проблема.
P.S. Есть хорошее английское выражение — «It depends ...». Всё зависит от требований, проекта, браузеров, команды, сроков (!) и т.п. Если проект делается под нормальные браузеры и сроки вменяемые, сами с удовольствием и по возможности делаем standalone-компоненты, там где это уместно.
Мне лично нравится концепт модульности небольших компонентов/либ проекта Component (что это такое, список плагинов, github) — своего рода unix-way для фронтенда (по большей части), но он пока только набирает обороты.
Да, и в контексте вашей версии истории, главный косяк-то в руководстве «аутсорс»-конторы, которое не сумело определить, что товарищ-то пока ещё не совсем опытный для позиции «ведущий фронтендер». Когда в проекте грамотный тимлид и ведущие по своей части, степень бардака резко снижается.
Правда ваша, но историю по сути своей и придумывать не пришлось… Сам конечно использую jQ для кроссбраузерности в местах где это действительно нужно, но порой и от него получается непредсказуемое поведение, с различными результатами в разных браузерах.
Как я и ожидал, много кто бросился рвать на себе рубаху и с боем защищать jQuery и решения построенные на нем, забывая, что речь о jQuery 2.0.
естественно, но вот код, который написан на нем, как правило, «хорошими знатоками» js… мягка говоря, качественным не назовешь.
Доводилось видеть, как каждыйверстальщикфронтедер, освоивший запись $()… подключает библиотеки и при использовании их, допускает ошибки в js, о которых в любой книге написано с первых строк.
Как я и ожидал, много кто бросился рвать на себе рубаху и с боем защищать jQuery и решения построенные на нем, забывая, что речь о jQuery 2.0.
Если веб-приложение тормозит, jQuery стоит в конце списка, где может быть проблема.
естественно, но вот код, который написан на нем, как правило, «хорошими знатоками» js… мягка говоря, качественным не назовешь.
Доводилось видеть, как каждый
забывая, что речь о jQuery 2.0.Версия мало имеет значения, главное — экосистема, стабильность, преемственность API и далее по списку в моём предыдущем комменте (уже 3-й раз повторил :)
естественно, но вот код, который написан на нем, как правило, «хорошими знатоками» js… мягка говоря, качественным не назовешь.&
Доводилось видеть… допускает ошибки в jsДа всем, на всех языках программирования, доводилось видеть всякое. Это же не повод экстраполировать.
В общем, вывод очевиден: дело-то совсем не в инструменте (jQuery), а в не очень опытных падаванах. Чем выше популярность языка, тем чаще встречается «всякое». Суть претензии к jQuery в том, что это «всякое» может вполне себе работать, но тут ведь только от падавана зависит желание учиться как делать правильно (и, в идеале, под присмотром коллег-мастеров).
Как же это знакомо. Бывает откроешь исходный код какого нибудь супер навороченного ГС, а там содержимое head в виде простыни — длиннее/массивнее body. И это только подключаемое. А вот в качестве бонуса в хедер ещё вставляют сам JS код.
ejohn.org/blog/thoughts-on-queryselectorall/ — я просто оставлю это здесь. И как написали выше, этих НО накапливается целая кучка. Я не призываю использовать jQuery, но это не отменяет обвязок, которые нельзя просто взять и заменить на натив код.
нельзя просто взять и заменить на натив код.
То есть js-фреймворки пишут не на натив js?
только на других фреймворках… я проверял!
Был какой-то хороший фреймворк, который всё умел и который сам с первой версии был собран на себе. Сначала был написан код на языке этого фреймворка, который преобразовывал код в жс. После чего на этом фреймворке написали сам фреймворк и с помощью ручки и бумаги вручную преобразовали его в нативный жс, прогоняя функцию преобразования в голове.
Неудачно выразился. Я хотел сказать, что
var $ = document.querySelectorAll.bind(document) и подобные замены, не всегда можно использовать как есть.Это просто пример краткой записи, как альтернатива sizzle, конечно же эта конструкция в большинстве случаев лишена смысла, но не во всех.
Я и говорю, что такая запись не может быть альтернативой и в реальной ситуации приведет к «багам», о чем и написано по ссылке.
В jquery2 реализована модульная система и можно сделать custom build, который содержит только нужное.
Также, сделана абстракция querySelector и есть обертка над native вместо sizzle. Подробности: github.com/jquery/jquery/blob/master/src/selector-native.js
Также, сделана абстракция querySelector и есть обертка над native вместо sizzle. Подробности: github.com/jquery/jquery/blob/master/src/selector-native.js
1.
2. jQuery силён своей экосистемой, поддержкой и стандартами. Время, когда большая часть браузеров будет нормальными, совсем скоро, соотвественно и ядро jQ будет весить совсем немного (как Zepto ±).
var $ = document.querySelectorAll.bind(document) — сильно ограничен в возможностях, т.к. выборка будет всегда с корня; есть ещё такой вариант:var $ = Function.prototype.call.bind(HTMLElement.prototype.querySelectorAll);
// use:
var somediv = $(document.body, 'div')[10];
var spans = $(somediv, 'span');
2. jQuery силён своей экосистемой, поддержкой и стандартами. Время, когда большая часть браузеров будет нормальными, совсем скоро, соотвественно и ядро jQ будет весить совсем немного (как Zepto ±).
Спасибо за статью — тема актуальная. Однако что касается визуальных эффектов имеет смысл полагаться на
requestAnimationFrame (http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/ или vimeo.com/77905678) вместо timer loops, так как этот именно метод предназначем и оптимизирован для подобных задач.
Относительно совместимости — это вопрос компромиса. Девелопер может по-прежнему писать Vanilla JS и использовать shim (скажем, из MDN коллекции, как это делает Лиа Вероу). Опять же проверка совместимости нынче не проблема. Достойный код должен быть густо покрыт тестами в любом случае. И далее в ходе интеграции (по коммиту) когда тесты будут отправлены на www.browserstack.com/ (скажем через bunyip) — отчет покажет определенно насколько кроссбраузеная поддержка имплементации соответсвует ТЗ. Опять же помним о YAGNI — если поддержки IE6 нет в требованиях, держать код поддержки в проекте точно не лучшая идея
requestAnimationFrame (http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/ или vimeo.com/77905678) вместо timer loops, так как этот именно метод предназначем и оптимизирован для подобных задач.
Относительно совместимости — это вопрос компромиса. Девелопер может по-прежнему писать Vanilla JS и использовать shim (скажем, из MDN коллекции, как это делает Лиа Вероу). Опять же проверка совместимости нынче не проблема. Достойный код должен быть густо покрыт тестами в любом случае. И далее в ходе интеграции (по коммиту) когда тесты будут отправлены на www.browserstack.com/ (скажем через bunyip) — отчет покажет определенно насколько кроссбраузеная поддержка имплементации соответсвует ТЗ. Опять же помним о YAGNI — если поддержки IE6 нет в требованиях, держать код поддержки в проекте точно не лучшая идея
А как же промисы в аяксе? без них не прикольно, когда его много.
«сам писал на jQuery до того, как освоил javascript… „
Для меня это звучит дико. Примерно как “я считал на калькуляторе до того, как освоил арифметику». А jQuery — просто библиотека, позволяющя некоторые вещи делать проще, быстрее и кроссбраузернее. Иногда можно без нее, иногда нужно без нее.
Для меня это звучит дико. Примерно как “я считал на калькуляторе до того, как освоил арифметику». А jQuery — просто библиотека, позволяющя некоторые вещи делать проще, быстрее и кроссбраузернее. Иногда можно без нее, иногда нужно без нее.
Раньше в проектах где объем js не превышает сотни строк обходился без jQuery. Проблемы начинались позже. Когда через пару лет возвращался к ним. Приходислось заново открывать код самописных хелперов чтобы понять что-же они делают. Далее добавляется много нового функционала, часть из которого намного проще реализовать плагинами jQuery. В итоге грохаются самописные хелперы и код переписывается.
Я только за Vanilla, когда используются только простейшие манипуляции, но я давно уже не сталкивался со случаями, когда ими все ограничивается. Чаще наоборот, одного jQuery мало и приходится использовать другие фреймворки которые работают вместе с ним или заменяют его. Чем дальше, тем больше киентский код становится сложнее серверного.
Я только за Vanilla, когда используются только простейшие манипуляции, но я давно уже не сталкивался со случаями, когда ими все ограничивается. Чаще наоборот, одного jQuery мало и приходится использовать другие фреймворки которые работают вместе с ним или заменяют его. Чем дальше, тем больше киентский код становится сложнее серверного.
jQuery — это прекрасная возможность написания спагетти кода. Возврат к комбам из жквери через год намного хуже чем к коду, написанному в виде разбивки на MVC.
а тут не принипиально, Vanilla или jQuery)
Именно, грамотно написанный компонент для страницы, с помощью классов и MVC, будет на много понятен, расширяем и гибок в использовании, чем любой плагин.
Поясню:
Понятен. По умолчанию компонент разделен на составляющие MVC, каждый решающий свои задачи. Никому в голову не взбредет искать логику модели на вью компоненте и наоборот. И даже по прошествии года/двух, любой человек знающий javascript разберется в нем, чего нельзя сказать о плагинах, которые на этот момент уже устаревают, а новые версии несколько раз переписаны под новые релизы jquery или вовсе больше не поддерживаются и тд… В итоге получаем стек устаревших(возможно с багами) плагинов, обновление которых требует других зависимостей и практически невозможно на крупном проекте, из-за того, что обновление jQuery ломает кучу всего.
Расширяем.
Если кому-то понадобится дополнить/поменять функционал, достаточно будет наследовать/изменить/дополнить существующий класс или метод, не забыв конечно про тест спеки.
Гибкий в использовании.
Компоненты, как отдельные сущности и не зависят друг от друга. Использование компонент, не перегружая какие-то базовые вещи, как это делает jquery ($.fn...).
Поясню:
Понятен. По умолчанию компонент разделен на составляющие MVC, каждый решающий свои задачи. Никому в голову не взбредет искать логику модели на вью компоненте и наоборот. И даже по прошествии года/двух, любой человек знающий javascript разберется в нем, чего нельзя сказать о плагинах, которые на этот момент уже устаревают, а новые версии несколько раз переписаны под новые релизы jquery или вовсе больше не поддерживаются и тд… В итоге получаем стек устаревших(возможно с багами) плагинов, обновление которых требует других зависимостей и практически невозможно на крупном проекте, из-за того, что обновление jQuery ломает кучу всего.
Расширяем.
Если кому-то понадобится дополнить/поменять функционал, достаточно будет наследовать/изменить/дополнить существующий класс или метод, не забыв конечно про тест спеки.
Гибкий в использовании.
Компоненты, как отдельные сущности и не зависят друг от друга. Использование компонент, не перегружая какие-то базовые вещи, как это делает jquery ($.fn...).
Поставил бы плюс автору но увы не хватает кармы. Хотя примеры приведены не самые удачные.
На моей практике большей части случаев jQuery использовался ради $('#elementId'). Сам же предпочитаю VanillaJS.
К слову о том что пишут мол много полезных плагинов у jQuery. Даже если исключить то что многие криво работают так регулярно под конкретные задачи их еще и переписывать надо. В конечном счете регулярно написать «велосипед» в контексте своего проекта куда быстрей и понятней (про понятность подразумевается для тех самых Вань из комментария выше).
На моей практике большей части случаев jQuery использовался ради $('#elementId'). Сам же предпочитаю VanillaJS.
К слову о том что пишут мол много полезных плагинов у jQuery. Даже если исключить то что многие криво работают так регулярно под конкретные задачи их еще и переписывать надо. В конечном счете регулярно написать «велосипед» в контексте своего проекта куда быстрей и понятней (про понятность подразумевается для тех самых Вань из комментария выше).
Ок, решено, отказываемся от jquery on, у нас же есть addEventListener.
А что с live? Ну мы можем смотреть event.target и сравнивать там, например event.target.className, вроде норм.
className состоит из нескольких классов? Не проблема, разобьем строку по пробелам или регуляркой чекнем в конце концов.
А что если в целевом элементе есть другие элементы и мы кликнули по ним, ведь в event.target попадет не то что нам нужно? Значит пробежимся по dom'у вверх и сделаем проверку для каждого элемента.
Хм, а что если обернуть всё это красиво в функцию, ведь забодаешься всё это каждый раз писать.
А вобще, ну его к черту, пойду обратно на jquery
А что с live? Ну мы можем смотреть event.target и сравнивать там, например event.target.className, вроде норм.
className состоит из нескольких классов? Не проблема, разобьем строку по пробелам или регуляркой чекнем в конце концов.
А что если в целевом элементе есть другие элементы и мы кликнули по ним, ведь в event.target попадет не то что нам нужно? Значит пробежимся по dom'у вверх и сделаем проверку для каждого элемента.
Хм, а что если обернуть всё это красиво в функцию, ведь забодаешься всё это каждый раз писать.
А вобще, ну его к черту, пойду обратно на jquery
className состоит из нескольких классов? Не проблема, разобьем строку по пробелам или регуляркой чекнем в конце концов.
Есть нативный classList, например: element.classList.add('hide'). IE10+
В посте речь о 2.0 где в свою очередь .live() отсутствует.
Deprecated 1.7 / Removed 1.9 пруф.
Deprecated 1.7 / Removed 1.9 пруф.
Я под live подразумеваю возможность в on вешать обработчик на родителя. Потому — что такая фича появилась сначала в live, потом её в delegate перенесли с указанием контекста, а потом в функцию on.
Данная функция не работала с элементами, создающимися динамически.
jsfiddle.net/u7DDV/
Неплоха практика навешивания обработчика на контейнер через
jsfiddle.net/u7DDV/
var b = $('<button>Click</button>');
b.appendTo('body');
b.live('click', function() {
alert('Click');
});
Неплоха практика навешивания обработчика на контейнер через
on(selector, listenerFn). Собственно все тот же live().Но jQuery делает именно это в live или добавлении класса. Только он делает попутно слишком много операций для обруливания кейсов, которые обычно не нужны. То есть $('#123') будет заметно медленнее document.getElementById не потому, что sizzle медленный, и не потому, что тут будет большой коллстэк пока мы дойдёт до гет бай ид, а потому, что попутно он проверит — а не стрингу ли мы передали, начинающуюсю и кончающуюся тегом, а не массив ли это. И получается что мы пришли валить деревья очень удобным блестящим швейцарским ножом, который угадывает что сейчас нам нужна пила, пробуя попутно сковырнуть ствол дуба отвёрткой.
Этот пост про Vanilla JS было интересно читать, потому что он был наполнен юмором, и никто его всерьез не воспринял. А вы же предлагаете бред какой-то.
Лет 6 назад, когда я еще в классе 8 был, когда ie7 только только вышел, решил для себя что буду писать на чистом js. Собственно знаний в нем не было никаких, а jquery невзлюбил за то, что каждый, кому не лень, предлагал его как панацею. По началу мне потребовалось совершить несколько манипуляций над стилями элементов, потом повесить несколько обработчик и в общем-то сейчас для подобных целей я бы тоже не стал использовать jquery, но в те времена изрядно намучился, так как никаких querySelectorAll еще не было (хотя по большей части, потому что делал все впервые).
Потом увидев статью на википедии про технологию ajax, захотел прикрутить у себя на сайте. Вот здесь у меня было очень много проблем с тем, что бы работало во всех браузерах одинаково, но так же у меня было много времени чтобы накапливать опыт.
Вообще в то время у меня была боязнь к библиотекам, и я писал свои велосипеды, где только мог.
Через пару лет я на хабре увидел реализацию чата, где с помощью jquery слались ajax-запросы и происходили манипуляции с dom. И вот тогда меня поразило с какой простотой делается то, над чем я убил однажды несколько дней. В тот момент начал его потихоньку использовать, но боязнь к библиотекам осталась. И я писал свои слайдеры, паралаксы и прочее, тратив на это много времени, но делал все это только ради обучения.
В этом году я устроился на работу. И у меня ни разу не возникало дилеммы, скачать ли библиотеку (которая состоит-то из 100 строчек, но зато отлажена) или написать, протестировать и использовать свою функцию (объект) и убить на это времени раз в 50 больше. Так же в проектах различных анимашек, манипуляций с деревом и ajax-запросов, ui-елементов обычно очень много, и клиентский код чаше намного больше серверного. И поэтому помимо jquery и jqueryui обычно подтягивается еще с пару десяток библиотек и плагинов к библиотекам. И иногда из всей этой солянки получается кромешный ад, но тут уже вопросы к построению процесса разработки, архитектуры проекта и прочего, при использовании лишь «Vanilla JS» в подобных проектах и при прочих равных условиях, я уверен, что этот ад был бы в десятки раз хуже.
А вот когда для себя и есть время, то стараюсь писать на чистом js, прорабатывая заранее архитектуру, создавая красивые обертки и велосипеды. И обычно в рамках объектно событийной модели, да там все красиво, понятно и быстро работает. Так же частенько по вечерам почитываю стандарты и различные гайды, и все это повышает скил. Но мне все равно совершенно не понятно, как можно разрабатывать более-менее средний по объему командный проект и не использовать библиотеки, отлаженные и со своим большим сообществом? Точнее понятно, но мне сложно представить заказчика у которого будут подобные требования или который заплатит за такую работу.
Лет 6 назад, когда я еще в классе 8 был, когда ie7 только только вышел, решил для себя что буду писать на чистом js. Собственно знаний в нем не было никаких, а jquery невзлюбил за то, что каждый, кому не лень, предлагал его как панацею. По началу мне потребовалось совершить несколько манипуляций над стилями элементов, потом повесить несколько обработчик и в общем-то сейчас для подобных целей я бы тоже не стал использовать jquery, но в те времена изрядно намучился, так как никаких querySelectorAll еще не было (хотя по большей части, потому что делал все впервые).
Потом увидев статью на википедии про технологию ajax, захотел прикрутить у себя на сайте. Вот здесь у меня было очень много проблем с тем, что бы работало во всех браузерах одинаково, но так же у меня было много времени чтобы накапливать опыт.
Вообще в то время у меня была боязнь к библиотекам, и я писал свои велосипеды, где только мог.
Через пару лет я на хабре увидел реализацию чата, где с помощью jquery слались ajax-запросы и происходили манипуляции с dom. И вот тогда меня поразило с какой простотой делается то, над чем я убил однажды несколько дней. В тот момент начал его потихоньку использовать, но боязнь к библиотекам осталась. И я писал свои слайдеры, паралаксы и прочее, тратив на это много времени, но делал все это только ради обучения.
В этом году я устроился на работу. И у меня ни разу не возникало дилеммы, скачать ли библиотеку (которая состоит-то из 100 строчек, но зато отлажена) или написать, протестировать и использовать свою функцию (объект) и убить на это времени раз в 50 больше. Так же в проектах различных анимашек, манипуляций с деревом и ajax-запросов, ui-елементов обычно очень много, и клиентский код чаше намного больше серверного. И поэтому помимо jquery и jqueryui обычно подтягивается еще с пару десяток библиотек и плагинов к библиотекам. И иногда из всей этой солянки получается кромешный ад, но тут уже вопросы к построению процесса разработки, архитектуры проекта и прочего, при использовании лишь «Vanilla JS» в подобных проектах и при прочих равных условиях, я уверен, что этот ад был бы в десятки раз хуже.
А вот когда для себя и есть время, то стараюсь писать на чистом js, прорабатывая заранее архитектуру, создавая красивые обертки и велосипеды. И обычно в рамках объектно событийной модели, да там все красиво, понятно и быстро работает. Так же частенько по вечерам почитываю стандарты и различные гайды, и все это повышает скил. Но мне все равно совершенно не понятно, как можно разрабатывать более-менее средний по объему командный проект и не использовать библиотеки, отлаженные и со своим большим сообществом? Точнее понятно, но мне сложно представить заказчика у которого будут подобные требования или который заплатит за такую работу.
Да автор топика молодец!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Vanilla JS vs jQuery 2.0