Ссылка на jquery: Что такое jQuery? Как его скачать и подключить к сайту?

Содержание

jQuery | WebReference

AJAX (асинхронный JavaScript и XML) — это средство загрузки данных с сервера без перезагрузки страницы. Он использует функциональность встроенного в браузер XMLHttpRequest (XHR), чтобы сделать запрос к серверу, а затем обработать полученные от сервера данные.

jQuery предлагает метод $.ajax и несколько удобных методов чтобы упростить работу с XHR во всех браузерах.

jQuery является библиотекой JavaScript с открытым исходным кодом, написанной Джоном Ресигом, которая упрощает взаимодействие между HTML, CSS и JavaScript. С 2006 года, когда был выпущен jQuery, он приобрёл внушительное число пользователей, будучи используемый сайтами и компаниями, большими и малыми.

Что сделало jQuery настолько популярным, так это его простота в использовании, с выборкой напоминающей CSS и понятным разделением поведения. Преимущества jQuery огромны, однако для наших целей мы рассмотрим только возможности находить элементы и выполнять с ними разные действия.

Библиотека jQuery позволяет легко манипулировать кодом HTML после его отображения в браузере. Она также предоставляет инструменты, которые помогут пользователю взаимодействовать с вашей страницей; инструменты, которые помогут вам создавать анимацию; и инструменты, которые позволяют вам общаться с сервером без перезагрузки страницы. Мы вскоре до всего этого доберёмся. Для начала рассмотрим некоторые основы jQuery, а также применим jQuery для его основной работы: получить какие-то элементы и что-то с ними сделать.

jQuery делает тривиальным добавление простых эффектов на страницу. Эффекты могут использовать встроенные настройки или подгонять продолжительность анимации индивидуально. Вы также можете создавать собственную анимацию произвольных свойств CSS.

Смотрите более подробную информацию об эффектах jQuery в документации.

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

В этом разделе мы рассмотрим некоторые (но не все) методы обхода и манипуляции.

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

jQuery упрощает реагирование на действия пользователя с веб-страницей. Это означает, что вы можете написать код, который выполняется, как только пользователь щёлкает по определённой части страницы или когда он перемещает курсор за пределы элемента формы. Например, этот код отслеживает, что пользователь щёлкнул по любому элементу <li> на странице:

Как отказаться от 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-бандла для совместимости с устаревшими браузерами.

github/eventlistener-polyfill
github/fetch
github/form-data-entries
iamdustan/smoothscroll
javan/details-element-polyfill
jonathantneal/closest
kumarharsh/custom-event-polyfill

marvinhagemeister/request-idle-polyfill
mathiasbynens/Array.from
mathiasbynens/String.prototype.codePointAt
mathiasbynens/String.prototype.endsWith
mathiasbynens/String.prototype.startsWith
medikoo/es6-symbol
nicjansma/usertiming.js
rubennorte/es6-object-assign
stefanpenner/es6-promise
webcomponents/template
webcomponents/URL
webcomponents/webcomponentsjs
WebReflection/url-search-params
yola/classlist-polyfill

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

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

Ядро jQuery — все версии

<скрипт источник = "{{ссылка}}" целостность="{{хэш}}" crossorigin="анонимный">

Атрибуты целостности и crossorigin используются для Проверка целостности субресурсов (SRI). Это позволяет браузерам гарантировать, что ресурсы, размещенные на сторонних серверах, не был подделан. Использование SRI рекомендуется в качестве передовой практики всякий раз, когда библиотеки загружаются из стороннего источника. Подробнее читайте на сайте srihash.org

jQuery Core & Migrate — Git Builds

НЕСТАБИЛЬНЫЙ, НЕ ДЛЯ ПРОИЗВОДСТВА

сборка jQuery git — несжатый, уменьшенный, стройный, тонкий минимизированный
сборка jQuery 3.x git — несжатый, уменьшенный, стройный, тонкий минимизированный
сборка jQuery 2.x git — несжатый, уменьшенный
сборка jQuery 1. x git — несжатый, уменьшенный
jQuery Миграция сборки git — несжатый, уменьшенный