index0h

Очень вероятно - кэши и логи в var/. На их синхронизацию уходит куча времени.
Под вагрантом рекомендую отключить автоматическую синхронизацию проекта и делать это из IDE по факту изменения файла.

1. Фронт - это пользовательский интерфейс к бэкенду. Если в проекте визуальная часть - основная, ваше утверждение верно, в противном случае - нет.
2. Да
3. Если у вас не используются данные, которые необхрдимо держать в секрете - почему нет?
4. Не факт что упростит. А вот аграничит ваши возможности - да.
5. Если юекендщика у вас нет И некий baas вас устраивает по функциональности И требований по безопасности данных у вас нет - юзайте baas. В противном случае лучше свой бэкенд.

Moodle

На сколько эффективно использовать ложку? Для супа - очень, для перемешивания бетона - неочень.

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

Уже был подобный вопрос с такой же ошибкой. Задача определяет язык. Является ли проект api сервером, или нет - это не важно. Важно, какие звдачи будет решать ваш сервер.

который будет содержать и отвечать на ~ 100 различных методов

Этот комментарий абсолютно без информативен.

Какой язык программирования наиболее подойдет, чтобы сделать это быстро?

Скриптовый. Но какой именно - зависит от тз.

Чтобы это было оптимально по расходам для бизнеса в целом?

Ответить на этот вопрос можно исключительно на основании тз.

Чтобы накладные расходы были минимальными (на сервера, на людей и т.д.)?

Так не бывает. Либо вы будете платить больше за сервера, либо больше за инженеров.

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

Откуда здешним знать, что вам будет понятно, а что нет?))

Книгу подбирают по себя. Заходите в магазин, юерете любую на 700+ страниц, открываете по средине, читаете абзац. Если вообще не понятно, о чнм там - книга не подходит, берете другую и так же проверяете

Нет, месенджеры - это часть процесса разработки. В моем случае по крайней мере.

Переформулирую ваш вопрос:

Готовим на плите, с четырьмя комфорками.
Хочется поменять вкус еды.

Подскажите пожалуйста какие приправы выбрать или хотя бы к каким присмотреться?
Как вообще происходит готовка с приправами?
Каких ошибок стоит избегать?

-- --

CMS/Фреймворки/... - это инструменты для решения конкретных задач. Выбор инструмента базируется на том, какие задачи вы собираетесь решать.

Трафик 50к в день - это чего 50к? Запросов, гигабит, регистраций, платежек, стримов, публикаций, транзакций.
Для оценки трафика с технической стороны есть 2 основных метрики: RPS (Request Per Second) и *bit/s (количество бит в секунду)

Делайте маленькие интерфейсы. Например сервис регистрации пользователя на вход принимает dto и реализует внутри кучу логики, но у этого сервиса интерфейс из 1 метода. Безусловно, внутри может юзаться и 5 и 10 и щещ больше не экспортируемых, это ок, но работать с таком сервисом будет очень просто, да и тестировать другие штуки, использующие его будет проще.

Не делайте сервисы с изменяемым состоянием, на сколько это возможно конечно.

Старайтесь не использовать экспортируемые переменные пакета, это аналог глобальных переменных, а про их вред уже 100500 обзоров написано.

Грамотно разделяйте алгоритм по методам. Если ваш метод делает 2 крупных разных вещи - вероятно стоит разделить. Если одну крупную возможно разделять не стоит. По примеру с регистрацией: весь процесс от валидации, сохранении пользователя до подергивания сервисов отправки почты спокойно можно забить в один метод. К эмпирическим правилам в стиле метод не больше 20 строк - подходите с осторожностью, далеко не факт что разделение будет хорошей идеей.

www.lingscars.com

С/С++ актуален, у этого семейства огромнейшая экосистема.
На счет привычек: не всегда но часто стоит написать более медленный и простой для чтения код, чем быстрый но нечитаемый.
На счет правильности начала с крестов: у каждого языка своя реализация того же ооп и выучив один язык вы будете считать ооп именно этого языка самым правильным, но на самом деле вы будете работоать только с реализацией того же ооп, а не обобщенными принципами. У того же golang отсутсвует наследование но есть агрегация и встраивания, есть еще прототипное ооп как в js...

Может есть где большой выбор примеров сайта с цветами и прочими ништячками?

Если смешать 1 кг говна и 1 кг варенья, получится 2 кг говна, тут примерно так же.

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

Начнем с далека: PHP - PHP Hypertexp Processor.
То что вы называете "на фронте" называется рендеринг. Это можно сказать классическое использование пыхи. Фреймворки часто содержат функциональеость, которая не совсем ложится в парадигму SPA, как в вашем примере с формами.
Подобные нестыковки решаются исключительно за счет соглашений в конкретном проекте.

А чего он вдруг должен уметь в сеть?)) Скачайте ваш злосчастный файл и парсите на здоровье с локальной файловой системы. Через сеть бы происходило тоже самое, но неявно.

KDB+