что программист может сам решать что ему использовать, и если ему удобно работать с DOM через jquery то пусть работает.

Согласен, но это прямо говорит о том, что программист имеет довольно низкий уровень знаний или не хочет учиться. Повторюсь, что 95% оберток в jQuery запросто переписываются в 1-3 строки на чистом js, поэтому в jQuery нет смысла.
Помимо этого, это вешает на проект тяжелое jQuery-бремя и, вероятно, новый разработчик с более высоким уровнем знаний не захочет браться за старую jQuery лапшу.
Нужно думать не только о «мне так удобно и я так хочу», но и о проекте в целом. Если ты тянешь в проект jQuery, потому что «я так хочу», но на это нет веских оснований, то ты так себе программист.

в одном видео разработчик смешал vue и jquery.

Как я выше сказал — это говнокод в чистом виде, автор видео имеет довольно низкие знания и любой более-менее нормальный разработчик не будет использовать его разработку, если хоть мельком взглянет на то, что там творится.
Автор молодец только в том случае, если к вопросу подходить с точки зрения конечного продукта, а не с технической точки зрения, но мы как раз говорили о технической.

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

learn.javascript.ru/xmlhttprequest

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

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

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

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

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

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

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

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

Почему fetch не сможет отправить запрос и вернуть json?

Сможет, только тебе придется писать для него обертку, чтобы удобно работать с api. В реальном приложении ты постоянно обращаешься на разные эндпоинты, конвертишь json и обрабатываешь ошибки, fetch из коробки либо что-то из этого не умеет, либо делает это неудобно. У тебя здесь нет выхода, тебе нужна обертка, либо твое приложение превратится в ад.

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

Возьмешь готовую обертку над fetch? Ну так и чем это, по-твоему, будет отличаться от axios? При этом, если тебе вдруг понадобится сделать загрузку с процентным прогрессбаром, то ты не сможешь этого сделать на fetch и тебе придется как-то выкручиваться.

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

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

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

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

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

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

мне кажется это странные аргументы

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

Да, над fetch есть обертки, которые тебе и исключение бросят, и .json() за тебя сделают, но процентную загрузку они тебе не дадут без XMLHttpRequest.
Поэтому еще раз повторю, что fetch — низкоуровневый инструмент и пока он не сможет в процентную загрузку, заменить XMLHttpRequest им невозможно.

Я точно также читаю в разных учебниках javascript что объект XMLHttpRequest признан устаревшим и от его использования нужно отказываться.

Можно ссылочку на подобные учебники?
Я бы с удовольствием предложил авторам реализовать загрузку файла с процентным прогрессбаром на современном и новом fetch.

в то время как fetch работает с promise нативно.

Это не меняет ровным счетом ничего, потому что fetch все еще остается неудобным и обрезанным по функциональности, тем более, что обернуть XMLHttpRequest в промис — это несколько строк.

jQuery — устаревшая и ненужная библиотека, потому что:
а) 95% функционала из jQuery — это сахарок, который в современном js не нужен;
б) jQuery-обертки медленные, и это было бы простительно, если бы они были полезные, но это не так;
в) в современном js мире рисуют интерфейсы через React/Vue/Angular, в котором не работают с DOM напрямую. Напомню, что jQuery делает именно это — работает с DOM напрямую. Поэтому скрещивать любой из перечисленных фреймворков и jQuery — это говнокод в чистом виде.
г) для оставшихся 5% функционала из jQuery придуманы отдельные инструменты, куда более удобные, быстрые и функциональные. За примером далеко ходить не надо — тот же axios.

и то и то библиотеки, без которых можно обойтись.

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

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

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

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

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

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

Хотя с точки зрения качества кода — это ненужный элемент.

Почему ненужный? Нативный fetch — это низкоуровневый инструмент, у него есть ряд недостатков и он не везде удобен. Например, fetch не поддерживает процентную загрузку, fetch не понимает коды ответа и любой статус воспринимает как «успешно», даже если сервер вернул 500, либо вообще умер. Fetch требует постоянно писать .json(), что еще одно подтверждение того, что это низкоуровневый инструмент.

Axios — это удобная обертка над XMLHttpRequest, с интерсепторами, исключениями на основе кода ответа и удобным api. Ты можешь написать свою обертку над XMLHttpRequest, но, опять же, здесь за тебя уже все сделали.

jQuery, в свою очередь — это устаревшая библиотека, которая даром не нужна в современном js, и сравнивать ее с axios немного странно.

Почему? Зачем?

А ты попробуй просто взять и поработать с нативным fetch'ем, подергать какие-нибудь эндпоинты, а потом потихоньку придешь к пониманию, что все как-то не слишком удобно.

Вы не понимаете, это другое)

По axios с одной стороны да, привычка.
Но с другой стороны это более лаконичный синтаксис по сравнению с нативным fetch.
В axios проще засеттить значения по умолчанию: в моём случае адрес коннектора и заголовки именно там, где эти значения получены. Чуть проще обрабатывать HTTP ошибки (хотя к MODX это плохо относится, другая парадигма ответов).

Axios я использую не потому что привык это делать в мире MODX и jQuery, а потому что увидел его уже в мире Vue.js и видел регулярно. Да и вообще он появился раньше, чем появился fetch)

Переходя на другую технологию может и было бы легче использовать старые добрые инструменты (тот же jQuery.ajax()), но потом приходит понимание, что не просто так же используются другие решения (иногда просто так :) )

В своё время jQuery был прекрасным инструментом, но сейчас это уже legacy — развитие браузеров и JavaScript оставило его не у дел. И теперь уже нет такой нужды использовать его. Конечно, полно сайтов ещё долго будут использовать jQuery, но чем дальше — тем болезненнее слезать.

И уж точно не нужно его приносить в другой мир, где есть инструменты, которые решают те же задачи, но по-своему (обычно лучше, быстрее, надёжнее и т.д.).

И за модой тоже нужно следить. Мода это же не плохо, иногда она становится новым стандартом на много лет. За прекрасным пример отставания от моды и стандартов далеко ходить не нужно)

Маленький совет, лучше сделать поддомен video.*.ru, чтобы потом удобнее если что мигрировать на другой хостинг.
Да и с поддоменом вы можете видео хранить на хостинге, где подешевле место и трафик.

Подскажите пожалуйста как выполнить сортировку у msOptionsPrice.modification по опции size?

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

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

Да их полно, наберите онлайн конвертер видео. Можете этим воспользоваться convertio.

Спасибо за ответ!
Я не против, это требование клиента. Буду пробовать его убедить, разместить видео на youtube.
А если вдруг не получится, можете подсказать какие-то еще варианты решения? С помощью чего можно оптимизировать выдачу видео пользователям?

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

Супер.