Здравствуйте, bnk, Вы писали:

A>>

A>>$('dialog')
A>>    .addClass('text-center')
A>>    .find('div textarea')
A>>        .addClass('width-100 text-center no-resize')
A>>        .prop('readOnly', true)
A>>        .prop('value', VarInput.split("¤")[0]);
A>>

A>>А первый отвечает: "Буду я ещё ГОВНОКОДИТЬ НА ЭТОМ ВАШЕМ jQuery!"

bnk>Ну ведь сам понимаешь, да?
bnk>IMHO намного чище без всяких непонятных `prop` и `$`

bnk>

bnk>const dialog = document.querySelector('dialog');
bnk>dialog.classList.add('text-center');

bnk>const textarea = dialog.querySelector('div textarea');
bnk>textarea.classList.add('width-100', 'text-center', 'no-resize');
bnk>textarea.readOnly = true;
bnk>textarea.value = VarInput.split('¤')[0];

Вот не соглашусь. На jQ это декларативная запись схемы преобразований DOM в чистом виде. Ни одного символа лишнего. Зачем, например, объявлять переменную, с именем, совпадающим с селектором, и делать таким образом копипаст, когда можно этого не делать (причём, без лишних запросов)? Это мелочи, конечно, но я и процитировал только кусочек. Когда этого полные штаны, где-нибудь да ошибёшься. И будет, например, после изменений проекта переменная dialog, содержащая не диалог, а панель, чтобы удивлять того, кому придётся поддерживать код.

Далее, два одинаковых prop'а наводят на мысль сделать мапу, описывающую новое состояние. Не будем забывать, что часть людей, придумавших соответствие атрибутов разметки и свойств OM, уже умерла от старости. Если бы это создавалось в наши дни, возможно, от этого сомнительного решения отказались бы в пользу DSL или того же самого .prop.

Далее, в случае с prop, конечно, много не наоптимизируешь, а вот с data — вполне себе. (data работает не с медленным DOM'ом, а с быстрыми js-объектами). А подход должен быть универсальным, иначе неконсистентно.

В целом, jQuery это аналог LINQ из дотнета. Только LINQ это декларативная запись схемы преобразований не DOM, а коллекций. И, соответственно, она нужна в core языка, а не внешнем браузерном API, как jQ. Другое отличие — LINQ пилит одна из лучших инженерных команд (хотя и их попрекают, хе-хе, всякими отсутствиями макросов), а браузерный API для ES пилит один из самых упоротых комитетов.