Артем

for (const i = 0; i < 10; i++) {

Этот вариант просто не будет работать, потому что ты мутируешь константу в выражении i++.
Это то же самое, что написать

const a = 1;
a++;

Именно поэтому используют let.

Я правильно понимаю — это не есть правило языка, это скорее «культура написания кода»?

Ты можешь использовать хоть var, но такой код никто не захочет читать и поддерживать. У const и let масса преимуществ перед var. Именно из-за них их и используют. Почитай про hoisting.

Потому как концепция «неизменяемая переменная» это странная идея

Отчего же это?

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

А чему уделять внимание? Держи в голове, что JS работает иначе, а погружаться в детали и пытаться понять логику работы под капотом — лишнее для тебя сейчас, имхо. Тебе нужно учить именно сам JS — фишки ES6+, пытаться писать оптимальный и грамотный код, а не лезть в дебри. Эти знания тебе сейчас практически ничего не дадут. Да, нужно знать какую-то базу про Event Loop, но эти базовые знания можно получить из 1-2 статей.

плюс мне кажется что js в браузере и js на сервере это немного разные вещи.

Да, конечно, различия есть, но эти различия — особенности среды исполнения, а не какие-то «фишки языка». Язык работает одинаково как в хроме, так и в ноде, потому что там работает один и тот же интерпретатор v8.
Опять же, тебе не нужно фокусироваться на этих различиях, если ты не пишешь серверную часть на ноде.

js в браузере — это лишь код, которые обрабатывается встроенным в браузер интерпретатором. И мне сложно представить что он единожды инициализируется и дальше работает.

Если так уж интересно, то по такому принципу работает консоль в браузере.

я изучаю js сквозь призму знаний о php

В этом и проблема: PHP и JS имеют абсолютно разную философию и цели, поэтому и работают по-разному.
Задача PHP — обработать запрос, выплюнуть какой-нибудь ответ и помереть. Тот же Node.js единожды инициализируется и дальше обрабатывает сколько угодно запросов, продолжая хранить все ранее инциализированные переменные в оперативке.
Соответственно, в Node.js нельзя просто сделать условный exit (die), чтобы быстренько помереть в рандомом месте приложения и выплюнуть ответ. Это может стать сюрпризом и вызвать сложности на первых порах, но в целом это помогает грамотнее проектировать приложение и уделять больше внимания его циклу жизни.

Разве не должна она был быть убита, когда страница полностью загрузилась?

Нет, это же не php, который born to die.

а когда она будет удалена?

Когда на нее не останется ссылок. Браузер тут вообще ни при чем, он предоставляет только интерпретатор JS.
Почитай про WeakMap и WeakSet, там подробнее объясняется про сборку мусора и вот это все.
Ну и там же есть ссылка на отдельную статью про сборку мусора.

жизненный цикл переменных в браузере

В браузере он ничем не отличается от того же Node.js, например. В обоих случаях JS не умирает так, как ты привык об этом думать из-за php.

{if 'фраза' | in : $.get.utm_term}
    pass
{/if}

Minishop, как я понял не ведет статистику, какой товар сколько раз куплен

Вполне себе ведет

$c = $this->modx->newQuery(msOrderProduct::class)
    ->select([
        'msOrderProduct.product_id as id',
        'SUM(msOrderProduct.count) as count',
        'Product.pagetitle',
        'Product.uri',
        'Data.price',
        'Data.old_price',
        'Data.new',
        'Data.image',
        '1 as bestseller',
    ])
    ->limit(20)
    ->leftJoin('msProduct', 'Product', 'Product.id = msOrderProduct.product_id')
    ->leftJoin('msProductData', 'Data', 'Data.id = msOrderProduct.product_id')
    ->groupby('msOrderProduct.product_id')
    ->sortby('count', 'desc');
if ($c->prepare() && $c->stmt->execute()) {
    return $c->stmt->fetchAll(PDO::FETCH_ASSOC);
}

if($true && $false){

условие шредингера, так сказать

проект менеджер берет на себя общение с заказчиком, понимание того что ему нужно, грамотно формулирует задачу программисту

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

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

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

это не задача программиста — полировать идею заказчика напильником

А кто этим должен заниматься, проект-менеджер? Очень сомневаюсь, что он сможет выстроить бизнес-логику хотя бы на близком уровне к тому, как это сделает синьор или тимлид. Проект-менеджер обычно занимается тем, что общается с заказчиком и передает «хотелки» программистам на понятном им языке.
Руководитель вообще этим не занимается, да и не должен.

А программист как ни крути — делает лишь сайт.

Опять же, зависит от уровня программиста. Кто-то делает «лишь сайт», а кто-то выстраивает архитектуру и бизнес-логику приложения.

микросервисным

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

В моем понимании раз уж мы общаемся на сайте посвященном modx — то тут все делают сайты и только сайты, а ни какие не проекты)

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

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

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

Если не брать в расчет Shopify, то сейчас ничего не изменилось. Wix и Tilda — все еще тот же ширпотреб, некие аналоги вордпресса, которые решают только самые примитивные задачи, для которых нерационально нанимать программиста.

Да я согласен с вами, что что-то со сложное бизнес логикой пока что конструкторы не потянут

Да и с относительно простой тоже.
Например, мне нужен простой сайт с рейтинговой системой. Ну, заполнил ты там свой профиль, получил 10 баллов, заполнил что-то еще — получил еще баллов.
Что мне может предложить Wix? Ничего. Что мне может предложить Tilda? Ничего.
Язык не повернется назвать такой проект сложным или серьезным, просто он нестандартный. И вот как только ты сталкиваешься с чем-то нестандартным, что не решается готовыми пакетами, так все, костыль на костыле.

Но они оторвут огромную часть рынка у простых роботяг-программистов.

Безусловно, но и ведь это не плохо. Если программист не развивается и не повышает свою квалификацию, то уж извините.

Потому что большинству заказчиков не нужны очень сложные решения

На мой взгляд, уровень заказчиков соответствует уровню программиста. Попробуй представить синьора с опытом 7+ лет, который на своей основной работе делает лендосы за 5к или простые магазины на CMS за 20к. Вот и у меня не получается.

Но та же тильда или wix через год два догонят.

Ну это вы, батенька, погорячились, мягко говоря

95 процентов желаний заказчика можно будет организовать просто двигая блоки по экрану в визуальном редакторе.

Это смотря какого заказчика. Если речь про лендосы с одной формочкой или типовые магазы с парочкой товаров, то разумеется. Если речь про сложные сервисы и серьезные проекты, то ни один заказчик в здравом уме не согласится делать что-то на виксе или тильде, — это антонимы для фразы «серьезный проект».

что все мы делаем на том же modx совершенно однотипные задачи

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

А есть американские конструкторы сайтов типа shopify — так это вообще мощнейший инструмент

Так далеко не все проекты ограничиваются функционалом магазина.

Что такое современный подход?

REST Api на бэке по всем канонам OpenAPI, React/Vue/Angular на фронте, который дергает это апи.

И что в нем такого хорошего?

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

В общем, посмотри github.com/bezumkin/VESP — это понятный пример

Я бы лично взял чистый Vue 3, а Nuxt, на мой взгляд, тут абсолютно не нужен.

А на чем ты собрался админку писать, на jQuery?

Для начала, наверное, нужно определиться с тем, как ты хочешь делать проекты. На CMS — это одно, а на фреймворке — совсем другое, здесь разные подходы, разные результаты и разные трудозатраты. А вот после этого уже можно что-то искать. Если нравится работать в CMS, то и переходить на Node.js смысла нет по большому счету.

Node.js — это, на мой взгляд, про самопис/фреймворки, а не про CMS. Ты сам пишешь API, сам строишь архитектуру приложения и бд, а потом сам отдельно пишешь фронтенд на React/Vue/Angular, который общается с уже готовым API. Лично я не вижу смысла переходить на Node.js и продолжать юзать CMS, это все уже есть в мире php, и выбор гораздо богаче, зачем менять шило на мыло?

Объясните, пожалуйста, почему так происходит.

Потому что имена переменных должны соответствовать правилам именования переменных в php. В php ты не можешь создать переменную name-1.
Правильный доступ к таким ключам осуществляется так:

{$_modx->resource['name-1']}

Если ключ массива соответствует правилам, то можно обращаться к нему через точку:

{$_modx->resource.name}

он встраивается в само оформление заказа.

В том то и дело, что он никуда не встраивается. Это обычный класс, который ты можешь привязать к любому объекту оплаты (msPayment) в настройках: miniShop2 -> Настройки -> Способы оплаты.
Во время оформления заказа miniShop2 смотрит на объект оплаты, который привязан к оформляемому заказу, ну и дергает оттуда метод send, передавая заказ в качестве единственного параметра.

Соответственно, тебе нужно по умолчанию поставить самую обычную оплату, без всяких классов-обработчиков, клиент будет оформлять заказ и сразу же видеть окошко, что заказ оформлен. Когда заказ получит статус «Ожидает оплаты» и клиент нажмет на кнопку «Оплатить», ты просто получаешь другой заранее подготовленный объект оплаты, у которого указан класс-обработчик робокассы, и точно так же дергаешь метод send, передавая выбранный заказ.

Платежный модуль робокассы — это ничто иное, как кастомный класс оплаты. Соответственно, тебе не нужно даже разбираться с ним, достаточно просто при нажатии на кнопку «Оплатить» отправлять запрос на сервер и дергать метод msPaymentInterface::send() у класса робокассы. Он тебе вернет ссылку, ты переходишь по ней с помощью js, ну и дальше все как обычно.