Comments 29
класс, напишите, пожалуйста
лайки, к сожалению, тут только по разнарядке :)
лайки, к сожалению, тут только по разнарядке :)
Статья в стиле ретро )
$(document).ready( Function )реализуется вообще без единой строчки JS — перемещением скрипта в конец документа, перед </body>:)
Как бы это ни было банально, но альтернативой для Jquery.ajax() является XMLHttpRequest
Стоит добавить, что в перспективе (а с полифилом уже сейчас) удобнее будет использовать fetch.
Спасибо, я забыл про него. В своих следующих статьях я расскажу про неё.
Ну, а для тех, кто не хочет по каким-то причинам использовать fetch, есть axios.
fetch вроде как невозможно отменить.
Это иногда бывает неудобно для SPA. Отправили запрос, но тут пользователь перешел на другой экран и ответ от предыдущего запроса нас уже не интересует. Но ответ все равно придет и выполнится какой-то обработчик.
Это иногда бывает неудобно для SPA. Отправили запрос, но тут пользователь перешел на другой экран и ответ от предыдущего запроса нас уже не интересует. Но ответ все равно придет и выполнится какой-то обработчик.
jquery — фреймворк? И не абы какой, а самый лучший? Очень смелое заявление.
What is jQuery?
jQuery is a fast, small, and feature-rich JavaScript library.
window.onload != $(document).ready! onload сработает только после того, как прогрузится весь контент, включая изображения
UFO just landed and posted this here
youmightnotneedjquery.com вдуг, кто не знал…
habrahabr.ru/post/335926/#comment_10370036 Вдруг Вам было лень комментарии проглядеть ;)
В то время, как корабли бороздят просторы ES 2017, тут такое.
К сожалению Edge до сих пор не может ES 2016 потянуть :)
А babel уже торт?
А про Edge не правда.
А про Edge не правда.
Право слово, надоели уже с этой библиотекой jQuery.
Это просто библиотека, которая содержит набор различных методов, и исключительно ваше право какие из них использовать, какие нет, а какие реализовывать нативно.
В той или иной степени различные аналогичные библиотеки (фреймворки) также реализуют одни и те же методы, что и в jQuery, полностью или частично или более расширенно.
Ранее использовали jQuery потому что:
— можно сделать короче и понятнее код,
— это было модно.
Сейчас, в основной массе, используют другие принципы построения структуры веб -приложения, — сайта, — ..., и, соответственно, применяют другие библиотеки (фреймворки), более подходящие к конкретным задачам.
Поэтому нет смысла хаять или хвалить jQuery, эта библиотека может быть полезна и сейчас для определенного круга задач. А может быть полезна и другая библиотека (фреймворк).
И я совершенно не понимаю, когда ругают за использование jQuery, но при этом ковыряют ее исходники и выдергивают оттуда код какого-то метода. Писали бы сами что ли, раз все так плохо.
И я, к примеру, часто использую jQuery в проектах, хотя понимаю, что есть оверхед по КПД использования методов библиотеки примерно 20-50%, ну и что. Сейчас интернет позволяет прогрузить +- 100-200 kB дополнительных данных в запросе, работает кеширование разных уровней, отложенные загрузки, минификации и другие инструменты оптимизации. Гораздо печальнее выглядят различные зависимости, вот где КПД использования зашкаливает — требуется зависимость ради одного метода — вот это мне кажется черезчур жестким и неоправданным. Поэтому для не хайлоад вполне пойдет и jQuery для облегчения писанины нативных методов, а там где хайлоад — там подходы и критерии к оптимизации совершенно отличаются от standart.
И все возражения против jQuery в настоящее время — просто дань моде, не более. Сейчас практически все специалисты используют инструменты по назначению — и, если будет необходимость в jQuery — ее будут использовать. Без оглядки на моду.
P.S. Не холивара ради, истины для.
Это просто библиотека, которая содержит набор различных методов, и исключительно ваше право какие из них использовать, какие нет, а какие реализовывать нативно.
В той или иной степени различные аналогичные библиотеки (фреймворки) также реализуют одни и те же методы, что и в jQuery, полностью или частично или более расширенно.
Ранее использовали jQuery потому что:
— можно сделать короче и понятнее код,
— это было модно.
Сейчас, в основной массе, используют другие принципы построения структуры веб -приложения, — сайта, — ..., и, соответственно, применяют другие библиотеки (фреймворки), более подходящие к конкретным задачам.
Поэтому нет смысла хаять или хвалить jQuery, эта библиотека может быть полезна и сейчас для определенного круга задач. А может быть полезна и другая библиотека (фреймворк).
И я совершенно не понимаю, когда ругают за использование jQuery, но при этом ковыряют ее исходники и выдергивают оттуда код какого-то метода. Писали бы сами что ли, раз все так плохо.
И я, к примеру, часто использую jQuery в проектах, хотя понимаю, что есть оверхед по КПД использования методов библиотеки примерно 20-50%, ну и что. Сейчас интернет позволяет прогрузить +- 100-200 kB дополнительных данных в запросе, работает кеширование разных уровней, отложенные загрузки, минификации и другие инструменты оптимизации. Гораздо печальнее выглядят различные зависимости, вот где КПД использования зашкаливает — требуется зависимость ради одного метода — вот это мне кажется черезчур жестким и неоправданным. Поэтому для не хайлоад вполне пойдет и jQuery для облегчения писанины нативных методов, а там где хайлоад — там подходы и критерии к оптимизации совершенно отличаются от standart.
И все возражения против jQuery в настоящее время — просто дань моде, не более. Сейчас практически все специалисты используют инструменты по назначению — и, если будет необходимость в jQuery — ее будут использовать. Без оглядки на моду.
P.S. Не холивара ради, истины для.
Не заметил, чтобы автор хаял jQuery. Это, бесспорно, хорошая библиотека. Но нет ничего плохого в том, чтобы показать, как можно некоторые вещи делать без неё. Кто хочет, будет и дальше использовать jQuery, кто-то другой решит, что можно обойтись чистым JS, только и всего :)
Ранее использовали jQuery потому что:
— можно сделать короче и понятнее код,
— это было модно.
Есть и еще одна веская причина, не упомянутая Вами, а именно кроссбраузерность. Особенно это было актуально при необходимости поддержки древних IE, приводящей при использовании голого JavaScript к упомянутой автором классической схеме:
function getXmlHttp(){
var xmlhttp;
try {
xmlhttp = new ActiveXObject('Msxml2.XMLHTTP');
} catch (e) {
try {
xmlhttp = new ActiveXObject('Microsoft.XMLHTTP');
} catch (E) {
xmlhttp = false;
}
}
if (!xmlhttp && typeof XMLHttpRequest !== 'undefined') {
xmlhttp = new XMLHttpRequest();
}
return xmlhttp;
}
Уважаемые друзья из мира Javascript!
Выучите уже наконец несложную разницу между библиотекой (или даже «библиотекой библиотек») и фреймворком.
Имя этой разнице — «инверсия управления»:
— Если вы используете библиотеку, то ваш код вызывает методы библиотеки по необходимости.
— Если вы используете фреймворк, то вы пишете код, который будет вызван фреймворком по некоему событию.
Всё очень просто и никак не зависит от языка и года на календаре :)
Выучите уже наконец несложную разницу между библиотекой (или даже «библиотекой библиотек») и фреймворком.
Имя этой разнице — «инверсия управления»:
— Если вы используете библиотеку, то ваш код вызывает методы библиотеки по необходимости.
— Если вы используете фреймворк, то вы пишете код, который будет вызван фреймворком по некоему событию.
Всё очень просто и никак не зависит от языка и года на календаре :)
Не описана работа с DOM. Переводил пару лет назад интересный материал на эту тему http://rachkov.pro/blog/22
Никогда не пользовался jQuery, но jQuery меня бесит) Почти на любой запрос в гугле как что-то сделать с DOM (и не только) на JS, показываются результаты как это сделать на jQuery)
Sign up to leave a comment.
Реализация и альтернатива основных JQuery функций на чистом JavaScript