Артем

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

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

const a = 1;
a++;

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

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

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

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

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

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

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

{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 — так это вообще мощнейший инструмент

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

Я бы лично взял чистый 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}

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