Js jquery: jQuery API Documentation

Как отказаться от jQuery в современном фронтенде: опыт команды GitHub

Не так давно GitHub полностью перестал использовать jQuery в своём фронтенд-коде. Мы перевели пост, в котором разработчики рассказывают, с чего началась их работа с jQuery, как они поняли, что пора от него отказываться, и как они смогли сделать это без использования других библиотек или фреймворков.

Зачем jQuery был нужен раньше?

jQuery 1.2.1 вошёл в число зависимостей GitHub в конце 2007 года. Это произошло за год до того, как Google выпустил первую версию браузера Chrome. На тот момент не было общепринятого способа обращаться к элементам DOM с помощью CSS-селектора, не было стандартного способа добавить анимацию к стилю элемента, а интерфейс XMLHttpRequest, предложенный Internet Explorer, как и многие API, был плохо совместим с браузерами.

С jQuery стало гораздо проще управлять DOM, создавать анимации и делать AJAX-запросы. У веб-разработчиков появилась возможность создавать более современные, динамические сайты, которые выделялись среди остальных. Самое главное, все функции JavaScript, проверенные в одном браузере с помощью jQuery, как правило, работали и в других браузерах. На заре GitHub, когда большинство его функций только обретали форму, появление jQuery позволило небольшой команде разработчиков быстро создавать прототипы и представлять новые функции без необходимости подстраивать их отдельно под каждый браузер.

Простой интерфейс jQuery также послужил основой для создания библиотек, которые в будущем стали компонентами остальной части фронтенда GitHub.com: pjax и facebox.

Веб-стандарты в последующие годы

С течением времени GitHub превратился в компанию с сотнями разработчиков и постепеннно сформировалась команда, которая отвечала за размер и качество JavaScript-кода, который мы отправляем браузерам. Одна из вещей, за которыми мы постоянно следим, — технический долг, порой вырастающий из некогда полезных зависимостей, которые потеряли свою актуальность по прошествии времени.

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

• Шаблон $(selector) можно легко заменить на querySelectorAll();
• Переключение CSS-классов теперь можно осуществить с помощью Element. classList;
• CSS теперь поддерживает создание анимации в таблицах стилей, а не в JavaScript;
• $.ajax-запросы можно выполнять с помощью Fetch Standard;
• Интерфейс addEventListener() достаточно стабилен для кроссплатформенного использования;
• Шаблон делегирования событий легко инкапсулировать с помощью легковесной библиотеки;
• С эволюцией JavaScript часть синтаксического сахара jQuery устарела.

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

$('.js-widget')
  .addClass('is-loading')
  .show()

Такой синтаксис прост в написании, однако по нашим стандартам не очень хорошо передаёт намерения автора. Сколько элементов js-widget, по его задумке, должно быть на странице: один или больше? А если мы обновим разметку страницы и случайно оставим имя класса js-widget, будет ли выброшено исключение, которое сообщит нам, что что-то пошло не так? По умолчанию jQuery молча пропускает всё выражение, когда нет совпадений по начальному селектору; однако для нас такое поведение было больше багом, нежели фичей.

Наконец, нам хотелось начать аннотировать типы с Flow, чтобы проводить статическую проверку типов во время сборки, и мы пришли к выводу, что синтаксис цепочек плохо поддаётся статическому анализу, так как почти каждый результат вызова метода jQuery одного и того же типа. Из возможных вариантов мы выбрали именно Flow, так как тогда такие возможности, как режим @flow weak, позволили нам начать прогрессивно и эффективно применять типы к кодовой базе, которая по большей части была нетипизированной.

В конечном счёте отказ от jQuery означает, что мы можем больше полагаться на веб-стандарты, использовать веб-документацию MDN в качестве официальной документации для наших фронтендеров, поддерживать более гибкий код в будущем и уменьшить вес наших зависимостей на 30 Кбайт, что в итоге увеличит скорость загрузки страницы и выполнения JavaScript.

Постепенный переход

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

• Начали отслеживать количество вызовов jQuery на строку кода и следили за графиком на протяжении времени, чтобы убедиться, что он либо не меняется, либо падает, но не растёт.
• Отказались от использования jQuery в новом коде. Чтобы достичь этого с помощью автоматизации, мы создали eslint-plugin-jquery, который проваливал CI-тесты при попытке использовать возможности jQuery вроде $.ajax.
• В старом коде появилось много нарушений правил eslint, которые мы пометили с помощью специальных правил eslint-disable в комментариях. Для того, кто будет это читать, такие комментарии должны были служить явным сигналом того, что здесь не отражаются наши текущие методы написания кода
• Мы написали бота, который при отправке pull request’а оставлял комментарий, сигнализирующий нашей команде каждый раз, как кто-то хотел добавить новое правило eslint-disable. Таким образом мы могли провести ревью кода на ранней стадии и предложить альтернативы.
• Большая часть старого кода была явно связана с внешними интерфейсами jQuery-плагинов pjax и facebox, поэтому мы оставили их интерфейсы почти без изменений, в то время как изнутри заменили их реализацией на чистом JS. Наличие статической проверки типов вселило в нас уверенность в проводимом рефакторинге.
• Много старого кода было связано с rails-behaviors, нашим адаптером для Ruby on Rails, таким образом, что он присоединял обработчик жизненного цикла AJAX к определённым формам:

  // УСТАРЕВШИЙ ПОДХОД
    $(document).on('ajaxSuccess', 'form.js-widget', function(event, xhr, settings, data) {
      // вставка данных ответа куда-нибудь в DOM
    })

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

• Мы поддерживали свою сборку jQuery, из которой убирали ненужные нам модули и заменяли более лёгкой версией. Например, после избавления от всех jQuery-специфичных CSS-псевдоселекторов вроде :visible или :checkbox мы смогли убрать модуль Sizzle; а когда мы заменили $.ajax-вызовы на fecth(), мы смогли отказаться от модуля AJAX. Мы убивали двух зайцев разом: уменьшали время выполнения JavaScript, параллельно гарантируя то, что никто не напишет код, который будет пытаться использовать удалённую функциональность.
• Глядя на статистику нашего сайта, мы старались прекратить поддержку Internet Explorer настолько быстро, насколько это возможно. Как только использование определённой версии IE падало ниже определённого порога, мы прекращали её поддержку и фокусировались на более современных браузерах. Отказ от поддержки IE 8-9 на раннем этапе позволил нам использовать многие нативные возможности браузеров, которые в противном случае было бы сложно «заполифиллить».
• В рамках нашего усовершенствованного подхода к написанию фронтенда GitHub мы сосредоточились на использовании обычного HTML по-максимуму, добавляя JavaScript в качестве последовательного улучшения. В итоге даже те формы и другие элементы интерфейса, которые были улучшены с помощью JS, как правило, могли работать даже с выключенным в браузере JavaScript. В некоторых случаях нам даже удалось удалить определённую устаревшую функциональность вместо её переписывания на чистом JS.

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

Custom Elements: пользовательские элементы

Одна технология, наделавшая шуму в последние годы, — Custom Elements: библиотека компонентов, встроенная в браузер, что означает отсутствие необходимости для пользователя качать, парсить и компилировать дополнительные байты фреймворка.

Мы создали несколько пользовательских элементов на основе спецификации v0 с 2014 года. Однако, поскольку стандарты в то время постоянно менялись, мы сильно в это не вкладывались. А начали только с 2017 года, когда была выпущена спецификация Web Components v1, реализованная как в Chrome, так и в Safari.

Во время перехода с jQuery мы искали структуры, которые можно было бы извлечь в качестве пользовательских элементов. Например, мы преобразовали код facebox, использованный для отображения модальных диалогов, в элемент <details-dialog>.

Наша общая философия прогрессивного улучшения относится и к пользовательским элементам. Это значит, что мы стараемся хранить как можно больше контента в разметке и только добавлять поведение поверх неё. Например, <local-time> по умолчанию показывает исходную временную метку, но с улучшением может переводить время в местный часовой пояс, а <details-dialog>, расположенный внутри элемента <details>, интерактивен даже без JavaScript, но может быть улучшен до расширенных возможностей доступа.

Вот пример того, как можно реализовать элемент <local-time>:

// Элемент local-time отображает время в текущем
// часовом поясе и местоположении пользователя.
//
// Пример:
//   Sep 6, 2018
//
class LocalTimeElement extends HTMLElement {
  static get observedAttributes() {
    return ['datetime']
  }

  attributeChangedCallback(attrName, oldValue, newValue) {
    if (attrName === 'datetime') {
      const date = new Date(newValue)
      this.textContent = date.toLocaleString()
    }
  }
}

if (!window.customElements.get('local-time')) {
  window.LocalTimeElement = LocalTimeElement
  window.customElements.define('local-time', LocalTimeElement)
}

Один из аспектов Web Components, который мы очень хотим перенять, — Shadow DOM. У Shadow DOM есть потенциал для раскрытия множества возможностей для веба, однако он также усложняет полифиллинг. Так как его полифиллинг на данный момент приведёт к снижению производительности даже для кода, который управляет частями DOM, не относящихся к веб-компонентам, для нас нецелесообразно использовать его в продакшне.

Полифиллы

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

Смотрите также: «Фундаментальные принципы объектно-ориентированного программирования на JavaScript»

Перевод статьи «Removing jQuery from GitHub.com frontend»

Подключение свежей версии JQuery в WordPress

А вообще, про подключение CSS и JS в WordPress на моём сайте есть отдельный видеоурок.

Наверное вы знаете, что на некоторых сайтах можно встретить JQuery версии 1.4.2, на некоторых 1.4.4, а иногда даже 1.6.4 (это самая последняя версия на момент написания поста).

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

Как же сделать так, чтобы на сайте автоматически подключалась всегда только самая новая версия?

Проще простого, самая последняя версия JQuery всегда находится по адресу:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>

Если валидация будет ругаться на эту строчку кода, знайте, она написана в HTML5 🙂

А вот пример подключения JQuery к WordPress. Учтите, это будет работать только в том случае, если в вашей теме присутствуют wp_head() и wp_footer().

add_action( 'init', 'true_jquery_register' );
 
function true_jquery_register() {
	if ( !is_admin() ) {
		wp_deregister_script( 'jquery' );
		wp_register_script( 'jquery', ( 'http://ajax.googleapis.com/ajax/libs/jquery/1/jquery. min.js' ), false, null, true );
		wp_enqueue_script( 'jquery' );
	}
}

Вставьте этот код в файл functions.php. Он находится в папке с вашей текущей темой.

Миша

Недавно я осознал, что моя миссия – способствовать распространению WordPress. Ведь WordPress – это лучший движок для разработки сайтов – как для тех, кто готов использовать заложенную структуру этой CMS, так и для тех, кто предпочитает headless решения.

Сам же я впервые познакомился с WordPress в 2009 году. Организатор WordCamp. Преподаватель в школах Epic Skills и LoftSchool.

Если вам нужна помощь с вашим сайтом или может даже разработка с нуля на WordPress / WooCommerce — пишите. Я и моя команда сделаем вам всё на лучшем уровне.

Переход с jQuery на Vue.js

Об авторе

Сара Дрезнер — заслуженный спикер и senior разработчик в Microsoft, автор статьей о трюках и хитростях CSS.

Нельзя просто так упустить все интриги, возросшие вокруг существующий JavaScript — фреймворков, но также не стоит забывать, что они явно не являются универсальными и каждый тип проекта требует что-то «свое». Возможно, вы не захотите устанавливать большое количество различных дополнений, чтобы просто реализовать небольшую абстракцию. Возможно, адаптация проекта под новые системы сборки, различные методы деплоя будет означать большое количество времени и усилий, которые вы будете не в состоянии включить в прайс клиенту. Возможно, вы не хотите писать в HTML JavaScript. Список может расти до бесконечности.

Что многие люди могут не знать, так это то, что вы можете легко внедрить Vue.js в ваш проект точно так же, как вы внедряете jQuery. Не нужно ничего перестраивать. Vue достаточно гибкий — в том плане, что вы можете его использовать прямо в HTML.

Итак, представим, что ваш код имеет следующий вид:

Вы можете в буквальном смысле изменить скрипт-тег и продолжить использовать HTML & JS точно так же, как вы использовали его до этого. Вам не нужно ничего переписывать. Вам не нужно интегрировать веб-паки. И вам определенно не нужно устанавливать никаких криповых чудовищ.

Вы можете заменить тэги и оставить разметку «как есть». Что радует, так это несказанная простота, гибкость и адаптируемость Vue.js, что вы можете увидеть на протяжении чтения данной статьи. Что же касательно размера, тут нас тоже ждет приятная особенность: всего лишь 86 КБ для версии 2.5.3 и 87 для более новой версии 3.2.1.

Давайте рассмотрим некоторые наиболее распространенные примеры использования нового фреймворка и убедимся в его неоспоримых преимуществах.

Перехват пользовательского ввода

Наиболее распространенным примером использования JavaScript  является отлавливание введенной пользователем в веб-формы информации. В нашем примере для упрощения мы не будем рассматривать комплексные формы, но для понимания этого будет целиком достаточно.

Чтобы отловить информацию, вводимую пользователем, мы можем сделать следующее:

Я использую этот пример, потому что он наглядно демонстрирует некоторые сильные стороны Vue. js. Он реализует особенности react, что делает его очень чуствительным в плане изменений. Демонстрацию вы можете увидеть, когда попытаетесь ввести что-то. Как можно заметить, вся информация обновляется практически мгновенно.

Вы также можете заметить это и в версии с JQuery — контролируя элементы DOM-дерева и работая с событиями, вызываемыми при изменении содержания его элементов.

В версии Vue.js мы сохраняем состояние элемента. Если более детально, то мы привязываем к нашему конечному скрипту DOM-элемент напрямую. Особенность в том, что даже в случае изменения структуры DOM-дерева и HTML в целом, конкретный DOM-элемент будет надежно привязан к нашему Vue.js — событию. Де-факто, на вводе мы используем атрибут v-model, тем самым обозначая хранение информации этого поля в JavaScript.

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

Хранение введенных данных в рамках индивидуального события

Особенность работы Vue.js заключается в том, что нам не нужно думать об особенностях реализации конкретного DOM-события. По сути, мы уже знаем, что мы желаем «перехватить». Мы просто указываем событию, на который из элементов срабатывать. Тогда как с использованием JQuery мы жестко привязываемся к структуре DOM и прочим DOM-событиям. Увидеть разницу мы сможем в следующем примере:

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

«Отловите элемент, просмотрите, что он делает, перехватывайте изменения, обрабатывайте полученные данные.»

Сравним: во Vue мы контролируем все изменения DOM-дерева. Мы привязываемся к конкретным элементам. По сути, мы имеем небольшую абстракцию под названием v-model.lazy. Vue тепер знает, что сохранять состояние данных до того, как были произведены первые изменения, нельзя. Отлично!

Классы

Следующая вещь, которую мы сейчас рассмотрим, является привязкой CSS-классов, так как наш всеми любимый и обожаемый Гугл сообщает, что это также наиболее популярный случай использования jQuery.

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

Мы храним active в данных, кнопка изменяет состояние условия и, в зависимости от условия, применяется к примеру .red. Даже состояния доступа, aria-pressed, сохраняются гораздо быстрее, так как у нас нет необходимости хранить все в vue-скрипте. Мы можем изменять состояние напрямую при помощи слова active.

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

Скрытие и отображение

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

Оба фреймворка успешно справляются с поставленной задачей, но все же и здесь есть свои причины, почему я отдаю предпочтение Vue.js. Vue обладает инструментом под названием Vue devtolls. Это не то же самое, что Chrome devtools, но когда я их использую, я получаю больше специфической информации, связанной непосредственно с Vue.js

И в jQuery и в Vue элементы успешно скрываются и появляются вновь. Но что, если что-то пойдет не так? Что, если что-то в нашем коде работает не так, как это было задумано? В случае с jQuery для отладки мы бы скорее всего использовали console.log и были бы таковы.

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

Что еще мне нравится, так это то, что v-if очень удобно принять в других случаях. Я могу использовать v-show, если вещь будет скрыватся и отображатся часто: v-if полностью «демонтирует» элемент, тогда как v-show просто изменит видимость. Это достаточно важно, так как позволяет улучшить производительность. Я легко могу установить целые каскады условий, в то время как повторить подобное с jQuery — слегка затруднительно.

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

Передача формы

Так уж исторически сложилось, что отправка формы посредством Ajax является наиболее «каноничным» примером использования jQuery. А потому мы просто обязаны рассмотреть альтернативу. На самом деле, Vue не обладает встроенными вещами навроде Ajax. Обычно вместо этого здесь используется Axious (js-библиотека для генерации http-запросов).

Этот пример будет несколько более сложным, чем предыдущие. Мы собираемся произвести следующее:

• До начала ввода в форму клавиша будет серой. После чего она примет «активный» класс и станет голубой.
• Когда мы отправляем форму, страница не будет перезагружаться.
• Как только форма принята, мы отобразим ответ на странице.

Здесь за управление классом клавиши отвечают строки 2-10. Похоже на то, что мы делали ранее.  Мы передаем в параметр под названием событие форму и говорим event.preventDefault(), дабы запретить перезагрузку страницы. После чего мы собираем всю информацию с формы и отправляем через Ajax запрос (.done()).

В версии Vue мы биндим поля через v-model. Мы проверяем имена для связки с классом. Вместо передачи информации и загрузки страницы event.preventDefault(), нам всего лишь нужно написать @submit.prevent в нашем элементе формы. Для передачи запроса же мы используем Axious.

Конечно, так же можно произвести и валидацию, отлавливание ошибок, тесты и так далее. Но для понимания логики работы с Vue, как мне кажется, достаточно и этих небольших примеров.

И в заключение

Нет ничего плохого в том, чтобы продолжать использовать jQuery. Цель этой статьи — всего лишь показать, что Vue так же хорош в качестве некой такой абстракции для небольших сайтов. Этот фреймворк оптимален в размерах, прост  в работе и освоении, достаточно тривиален и прекрасно интегрируется в HTML & JS без необходимости перестраивать приложение.

Благодаря гибкости Vue передача кода на стадию билда и общая компонентная структура не являются чем-то сложным. На самом деле — это очень даже весело. Попробуйте сами! Вы можете скаффолдить весь Vue на уровне продакшена просто при помощи пары терминальных команд. Подобным образом вы можете работать с отдельными компонентами, не трогая HTML & JS. Вам не нужно менять конфигурацию вашего веб-пака, разве что вы не захотите сделать что-то специфическое.

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

Удачи в разработке!

Автор перевода: Евгений Лукашук

Источник

Фальшивая версия плагина jQuery Migrate заразила множество сайтов — «Хакер»

Исследователи  Денис Синегубко и Адриан Стоян обнаружили на десятках сайтов фейковые версии файлов jQuery, имитирующие плагин jQuery Migrate для WordPress, работающий на 7,2 млн сайтов. Такие подделки содержат обфусцированный код для загрузки малвари, и пока неясно, как эти скрипты попадают на страницы скомпрометированных ресурсов.

We lately see many websites with replaced . /wp-includes/js/jquery/jquery-migrate.min.js
It loads malware from hxxps://stick.travelinskydream[.]ga/analytics.js pic.twitter.com/3W7nSoCsLm

— Denis (@unmaskparasites) March 30, 2021

Чтобы затруднить обнаружение, эти вредоносные файлы заменяют легитимные файлы по адресу ./wp-includes/js/jquery/, где WordPress обычно хранит файлы jQuery. Так, файлы jquery-migrate.js и jquery-migrate.min.js содержат обфусцированный код, дополнительно загружающий странный  файл analytics.js с малварью внутри.

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

Издание Bleeping Computer пишет, что на самом деле этот скрипт, конечно, не имеет никакого отношения к аналитике. Например, в коде содержатся ссылки на/wp-admin/user-new.php: страницу администрирования WordPress, предназначенную для создания новых пользователей. Более того, код обращается к  переменной _wpnonce_create-user, которую WordPress использует для обеспечения защиты от CSRF.

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

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

Начало работы с jQuery

Существует несколько способов начать использовать jQuery на своем сайте:

• Скачать библиотеку с официального сайта jQuery.com
• Включить jQuery по CDN, вроде Google

Скачивание библиотеки jQuery

На официальном сайте jQuery для скачивания доступно две версии библиотеки:

• Для готовых проектов (production) – эта версия предназначена для уже отлаженных и работающих сайтов. Она минифицирована и сжата, что позволяет ускорить ее загрузку.
• Для разработки (development) – это для тестирования и разработки новых скриптов (код не сжат и содержит комментарии).

Обе версии библиотеки можно скачать на сайте jQuery.com.

Библиотека jQuery — это один файл JavaScript, который подключается в HTML теге <script> (обратите внимание, что тег <script> должен располагаться внутри тега <head>):

<head>
<script src="//msiter.ru/jquery-3.4.0.min.js"></script>
</head>

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

Удивляетесь, почему в теге <script> мы не используем атрибут type=»text/javascript»? В HTML5 этого не требуется. JavaScript — скриптовый язык по умолчанию в HTML5 и во всех современных браузерах!

jQuery CDN

Если вы не хотите скачивать и размещать библиотеку jQuery на сервере своего сайта, то вы можете подключить ее с CDN (англ. Content Delivery Network – Сеть доставки содержимого).

Библиотеку jQuery можно подключить с сети Google и Microsoft.

Google CDN:

<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.4.0/jquery.min.js"></script>
</head> 

Microsoft CDN:

<head>
<script src="https://ajax.aspnetcdn.com/ajax/jQuery/jquery-3.4.0.min.js"></script>
</head> 

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

Синтаксис jQuery Вверх Учебник jQuery для начинающих

Переход с jQuery на Vue.

js Зачем, как и что из этого вышло

Опубликовано: 25 Июн 2019

Вернуться в блог

Меня зовут Сергей, я работаю в Студии Флаг с 2017 года и, когда я пришел, состояние фронтенда оставляло желать лучшего.

Введение

Меня зовут Сергей, я работаю в Студии Флаг с 2017 года и, когда я пришел, состояние фронтенда оставляло желать лучшего. Если CSS хоть как-то собирался, был разбит на модули, то на некоторых проектах весь JavaScript хранился в одном файле длиной несколько тысяч строк, не минифицировался, и периодически встречались комментарии типа «Не лезь, оно тебя сожрет». В другом месте JS-функция иногда возвращала “trulio” вместо true. Большая часть кодовой базы была написана на jQuery, что тоже не упрощало работу.

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

Постепенно, мы занялись созданием сборки фронтенда, начали с минификации (сжатия) и транспиляции (трансформации кода таким образом, чтобы он работал в старых браузерах) JavaScript с помощью популярного сборщика Gulp. Позже стали разбивать код на модули. С 2017 года мы начинали постепенно внедрять php-фреймворк Laravel. Кстати, создатели Laravel (Taylor Otwell) и Vue.js (Evan You) много общаются и выступают на конференциях друг у друга.

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

Почему Vue

Vue.js – это прогрессивный фреймворк для создания пользовательских интерфейсов. Создателем Vue.js является Evan You, бывший сотрудник Google и Meteor Dev Group. Начал он разрабатывать фреймворк в 2013-м, а в феврале 2014-го состоялся первый публичный релиз.

Почему мы выбрали именно его?

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

Во-вторых, Vue довольно легко интегрируется с Laravel, backend-фреймворком, который мы используем.

В-третьих, он подходит для постепенного внедрения. Постепенно изучая фреймворк, мы могли начинать использовать его в существующих проектах, которые не были написаны на Vue.js с нуля.

Немаловажным является то, что фреймворк имеет доступную документацию(в том числе на хорошем русском языке).
Vue.js появился позже Angular и React, и, как обещали разработчики, взял лучшее от обоих. На тот момент он уже начал обгонять React по звездочкам на GitHub, и в рейтинге любви разработчиков имел позиции не ниже, чем React. Совокупность этих факторов привела к выбору Vue.js, который мы начали внедрять с начала 2018 года, и еще ни разу не пожалели об этом.

Использование Vue.js

Для изучения Vue.js требуется базовое знание HTML, CSS, JavaScript, желательно знание стандарта ES6 и выше. Vue поддерживает все современные браузеры и даже Internet Explorer 9-11 и весит всего около 20 кб (min + gzip).

Для старта простого проекта на Vue.js достаточно скачать JS-файл и подключить его на страницу с помощью тега <script>. Будет зарегистрирована глобальная переменная Vue. Также существует Vue CLI – инструмент, с помощью которого можно быстро развернуть проект, и использовать все продвинутые возможности Vue (о них расскажу далее) без потери времени на настройку конфигов систем сборки фронтенда. Мы же на своих проектах используем Webpack + Laravel Mix (пакет для Laravel, позволяющий быстро настраивать Webpack).

Основные концепции

Основными концепциями Vue являются:

• конструктор
• компоненты
• директивы
• переходы