NikSIk31, а тут дело совсем не в крутости или отсталости, на самом деле. Я вижу такие преимущества SPA-сайтов (я не конкретно про свой говорю, потому что разрабатываю его один, а вообще):
Бэкенд становится проще, потому что является обычным API - проще тестировать
Нет необходимости пилить отдельные API для мобильных приложений, потому что можно использовать то API, с которым взаимодействует фронтенд
Фронтенд полностью отделен от бэкенда, что позволяет фронтенд- и бэкенд-разрабам заниматься своими задачами независимо. То есть нет необходимости в fullstack-разработчиках
Возможность полностью переделывать фронтенд и бэкенд независимо, в том числе и переписывать бэкенд с пхп(например) на что-то другое, не трогая фронтенд вообще никак.
Возможность без боли использовать современные и удобные фронтенд-фреймворки, которые вкорячивать в не SPA-сайты бессмысленно и неудобно
Сайты в виде SPA работают приятнее, на мой взгляд, потому что нет перезагрузки страницы после почти любого действия. Везде можно все обвесить красивыми индикаторами загрузки, размытиями фона и т.п.
Если говорить о фронтенд-разработке, то в большинстве сайтов без SPA юзают jquery. С одной стороны, почему и нет. Но, с другой, когда на фронте усложняется какая-либо логика, поддерживать всю эту лапшу становится просто невозможно. Переписать нормально тоже не представляется возможным.
Насчет Тостера ничего не скажу, отталкиваюсь исключительно от своего опыта. К тому же везде по-разному. Гигант-Тостер не использует спа, а не менее гигант-Медуза использует, так что это совсем не показатель. :)
NikSIk31, добрый день! Не очень понял, когда именно происходит перезагрузка. При переходе на статью из общего списка перезагрузки нет (в браузере не вращается индикатор загрузки страницы). Если Вы имеете в виду переход по ссылке в тексте статьи - да, такая проблема есть, там, действительно, происходит перезагрузка.
Дело в том, что для работы таких ссылок без перезагрузки страницы, их надо парсить их текста статьи на стороне фронтенда и рендерить как react-компоненты (сейчас это обычный тег ). А текст статьи вместе с такими ссылками у меня сейчас приходит с сервера и вставляется в страницу полностью с помощью dangerouslySetInnerHTML без какой-либо обработки в js.
Ivan Yakushenko, интерпретатор Питона потребуется, pip потребуется. Возможно, и Virtualenv. Можно установку всего этого вшить в bat-скрипт, но это как-то так себе, мне кажется. Вообще есть, вроде как, утилиты, которые умеют питон с зависимостями упаковывать в исполняемый файл, но я не пользовался - не могу ничего сказать.
habrahabraman, если кода мало достаточно, я бы это на го переписал (если это более-менее выгодно и не сильно запарно). Не потому, что я этот язык люблю, а просто на выходе получаешь бинарь, который заказчик даблкликом запустит - и ничего доустанавливать ему не придется.
Евгений Вольф, но в таком случае не очень понял, почему Вам тогда Yii2 не угодил? Он ведь ничуть не сложнее, чем Codeigniter. Какое у Codeigniter весомое преимущество, позволяющее Вам делать вывод, что Yii2 родился мертвым? Я, если что, давно не пользуюсь ни тем, ни другим - просто любопытно.
Евгений Вольф, шаблону проектирования можно учиться и на нормальных фреймворках. В этом смысле даже Yii2, который Вы почему-то не советуете, на мой взгляд, подходит больше. Там хотя бы неймспейсы используют. И тоже MVC-шаблон, кстати.
Codeigniter хорош тем, что там минимализированы "правильные подходы"
Если во фреймворке не используются стандарты того языка, на котором он же сам и написан, то и правильность остальных подходов вызывает сомнения. Следование шаблону MVC - это не единственный фактор, делающий фреймворк "правильным".
Сделай так, чтобы у компонента картинки был свой стейт - и в toggleBio (этот метод засунь в этот же компонент картинки) меняй его. id тебе туда передавать не нужно. Судя по всему, ты пытаешься менять стейт, который относится к компоненту со списком картинок.
Saboteur, решений для многопоточного бэкенда - да, но какие из них НОРМАЛЬНЫЕ (как автор уточнил в формулировке вопроса), кроме java и .net? Go/Rust? Может быть, но пилить на них большие сайты очень долго и неудобно. ORM под го вменяемых нет (Gorm кажется удобной только на первый взгляд). Да и сам Go, как язык, весьма своеобразен, да и фреймворков реально хороших тоже нет. Берешь Gin/Gonic - и тут же начинаешь писать issues в Github, потому что то одно не работает, то другое (и дело вовсе не в кривых руках, уверяю Вас, просто сыровато все).
Понимаю, что вопрос еще вряд ли актуален, но все же: можно делать сборку в GitLab при деплое, создавать после этого артефакт (архив с кодом) - и его разворачивать на сервере. То есть сборка будет идти непосредственно в GitLab. Если что-то поломается на каком-то из этапов, весь процесс прервется.
P.s. пока то я делаю так, как у тебя, но я это собираюсь тоже переделывать. Если ты нашел за полгода какое-то годное решение - делись :)
FanatPHP, еще раз: мне эта информация зачем? Это разговор слепого с глухонемым. Я нигде вообще не писал про ручную обработку каждого запроса, поэтому Ваш комментарий, как и предыдущий, не имеет смысла. Я не думаю, что Вам стоит учить меня разработке, поэтому желаю удачи!
Если говорить о фронтенд-разработке, то в большинстве сайтов без SPA юзают jquery. С одной стороны, почему и нет. Но, с другой, когда на фронте усложняется какая-либо логика, поддерживать всю эту лапшу становится просто невозможно. Переписать нормально тоже не представляется возможным.
Насчет Тостера ничего не скажу, отталкиваюсь исключительно от своего опыта. К тому же везде по-разному. Гигант-Тостер не использует спа, а не менее гигант-Медуза использует, так что это совсем не показатель. :)