История и наследие jQuery

[kutensky]

По поводу поддержки IE 11… Не понятно когда вообще исчезнет необходимость его поддержки. К сожалению, Win10 всё ещё использует его как предустановленный браузер, и конца его поддержки пока не видно. А потому всё ещё приходится делать хаки и отказываться от некоторых новых фишек.

[vmarunin]

Разве не Edge используется? Нет, IE в недрах ещё живёт, но до него не так просто докопаться

[dimka11]

Его можно запустить через пуск, иногда его открывают другие программы.

Ради интереса запустил, впервые за последние года 2 обнаружил тулбар со ссылками яндекса :)

[Wolches]

Не понятно когда вообще исчезнет необходимость его поддержки.

В России как минимум до сих пор используют старые версии КриптоПро с привязкой функционала к данному браузеру, думаю в других странах тоже хватает IE-специфичных решений родом из нулевых.

[murzix]

Прогресс в сайтостроении тормозят «злые админы», иначе сложно объяснить почему на b2b сайтах пользователей с IE меньше не становится

[CoolWolf]

2009 год:
— Я сделал слайдер на чистом JS
— О_о (непонимающий осуждающий взгляд)

2019 год:
— Я сделал слайдер на jQuery
— О_о (непонимающий осуждающий взгляд)

Эх, как молоды мы были :)

[kikiwora]

iPad OS (iOS 13 на iPad) теперь определяет себя как
«Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko)»

Что сделано специально чтобы сайты не включали мобильную (как правило урезанную) версию, но и не детектится ни как одна из платформ (на данный момент), а тем более как мобила (что логично).

Отключается в опциях Safari. Но мало кто будет отключать в реальности — никто не захочет урезать функционал.

Это вызывает целый ряд проблем на сайтах которые написаны с использоанием платформ-детекторов (что плохо само по себе).

Но способ определить такое чудо как мобилу всё же существует, поскольку маков с мульти-тачем пока что не существует:

let isIOS = /iPad|iPhone|iPod/.test(navigator.platform) || (navigator.platform === 'MacIntel' && navigator.maxTouchPoints > 1)

В любом случае, если вы используете платформ-детекторы, то вы пишете код который пахнет (code that smells) — это плохой подход.

Используйте вместо детекта платформы feature detections.
Проверяете фичу — работает, используете, нет работает — делаете fallback или выводите сообщение с извинениями.

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

Лучше сайт который работает везде но не полностью чем тот который работает не везде но полноценно

А так, просто тестируйте на всех устройствах и решайте проблемы по мере поступления.
Не нужно форсить всех юзеров по одному шаблону.

И ради всего святого, не нужно посылать юзеров на кастрированые мобильные версии сайтов.
Делайте всё сразу нормально и продумано.

Responsive дизайн — будущее. Он сам подгонится под нужный размер экрана.

[Ghost_nsk]

Крсиво все написано, но в том же Safari периодически встречаются баги, от которых невольно вспоминаешь веселые времена IE6, «ну просто он такой вот».

[Aleksei_Segodin]

Есть довольно простой способ отделить тачскрины от устройств с обычным курсором, не запариваясь с размерами окна или типом браузера:

let regular = window.matchMedia('(pointer:fine)');
let touch = window.matchMedia('(pointer:coarse)');

if (regular.matches) {
  // обычный курсор
} else if (touch.matches) {
  // тач-скрин
} else {
  // устройство без курсора, оно же pointer:none
}

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pointer
https://caniuse.com/#search=pointer%3Acoarse

[PowerMetall]

И ради всего святого, не нужно посылать юзеров на кастрированые мобильные версии сайтов

Responsive дизайн — будущее. Он сам подгонится под нужный размер экрана

Как по мне — я просто убивать готов тех кто делает Адаптивный ®©™ Единый ®©™ сайт для всех устройств

Вот на кой ляд мне качать c мобильника весь этот интерфейс, всю эту кучу либ и фреймворков, картинок, скриптов, и прочего кода, из которых 80% все равно от меня скроется, ибо он же с телефона, покажем ему только то что нужно/вместится на экран

Итого я вижу те же 20% что и в мобильной версии, только RAM и CPU на моем устройстве эта страница сожрёт ровно столько же, сколько и полноценная версия для ПК, плюс будет лагать при прокрутках и прочих взаимодействиях, и да, грузиться по GPRS полдня, с шансом при каждом клике не прогрузиться до конца и не работать.

Возьмите любой сайт крупного магазина электроники, или стройматериалов. С мобильника (8 ядер, 3 гига RAM) — лаг на лаге, тормозит, если у тебя не то что 3g, если минимум не LTE — будешь ждать интерактивности вплоть до вечности, ибо у каждого скриптика, у каждого кусочка есть нефиговый такой шанс тупо не прогрузиться через GPRS, поломав при этом работу всей остальной страницы.
Про EDGE речи вообще нет, браузеры падают в таймаут раньше, чем на странице появится хоть что то. Особенно «весело» это когда ты за городом, как раз возле того тех же стройматериалов/хозтоваров

Скучаю по WAP сайтам, когда страница с той же инфой и, зачастую, логикой весила несолько килобайт, и абсолютно не тормозила на старом Сименсе с экраном 101х80 пикселей.

[DmitryKazakov8]

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

Я тоже помню текстовые сайты на заре развития Интернета, когда модем 32кб/с по карточкам, но сами приложения были с постоянной перезагрузкой, ужасным дизайном, и пользоваться было неудобней. Сейчас благо инет в основном быстрый, и можно делать красивые, удобные и быстрые в работе веб-приложения, увеличив размер файлов при первичной загрузке (при повторной — они возьмутся из кэша и откроются быстро). Ваши претензии надо перенаправить к создателям громоздких CMS-систем из 2000-х.

[potan]

«Императивный подход плохо масштабируется, но его освоить проще, чем декларативный подход других библиотек.»
Спорное утверждение. На старой работе, когда фронтендер был в отпуске, мне приходилось заглядывать в js-ный код (сначала с jQuery, потом с каким-то фреймвоком, кажется он назывался Ext4). Хотя я был уже достаточно опытным бекендером на C++ и Scheme, понять, что и как там работает мне было очень тяжело. Но когда мне понадобилось сделать небольшой фронт самому, я посмотрел на Elm и разобрался за пару дней. Декларативность этого языка и фреймвока очень помогла его быстрому изучению.

[funca]

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

[botyaslonim]

30 килобайт jQuery на фоне типичных бандлов для лэндингов в 3-5 Мб кажется теперь таким милым, пушистым… короче, это преимущество!

[piton_nsk]

А так, просто тестируйте на всех устройствах и решайте проблемы по мере поступления.

Проблема в том что тестировать на всех устройствах и браузерах это совсем не просто.

[AriesUa]

Если бы не jQuery мы не увидели новое API в браузерах. Именно некоторые фичи были перенесены с jQuery в браузер.

Стоит отдать должное — jQuery сделала небольшую революцию в JS.

[KorDen32]

На сайте You Might Not Need jQuery ...

… перечислено множество наглядных причин, почему jQuery всё ещё используется. Одна короткая строчка на jQuery против 5-10 строчек нативного кода.