Andrei Popov

Если любишь типизацию то можно посмотреть в сторону https://nestjs.com + https://angular.io/ абстракции в них крайне похожи но тем не менее это два фреймворка. Одного фреймворка для фронта и бекенда нет потому что они выполняют разные задачи один служит для приема обработки и предоставления данных другой по большей степени для презентации их и пользовательского взаимодействия

Таки фуллстек фреймворки существуют. Вот самые яркие примеры:

https://www.meteor.com/
https://derbyjs.com

А вот стоит ли их сегодня изучать - это отдельный вопрос.

Кроме того, существует множество обвязок, соединяющих в себе фреймворки для бэка и фронта. Яркие примеры:
https://nextjs.org (react+express)
https://nuxtjs.org (vue+express)
Таких - просто тьма.

На сегодняшний день, часто пишут "бэкенд дня фронтенда". То есть - это рендер-сервер (иногда с сессиями), который берет данные по api у "настоящего" бэкенда.

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

1-й - по мне очень глупо - засоряем дерево (обязательно снимать с публикации - чтобы не было мусорных страниц в поиске)
2-й - Конечно MIGX - удобнее и более правильно

Думаю нет, опенкарт написан достаточно "в лоб", я в свое время писал расширения под разные версии и никогда мне не приходилось использовать паттерны проектирования, интерфейсы (абстрактные классы) и т. д., точнее Вас в принципе никто не ограничивает, но это время, а время в опенкарте часто низко ценится, а поскольку в самой цмс присутствуют свои нюансы:
- различные сборки которые имеют разные глюки
- кеш(оцмод/вкюмод, редко бывает мега ад когда оба функционируют одновременно),
- шаблон который почти всегда не подходит для Вашего проект
- конфликт расширений между собой
то все сводится к тому как можно быстрее сделать и забыть.
Опенкарт обычная MVC система где
M представлена набором запросов в бд
V до третьей версии это были обычные пхп файлы с хтмл разметкой, в третьей версии они подключили шаблонизатор твиг
С обычно огромный класс который все и делает

Избыточная верстка и css. Там много генерируется черти как пойми. Но для тех кто исходный код никогда не открывает - норм.

Вы подсаживаетесь на одно стороннее решение и скорей всего там и останетесь. Лучше для верстки написать своё. Так вы знаете что где и как работает. Почитайте сколько помощи на форумах поддержки по билдерам - близко к нолю. Зато в 90% вы получите ответ что нафига этим пользоваться?

СЕО - да ему все равно на него. Это удел спец плагинов.

Скорость загрузки - да. Она низкая. Например тот же элементор - хвастается лучшими сайтами на нем, собирая это в дайджест. Я в конце весны анализировал их - по скорости это просто ад. По другому не назовешь.

Но если вам надо лендинг собрать - собирайте на нем.
Выше написали - типа прототип на нем, а потом... И так сойдет...
Я мало видел сайтов что были на билдере, а потом вдруг их переписали нормально. Дайте мне такую инфу кто владеет - интересно.

Новый билдер - проект гутенберг. И в нем я сразу увидел кучу проблем, как сторонние разработчики блоков убивали производительность:
- просто засунули в фронт fontawesome 4.7 версии. ВНИМАНИЕ: ради 3х иконок!!
- просто засунули в фронт fontawesome 5.* версию и ВНИМАНИЕ это сломало первый вывод с 4.7 версией.

Короче - разносол в своей красе.

- еще с гутенбергом - любовь засунуть для простой верстки бутстрап. Нафиг не нужные 90% css будут у вас грузиться.

Почему так? Потому что у вордпресса нет handle для бутстрапа, скрипта рекапчи, карт и прочих частых и нужных библиотек.

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

Больше всего влияет на скорость загрузки - очень много лишнего грузится, верстка избыточна.

PageBuilder'ы понятно почему используют - чтобы показать лёгкость при работе с WordPress. Это удел людей, которым в код не лезть.

За нормальный SEO обычно отвечает плагин, и он обычно нормально справляется.

pdoTools обычно достаточно для визиток и несложных сайтов.
Без дополнений это шаблонизатор для статических страниц.

Сделать 5-10-50 проектов. Когда надоест каждый раз писать одни и те же велосипеды и ездить на них по одним и тем же граблям, "неприязнь" как рукой снимет.

Как правило, у любого стороннего модуля в npm есть исходники на github, вы можете ознакомиться с кодом и примерно понять, как это работает. Там же есть issues, где можно ознакомиться с имеющимися известными проблемами.
В целом, вероятность, что в популярном модуле, используемом тысячами и миллионами разработчиков, допустят ошибку и никто из этих людей за всё это время её не обнаружит, гораздо ниже, чем если вы в своём коде допустите ошибку.

в чистом сео никакого
но если у вас есть идея как продвигать про и идею про то конечно вы получите дикий буст в начале

Как то читал одного чувака, который решил проверить на практике, и купил одинаковые имена на нескольких доменах первого уровня. Сделал чтобы были одинаковые условия у всех. На деле не оказалось преимущества у домена .ком
Разница в том что браузер по умолчанию считает что основной домен это .ком, потому если написать имя и жмать вроде контрол+энтер, то откроет его. Не знаю насколько это часто вообще пользуют, но раз есть такая функция, то наверное кто-то пользует.
Также для запоминания лучше - дефолтный домен.
Но в Вашем случае портфолио фрилансера скорей всего нет вообще обязательной нужды в .ком
Либо если Вам надо показать свою древность(типа как раньше было для этого пятизнак аськи) то .ком будет показывать что Вы типа чуть дольше на рынке.

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

pro дороже