Pull to refresh
Comments 36
Хороший туториал, но содержание устарело. Лет на 5.
jQuery сейчас… не в моде, чтоли. Посмотрите на ваши же проекты, скорее всего вы используете его только для навешивания событий, show/hide и ajax запросов. В 99% обычных проектов большего и не нужно. Даже анимации, которыми раньше пользовались все, сейчас делают на CSS.

Плагины для jQuery тоже устарели. Но если уж пишите туториал по ним, то к «шаблону» добавьте поддержку AMD/CommonJs (или лучше обоих сразу), чтобы при подключении плагинов, например webpack-ом, не приходилось что-то дописывать.
Я ж и не спорю. как раз объясняю, что время jQuery постепенно уходит.
Жаль его нет в IE, можно конечно использовать полифил, но это опять значит какой-то доп.инструмент.
Спасибо, обновил статью про bower и npm.

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

$('#elm').on('click keydown mousedown', someHandler) 

Все то же самое я могу сделать и на vanila.js, но мне как минимум нужно будет описать, что-то вроде

function on(elm, events, handler) {
   if (elm) {
       events.split(' ').forEach(function (event) {
           elm.addEventListener(event, handler);
       });
   }
}

А это уже лишний не нужный код. Безусловно уже есть множество удобный библиотек для этих целей, но зачем использовать их все, если есть одна
Да я и сам им пользуюсь, уже скорей по привычке, да и у пользователей он скорее всего закеширован. Хотя для мобильников когда что-то делаю, стараюсь вообще отказываться от библиотек/фреймворков по возможности.
Избавляясь от 3 строчек «лишнего» кода вы тянете целую библиотеку и ставите свой скрипт в зависимость от неё. Потом другой разработчик на каком-нибудь, например, Ангуляр, захочет использовать ваш плагин и ему придётся тянуть лишнюю зависимость, которая в самом Ангуляре ни к чему. Так и получается, что веб пухнет от всех зависимостей, потому что авторы считают нативные реализации «лишним кодом».
В вашем коде нет ничего, чего нельзя или очень затратно сделать не используя jQuery.
Хм, написал автор плагин с использованием jQuery, а потом "другой разработчик на каком-нибудь, например, Ангуляр, захочет использовать ваш плагин и ему придётся тянуть лишнюю зависимость"

Если я пишу с использованием jQuery, то и готовые решения подбираю на jQuery, если пишу на Angular, то и решения подбираю соответствующие. А если я начинаю ради пары-тройки плагинов тянуть в один проект несколько фреймворков и больших библиотек — это однозначно проблема во мне, а не в тех, кто писал хорошие плагины под конкретные фреймворки
+1. Всему свое место. Вообще Ангуляр просто так не вводится, т.е. если вы уж решили вводить ангуляр то стройте под него приложение, а не цепляйте на ходу, а используйте jquery
А что заставляет разработчиков плагинов под Ангуляр использовать jQuery? Может, как автор выше прокомментировал: «без раздумий» подключать jQuery везде?
Вы попробуйте на ng-modules поискать UI плагины под Ангуляр — большая часть из них зависит от Bootstrap и от jQuery.
Я конечно понимаю, что выбор разработчика под какие библиотеки и фреймворки выбирать плагины, но ведь ничто не мешает разрабатывать компоненты без зависимостей и использовать их с любым фреймворком? Современные браузеры уже давно решили проблему работы с DOM.
Тут как бы и зарыта проблема, что вот никак не получится в нормальном проекте без НЕ современных браузеров. Пишу полгода уже новую версию проекта(сервис), с нуля. И вот казалось бы сейчас развернусь, а тут говорят что у IE8 есть достаточная доля рынка и мы не можем его игнорировать. И все классные разработки идут лесом
Насчёт npm подскажу, что можно немного упростить себе жизнь, если из корня проекта вместо команды «npm publish ./» (которую Вы порекомендовали) подавать команду «npm publish» без дополнительных уточнений. (Эта команда по умолчанию работает с текущим каталогом, поэтому его явное указание в виде «./» — это лишнее.)
Спасибо, дополнил статью про автоматизацию этого процесса.
(Дисклеймер: это ответ на вопрос "что в моде", а не холивар "х лучше jQuery")

Angular (уже выходит из моды), React (подходит к закату). Angular 2 и его конкуренты.
Ну на счет реакта я бы поспорил, а ангуляр просто обновится до второй версии. Да и ни то ни другое заменой JQ не является: фреймворк библиотеке не замена.

По «что в моде» — ES6-7 и современные браузеры. Ведь изначально jQuery создавалось именно что-бы избавить программистов от плясок вокруг кучи браузеров.
Ангуляр1 и Ангуляр2 абсолютно разные фреймворки, это не обновление и даже не расширение. Возможно Ангуляр2 следовало бы назвать другим именем, но видимо хотелось использовать прежний бренд для узнаваемости.

В Ангуляре2 есть проблема (на мой взгляд проблема), то, что он под 3 платформы сразу — JavaScript, TypeScript и Dart. Я не знаю как комьюнити приспособится к такому делению.

> Ведь изначально jQuery создавалось именно что-бы избавить программистов от плясок вокруг кучи браузеров

Всё верно, но технологии не стоят на месте — если что-то было удобно во времена IE6(7), то это не значит, что нужно тянуть технологию до IE12 (Edge, условно).

jQuery сыграл большую роль в веб-разработке и вообще развитии фронтенда, благодаря ему браузеры получили очень много нативных технологий, но пора развиваться дальше.
А какое основание насчёт того, что React "подходит к закату".
какая разница что в моде. Главное что эффективно
Это ИТ. Здесь то, что не эффективно — не в моде. И наоборот.
Для своих классов можно использовать паттерн модуля и паттерн открытия модуля, когда функция конструктор возвращает явно объект. Который является по сути маппингом на методы и свойства замыкания, чтобы сделать из публичными.
Ещё хороший тон, когда плагин поддерживает привычные интерфейс jQuery UI, а это:

$('.js-target').plugin('widget'); // возвращает ссылку на инстанс
$('.js-target').plugin('option', 'name'); // получить опцию
$('.js-target').plugin('option', 'name', 'value'); // установить
$('.js-target').plugin('destroy'); // уничтожает всё связанное

Если плагин порождает какой либо html, нужно оформлять его в виде шаблона, хотя бы с простецкой заменой по регулярке /\{(.*?)\}/ или тот же MicroTemplate использовать, там пара строчек. А совсем хорошо, когда можно передать функцию, чтобы в зависимости от параметра вернуть нужны html. Тоже самое касается всех имен классов и селекторов, которые используют плагин. Всё должно быть конфигурируемо.

Так же нужно корректно использовать data:

// Плохо
$(this).data('tooltips');

// Плохо
var NAMESPACE = 'tooltips';
$(this).data(NAMESPACE);

// Нормуль
var NAMESPACE = 'tooltips:' + Math.random();
$(this).data(NAMESPACE, instance);

Ещё одно правило хорошего тона, которое в целом относиться к любой публичной разработке, это выносить все внутренние утилитные методы, если они не приватные, в публичный статик объект, например какой-нибудь utils. Очень часто бывает, что уже все нужные методы для работы, те же самые: extend, addEvent, each и тому подобное, уже есть, но они оставлены в замыкании из-за чего приходится писать ровно тот же код, неуклонно увеличивая энтропию Вселенной.
UFO landed and left these words here
Я так понимаю, чтобы никто случайно не затер эти данные.
Чтобы ваш плагин не пересекся с другими пользовательскими данными или другим плагином.
Могу конечно ошибаться но конструкция
var self = this;
вроде бы считается антипаттерном, так как давно существует .bind(this) в прототипе Function
bind — полифилить нужно.
А вот self, that, t и т.п. хорошо бы заменить на четкое и понятное _this.
Добро пожаловать в реальный мир, где есть такие браузеры как IE < 9 и PhantomJS.
А простите, почему-то подумал как раз о том, что не нужно полифилить )
Вы конечно правы, мое беглое чтение Вашего коммента привело к непониманию.
Сравнивать не совсем корректно :)
Это разный подход.

self — создает замыкание.
.bind(this) — возвращает новую функцию.
Only those users with full accounts are able to leave comments. Log in, please.