Александр Мельник

Верно, Артем.
Видите мы с вами в процессе обсуждения пришли к такой неожиданной идее — в мире разработки, даже веб разработки, существуют совершенно разные миры. Эти миры живут по абсолютно разным законам и это нормально.
Вот вы пишите

Ради 1 строки вместо 3 тянуть jQuery?

Скажите, а что та фирма (или где вы работаете) занимается только разработкой с нуля проектов? Тогда конечно можно самим выбирать какие технологии использовать.
А мой мир выглядит так — директор находит на просторах интернета любые сайты, написанные на любых cms, движках и даже языках (пока не было только на C#), обещают им с СЕОшниками золотые горы и заключают договор. Сеошники сразу начинают говорить, ну мол ясно почему у вас все так плохо, у вас тут дескрипшены неверные, а тут нужно товары не так разместить, тут нужно сделать фильтр для товаров причем такой чтобы генерил урлы и позволял задавать тайтл свой для фильтрованных страниц и прочее в том же духе. И со всем этим приходят ко мне, мол — все делай. А это готовый сайт, сделанный 7 лет назад. К примеру вордпресс какой-то, у которого установлено 134 плагина, каждый плагин подключил свою версию jquery и так далее.
Согласитесь в такой ситуации, говорить о том, что я вам сейчас сайт перепишу, удалю jquery потому что она медленная (чем приведу 85 плагинов в негодность) — ну вообще не вариант. Причем это все нужно сделать на чистом энтузиазме, потому что лично заказчику совершенно все равно сколько и какие там библиотеки и плагины, ему сделали сайт 7 лет назад за 1000 рублей и платить за технические работы по нему он не собирается (тут особая странность нашей фирмы — мы типа только предлагаем услуги по СЕО, все программные работы для заказчика бесплатны и служат лишь для выполнения пожеланий СЕО).
Я это к чему, что есть и правда совсем разные миры в разработке и жизнь в них течет совсем разная, в каком то мире jquery это устаревшее и никому не нужное, сайты строит javascript собирает webpack, а есть миры (и их не мало) где сотни сайтов созданных черте когда и черте на чем, тоже нуждаются в поддержке, переделке и внедрению новых фич )

Ну так нужно учить только то, что реально тебе нужно в настоящий момент, а не гнаться на всем новомодным.

Правильные слова.
На данный момент я обслуживаю около 50 проектов в нашей компании. Но все это обычные сайты на разных cms (bitrix, modx, joomla, drupal, wordpress, opencart и еще более редкие). Плюс создаю новые, чаще всего на modx. Нигде в этих сайтах не используется vue react или не дай Бог angular. тут нигде (и в modx тоже даже нет нормального composer и поддержки psr-17). Поскольку мне ежедневно приходится работать именно с таким г… набором, то мне нет смысла (кроме собственного любопытства) изучать технологии (докер, vue и так далее). Но я их изучаю, но не использую (вернее только для своих тестов) и соответственно они напрочь вылетают из головы. Вот такая дилема)

Хотел написать, что вам же почему то не хочется писать .json() при работае с fetch хотя это всего7 символов, а почему кому-то должно хотеться переписывать

$('div').click(()=>{alert('hello world')})

на это

const divs = document.querySelectorAll('div');
if (divs) {
    divs.forEach((element)=>{
        element.addEventListener('click', ()=>{alert('hello world');});
    });
}

но наверное стоит уже заканчивать. Вы правы и молодец. Я не очень прав, но честно признаюсь — я просто офигеваю от обилия технологий и не успеваю их все вместить в свою голову. Я встаю утром до работы изучаю что то новое, работаю 9 часов, потом еще пару часов обучаюсь (и скажем так на пятом десятке это совсем не тоже самое что в 20 лет). И да, наверное все мои сомнения и мысли в первую очередь исходят из невысокого уровня знаний.

Можно ссылочку на подобные учебники?

learn.javascript.ru/xmlhttprequest

На сегодняшний день не обязательно использовать XMLHttpRequest, так как существует другой, более современный метод fetch.

В современной веб-разработке XMLHttpRequest используется по трём причинам:

По историческим причинам: существует много кода, использующего XMLHttpRequest, который нужно поддерживать.
Необходимость поддерживать старые браузеры и нежелание использовать полифилы (например, чтобы уменьшить количество кода).
Потребность в функциональности, которую fetch пока что не может предоставить, к примеру, отслеживание прогресса отправки на сервер.

Учебник Кантора тоже как бы намекает, что использование XMLHttpRequest сходит на нет, но вы правы в том, что fetch пока не умеет следить за процентом загрузки.

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

Но согласитесь вы с таким высказыванием?, что программист может сам решать что ему использовать, и если ему удобно работать с DOM через jquery то пусть работает. Не все программисты рисуют интерфейсы через новомодные фреймворки, добрый старый html никуда не делся.

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

Ведь все началось с чего, Евгений (автор поста) написал что в одном видео разработчик смешал vue и jquery. Мне кажется — если у него все получилось, то он молодец.

Подскажи, как ты собираешься обойтись без axios, если ты хочешь работать с api в условном Vue?

не могу ничего ответить разумного, я не пользуюсь vue.
Ознакамливался с учебником 2 версии, сейчас вроде уже 3 вышла.
А в чем там проблема? Насколько я понимаю, принцип работы vue в том, что он умеет реактивно изменять dom (не хочу сейчас вдаваться в тонкости между dom в браузере и виртуальным dom с которым работает vue), отсылая запросы, получая json ответы и по этим данным опираясь на template изменять страницу. Почему fetch не сможет отправить запрос и вернуть json?

тут молчу, я об этом не знаю.

но потом приходит понимание, что не просто так же используются другие решения (иногда просто так :) )

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

etch не поддерживает процентную загрузку, fetch не понимает коды ответа, Fetch требует постоянно писать .json(),

мне кажется это странные аргументы. Axios все это умеет только потому что это библиотека по работе с запросами. В ней написан код, создающий синтаксический сахар для работы и не более.
Так можно говорить, что javascript не умеет назначать прослушку событий на группу элементов, нужно навешивать в цикле listener, а в jquery можно написать $('div').click(()=>{}); и за одну строки и сделать выборку и навесить колбек. Значит jquery лучше?) Все это не более чем сахар.

Ну я не могу спорить, мне немного странно слышать фразу — «устаревшая библиотека, которая даром не нужна», у меня так когда то бывшая жена говорила про сумочку)

Я точно также читаю в разных учебниках javascript что объект XMLHttpRequest признан устаревшим и от его использования нужно отказываться. Поэтому axios это некий сумбур из устаревшего XMLHttpRequest с привязкой туда promise, в то время как fetch работает с promise нативно.
В общем сколько людей столько и мнений.

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

Согласен с вами Евгений.
Но с другой стороны не могу не спросить (ни в коем случае не для осуждения, мои уровни знаний не позволяют осуждать).
Вот вы пишите что в своей программе используете axios для запросов. Почему? Зачем?
Ведь сам язык javascript имеет отличные инструменты для отправки и получения запросов, асинхронность и прочее.
Могу ошибаться, возможно есть адекватные причины использовать axios но скорее всего — это просто привычка. Вы знакомы с этой библиотекой, вы знаете ее синтаксис и не задумываясь подключаете ее в код проекта. Хотя с точки зрения качества кода — это ненужный элемент. Тогда почему если кто то любит jquery не подключить эти несчастные 19 килобайт (могу ошибаться но примерно столько весит сжатая) и не использовать ее для запросов или еще для чего-то? Ведь и axios и jquery есть сторонние библиотеки, «раздувающие» наш код.

Поэтому я не совсем понимаю, когда говорят — вот так правильно, а в вот так нет, скорее в разработке применимо — вот так модно, а вот так не модно)

Я знаю здесь многие смотрят видео уроки Владилена Минина и да, в чем-то он хорош. Лично на мой взгляд он владеет предметом но не владеет даром обучать, который есть например у Дмитрия Лаврика, но сейчас не об этом. Сегодня у Минина вышло видео, как писать код используя одновременно react и vue. www.youtube.com/watch?v=eS9XXlqmhuw
Чем это лучше vue и jquery.

Ну не знаю. Я 15 лет проработал в прошлой жизни ведущим инженером на одном гос предприятии и вынужден сказать — это все же очень хорошее правило.
А жизненный опыт говорит — осуждай только в том случае, если сам смог сделать лучше.

Я не смогу сделать лучше чем автор в том видео, даже если он сделал не «по канону», поэтому не могу его осуждать.
Но я вот честно не люблю, когда в мире разработки фреймворки сидят на шее у фреймворков и погоняют фреймворками. Ведь что такое по своей сути vuejs как не фреймворк языка javascript. Но этого мало, над ним придумывают фреймворк vuetify что уже звучит дико. Еще пару фреймворков поверх и все программы будут выглядеть — $app->makeMeHappy( new DateTime('now'));
Не могу пояснить, но почему то мне это не приятно. Может потому что в 1991 году сидел с другом ночами над ассемблером и фортраном, а может просто потому что старость сопротивляется всему новому.

Не смотрел видео и наверняка пишу не в тему, но помню одно правило хорошего инженера — если что-то выглядит глупо, но работает — это не глупо)

представьте насколько проще было бы вам помочь, если бы вы показали, куда и что вставляете.
Начнем с того, где вы хотите «изменить стили»? На странице категории товаров (где идет вывод списка товаров) или на посадочной конечной странице товара?
Если в категории товаров, то как вы их отображаете, при помощи сниппета msProducts?
Если да, то вы в нем указываете имя tpl чанка, который отвечает за отображение одного товара в списке, ведь так? В этом чанке будет работать код, указанный Евгением — тоесть проверка на то что в переменной $favorite лежит что-то что может быть приведено к true. Ставите у товара галочку — особый и в эту переменную попадает 1.

Если вы хотите иметь доступ к переменной $favorite на странице товара, то используйте такой вызов
{ if $_modx->resource.favorite}my_class_for_favorite{/if}

Ну честно говоря, автоматическое создание аккаунта при заказе иногда приносит проблемы.
Не раз сталкивался со следующим поведением
— человек делает заказ указав email test@test.com и свои контактные данные
— ему автоматически создается аккаунт
— через месяц он еще раз делает заказ на сайте, указав тот же email, но другие контактные данные, например у него сменился телефон или адрес
— в такой ситуации в заказ могут попасть некорректные данные, подтянутся «старый»
телефон к примеру. Так же некорректные данные могут прийти в письме менеджеру о новом заказе.

Разве интересно всегда и везде использовать готовые компоненты? В чем тогда смысл быть программистом?

совсем удалите эту строку. Без нее подключится файл стилей по умолчанию.

вам не нужно вызывать pdoResources а ниже msProducts.
Вам нужно вызвать msProducts в чанке tpl.category.list

попробуйте tpl

&tpl=`@INLINE <li><a href="[[+uri]]">[[+pagetitle]]</a></li>`

сделать не инлайновую, а вынесите ее в чанк отдельный.