Выпуск JavaScript-библиотеки jQuery 4.0

[irsick]

You Might Not Need jQuery уже много лет пропагандирует те же идеи.

Но поезд давно ушёл. Я не вижу смысла новой мажорной несовместимой версии. Legacy вроде WordPress может остаться на старой, а современный web использует современные инструменты.

[pfr46]

Видим мы эти "современные" сайты. Несчастный магазин с десятком товаров на Laravel/Django с React/Vui.

[NetFantomIO]

Ну если так быстрее в разработке, то почему нет.

[MaximKiselev]

Потому что это жрет память. А оператива подорожала как не в себя и ещё дефицит предвидется на ближайшие года 2. Те у современных браузеров есть ограничение на размер памяти для вкладки - это раз (поэтому откройте любой chatgpt с большим количеством сообщений и увидите как ваш браузер уходит в запой), на реакте тоже надо уметь писать - напишешь чёто не так и оно будет тормозить дико и жрать память, поэтому одни сайты весят 100мб а другие 800мб. Откройте 5 вкладок и все , хром жрет память и вин последняя тоже жрет (походу там сломаны механизмы очистки кеша памяти). В итоге если у вас включен своп получаем повышенный износ накопителей. За кривой код платят всегда конечные пользователи а не компании, наоборот убьете вы ваше железо побежите покупать новый Ssd. У jquery есть альтернативы достаточно хорошие без сборок и копий DOM. Ну и не забываем про скорость загрузки и размер бандлов, ванильные сайты летают и быстро открываются. Jquery надо было идти не в сторону вырезания функционала а наоборот добавления типа реактивности, компонентов, более высокой и качественной работы с сетевыми запросами и технологиями, тулингом. Те изначально он для чего создавался пиши меньше и проще - делай больше, поэтому его и все полюбили.
Ждал большего от релиза :(

[NetFantomIO]

имхо это "общеводство". Жрут ли сайты с React больше памяти? При прочих равных да. Но и сайт с jQuery тоже потребляют больше, если сравнивать с ванильным JS, вообще без использования каких-то бибилиотек.

И это при "прочих равных", при условии, что разработчик квалифицированный. В противном случае утечками памяти можно выжрать ого-го и на ванильном JS.

Но! Скорость разработки с использованием бибилиотек и фреймворков заметно выше, чем без них. И это важнее для бизнеса, чем вопрос потребление лишних десятков и сотен мегабайн на клиенте. А компромис скорость разработки vs потребление ресурсов начал смещаться когда с Assembler перешли на более высокие языки программирования, если даже не раньше.

Возвращаясь к промеру - для магазина с десятком товаров вообще лучше бы использовать no-code/low-code подходы, или простигосподи налайвкодить. Но и катастрофы от выстрела пушкой тоже нет, если это прямо быстро. Пусть лучше инженер страдает от нарушенного чувства прекрасного, чем от голода =)

[ImagineTables]

сайт с jQuery тоже потребляют больше, если сравнивать с ванильным JS

Я бы так поделил варианты использования Javascript совместно с HTML (я говорю, «совместно с HTML», а не в «современном web», как написал кто-то выше, потому что сегодня HTML + JS это не только веб, но ещё и мобильные и десктопные приложения).

Первый вариант — использовать JS для того, для чего его и создавали: управлять готовым DOM'ом там, где не справляется разметка и стилевые преобразования. Ну, и, естественно, вызывать внешний по отношению к нему код.

Второй вариант — возложить на JS какую-нибудь сверхзадачу, в диапазоне от виртуализации DOM (React и пр.) до полноценной бизнес-логики (Electron'ные говноподелия).

В первом случае расход памяти будет несопоставимо меньше. По иронии, именно в первом случае и используется jQuery. На этом фоне смешно говорить про любой связанный с ним оверхед.

[NetFantomIO]

Роль JS не сводится к "управлению DOM", хотя это одна из важных задач, для которых он создавался. Бизнес-логика, валидация форм, взаимодействие с пользователем (реация на события) и вот это вот все.

Что касается роли конкретно jQuery, то он появился тогда, когда был зоопарк реализаций API в браузерах. Сейчас API стандартизирован, и рабочая лошадка document.queryselector работает везде. Так ли нужен он (jQuery) вообще?

Если вам нужно манипулировать DOM, валидировать формы или анимировать элементы, то вы можете спокойно делать разработку на pure js, но с jQuery может быть удобнее, особенно если вам нужно поддерживаться старые браузеры.

Если вам нужна реактивность, вы можете реализовать свой велосипед хоть на pure js, хоть с jQuery, но с React/Vue/Angular/... это делать удобнее и быстрее.

Если вам нужен базовый UI, вы можете рисовать свои компоненты, но удобнее взять Bootstrap/MUI/Tailwind/Materialize

Когда задача сделать продукт, который будет работать максимально быстро на очень ограниченных устройствах и в плохом сетевом окружении - конечно вы будете думать об оптимизации верстки, графики, JS (лучше вообще без сторонних либ).

Каждый слой абстракции pure js -> jQuery -> React.. добавляет свой оверхед, с этим спорить глупо. Хотя, конечно, в разном объеме, но вот будет ли он значимым для примера с простым магазином? Я думаю что нет. Именно поэтому мой поинт в том, что ничего страшного в этом нет.

Справедливости ради есть и другой тренд - когда для решения какой-то простой задачи (условно 2+2) начинают тянуть сторонные либы, и в результате общий бандл пухнет, при том что 99% функционала этих либ никак не используется, но вроде современные сборщики с этим научились успешно справляться.

[ImagineTables]

Бизнес-логика, валидация форм

Довольно странно видеть бизнес-логику и валидацию форм через запятую. Последний раз я так удивлялся, когда Брендон Айк через запятую перечислял WebView2 и Electron. Ошибка та же: «Отдам котёнка в добрые руки или утоплю». Даже в играх, которые очень стараются оптимизировать, используют скриптинг, чтобы выдерживать баланс между производительностью и удобностью. Валидация форм или WebView2 — это такой скриптинг здорового человека (хотя WebView2 лично я бы использовать не стал). А Electron и другие способы писать бизнес-логику — нет. Это так же тупо, как писать рендерер на Lua вместо C++/Vulkan. Мне это постоянно приходится объяснять при общении с потенциальными заказчиками, потому что они слышат про JS и сразу говорят: а мы хотим нативное приложение. По их логике, игра, использующая Lua — не нативное приложение. А всё из-за этого вонючего Electron'а, который испортил репутацию для всех программистов, чтоб его черти взяли. Поэтому каждый раз я так подробно объясняю. Надо бы постик, хотя бы, запилить на эту тему.

Что касается роли конкретно jQuery, то он появился тогда, когда был зоопарк реализаций API в браузерах. Сейчас API стандартизирован

И это я слышу постоянно. Тоже бы постик не помешал. Когда появился MFC, тогда был зоопарк реализаций универсальных библиотек (стандартная библиотека C++ ещё не была стандартизирована). И поэтому, как прагматики, авторы запилили в MFC свои строки, массивы, связанные списки. И некоторые на серьёзных щщах утверждали, что MFC это стандартная библиотека от MS (другие говорили — что это обёртка над WinAPI), хотя это всё сугубо вторично, а MFC это имплементация model-view-controller для приложений-редакторов.

jQuery соотносится с DOM API как SELECT с циклом for. Это декларативный язык (оформленный как библиотека — LINQ тоже одновременно язык и библиотека) цепочечных запросов, только не для данных, как SQL/LINQ, а для узлов DOM. Что не мешало мартышкам писать на нём var buttons = $('.my-button'); buttons.each( … button.css('color', 'red'); button.то(); button.сё(); … );.

[pfr46]

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

[NetFantomIO]

Согласен. Но если вы не знаете когда нужно заниматься оптимизацией, то вы просто никогда не запустите крупный проект.

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

Понимать когда нужно и когда не нужно вкладываться в оптимизацию на порядок важнее на мой взгляд.

В сухом остатке - оверинженеринг зло, но и убиваться в оптимизацию зло не меньше.

[pfr46]

Знакомый поход. Вот только вы же сами будете постоянно аргрейдит комп если все так будут делать и не стремится это исправить.

[gun_dose]

Так в том то и дело, что разработка будет медленнее в разы. Никак не может быть такого, чтобы в разработке Laravel + React оказалась быстрее, чем просто Laravel. Напомню, речь о несчастном магазине с десятком товаров, где никакая реактивность не надо, а с тем что надо отлично справится HTMX

[NetFantomIO]

Если медленее - вопросов нет. Мой поинт в том, что нет ничего плохого в условном "магазине с десятком товаров на Laravel/Django с React/Vui", если есть выигрышь в скорости создания. У опытного разработчика может быть в запасе много наработок, и если копи-паст за час позволит получить рабочий продукт, который требует немного больше ресурсов, то ну и фиг с ним. Бизнесу важна скорость, а не идеальные (с точки зрения инженеров) решения.

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

[MyraJKee]

Ого, я думал пациент скорее мертв, чем жив. Хоть и не являюсь противником jQuery