Что хотел спросить-то. Имеет ли смысл синергия условных Django и React (Vue)? Если да, то как она должна выглядеть? Или кругом уже давно сплошные SPA? Прохладные истории приветствуются

Смысла ноль что-то вроде HTML генерить Питоном. Юзай Django или Django REST Framework и генерируй ими JSON. Больше ничего не нужно.

Возможно тебе понадобится Node.js/Webpack на сервере, чтобы работал SSR (server-side rendering). Гуглить по «ssr vue» и «ssr react». Мануалов тонны.

всё зависит конечно от аудитории на которое это рассчитано и какие возможности твой сервис предоставляет, но если есть возможность использовать ресурс без потери функционала отключив JS это большой плюс. Если смотреть на разработку с такой стороны то это должен быть гибрид и шаблонов и Vue/React. Не загрузился JS ну и ладно, просто меньше интерактива, больше POST/GET.

Есть ли смысл писать сразу на Django и React?

Нет смысла писать на Django.

Нет смысла писать на React.

Нет смысла писать. Всё тлен.

Имеет ли смысл синергия условных Django и React (Vue)?

Имеет. Главное, что не php)

Тебя волнует мнение сферических хипсторов? Пиши как считаешь правильным, лишь бы юзеру было удобно.

Или кругом уже давно сплошные SPA?

Нет, spa это очень узкий круг задач. А вот злоупотребление клиентскими ресурсами кругом давно, да.

Да пиши ты основу по-старинке, потом Vue интегрировать будет не сложно. Vue поддерживает такой же режим работы, как jQuery, когда шаблон для Vue собирается на сервере, и уже сам Vue в браузере его компилирует в js код, но смысла в этом не много, но такая возможность есть, и мы ей не однократно пользовались в проекте, года 2 назад.

Скорее волнует скорость загрузки странички. Получать html, потом превращать его в VDOM всяко медленнее, чем собрать всё это вебпаком в один блоб. Но если собрать блоб, то непонятно с какой стороны прикручивать Django

но такая возможность есть, и мы ей не однократно пользовались в проекте, года 2 назад

А для каких целей пользовались, если смысла в ней немного?

Мы переводили проект на Vue, тогда он был в новинку и мы плавно, часть за частью переводили на единый spa, постепенно наращивая возможность, тогда ещё и vue template compiler то не было, были только разговоры об этом, вроде, что будем всё писать в .vue файлах.

Django прикручивай как rest с json, которые будешь рожать из query (бд), но в джанге все любят админку и джанго формы, а тут придётся всё ручками от Vue обрабатывать.

Особенно на JS.

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

Нет. SSR нужен сейчас только для B2C (дохлые мобилки, SEO и т.д.), учитывая его дополнительную сложность. Если нет весомых поводов использовать SSR, то его не надо использовать, потому это 1000 способов выстелить себе в ногу и сразу не заметить.

Еще существует prerendering - гораздо более простая альтернатива SSR, чтобы получить рабочий SEO

превращать его в virtual DOM и делать какой-то интерактив на блестящих новеньких фреймворках, типа React или Vue

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

Или кругом уже давно сплошные SPA?

нет. любой классический серверный template engine с 100% рендером страницы на сервере на каждый реквест - это все еще может быть отличным решением. лендинги, сайты мелких компаний, википедия, ЛОР, и т.д., - для всего этого «старый способ» все еще абсолютно работоспособен и нет предпосылок, чтобы он устарел

делать простой сайт на 5-10 статических страниц на реакте с SSR - это как делать кластер на Hadoop, чтобы разместить 50МБ данных

Vue принципиально не отличается от реакта. Для человека, который не писал ни на одном, они покажутся одинаковыми, если использовать JSX

браузере брать нагенерённный сервером html, превращать его в virtual DOM и делать какой-то интерактив на блестящих новеньких фреймворках, типа React или Vue

НИКОГДА не делай так если ты не до конца понимаешь что делаешь.

Если ОЧЕНЬ хочется — берёшь react на бэкэнде, им генеришь html, передаёшь браузеру. Аналогично с vue. Это ничерта не тривиально повторять в джанге. Первая же трабла, с которой ты столкнёшься, если попытаешься взять отрендеренный джангой DOM — это решето в angular1-стиле: джанга без понятия о том, что опасно, а что нет для UI-фреймворка и как всё экранировать. Это уже когда ты реализуешь минимальную гидрацию HTML, что не сильно просто.

С другой стороны, меня мучают подозрения, что хипстерыникто уже не работает со статическим html в браузере. Вместо этого, весь html превращается в js на этапе сборки сферическим Webpack-ом. А в браузер приходит пустая html-страничка и пачка js-блобов, генерирующих контент

SSR — это не тривиально и не бесплатно. Нужно быть уверенным, что тебе нужен SSR (а не, скажем, пререндеринг) прежде, чем его пилить. Пилить межязыковой SSR — та ещё идея.

Или кругом уже давно сплошные SPA?

Да.

Если не устраивает сплошное SPA (почему?) — ты можешь пользовать react/vue «на правах jquery»: как виджеты, встраиваемые в HTML (скажем, для форм). Это вполне ок, хотя и недостаточно хипстерски.

В общем,

• Джанга + реакт — вполне ок, но обычно джанга в таком случае не рендерит HTML вообще, а служит rest (или graphql для хипстеров)-бэкэндом. Ну, не считая тривиального «вытащить хэш из webpack-loader в html».
• Никогда не смешивай 2 разных типа шаблонов в одном месте. Вообще, на одной странице одновременно и сервер-шаблоны, и клиент-шаблоны встречаются в основном при медленном перепиливании (например, с первого на второе) либо при встраивании готовых компонентов. При этом:
  • Отрендеренный бэкэндом HTML обязан быть непрозрачным блобом для фронтэнд-фреймворка. Его нельзя парсить, можно только взять и вставить в нужное место.
  • Аналогично: весь UI-слой фронтэнд-фреймворка обязан быть непрозрачным блобом для бэкэнд-шаблонов. Фронтэнду можно передать настройки, но идея, скажем, писать JSX джангой (и компилить на клиенте) — ужасна, хоть и технически реализуема.
  • Если хочешь SSR с джангой — работай с нодой из джанги. Где-то тут возникнет вопрос «а зачем тут вообще джанга?». Хотя SSR-руты могут быть отделены от API-рутов, тогда джанга опять же не будет иметь понятия ни о ноде, ни о html.

Есть что-то подобное в rails. Командой rails webpacker:install:vue добавляет vuejs вместе с webpacker в asset pipeline.

Вот тут можно посмотреть https://mkdev.me/posts/rails-5-i-vue-js-kak-perestat-muchatsya-s-frontendom-i...

http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/

Версия уже зарелизилась. Сейчас 5.1.6.

Если есть вопросы можешь спрашивать

но если есть возможность использовать ресурс без потери функционала отключив JS это большой плюс.

что, прямо совсем без потери?

Твои доводы понял. Спасибо

Если не устраивает сплошное SPA (почему?)

Как бы объяснить.. На страничке всегда есть контент, который хоть и зависит от текущей сессии (например, информация о пользователе, всякие счетчики), но не будет меняться пользователем в рамках работы с SPA. И такого полустатичного контента, ИМХО, обычно больше чем, интерактивного. Нет никакого смысла запрашивать его через REST и рисовать через vue/react - намного проще отдать отрендеренную джангой модель. А уже интерактивным контентом управлять через vue.

Отсюда возникает большой соблазн отдавать джангой отрендеренный html с вкраплениями кастомных тегов:

<!-- Тут обычный html -->

<my-vote caption="Кто громче топает" -->
  <my-item icon="sonic.bmp"> Ёжик </my-item>
  <my-item icon="bear.xpm"> Мишка </my-item>
  <my-item icon="er.ico"> Единая Россия </my-item>
</my-vote>

<!-- И тут обычный html -->

Натравить vue на «body» и пусть он сам выискивает кастомные теги и делает с ними свою магию:

var app = new Vue({
  el: 'body',
  data: { /* Some data */  }
})

Нет. Через 1.5 года всё выкинут на помойку.

И что будет?

Правильно я понимаю: в шаблоне рельсов указываешь места на странице, куда будут вставленны vue/react блобы, предварительно собранные вебпаком?

Пришло время переписать веб проект. Веб проект сам себя не перепишет.

Да.

Здесь можно посмотреть как это работает https://gorails.com/series/using-vuejs-with-rails

https://github.com/gorails-screencasts/gorails-episode-184

Мы делаем так и нам нравится

Например, у нас есть редактор форм (который есть vue-component)

С сервера отдаём настроенный компонент

<script src="/js/our-form-editor.min.js">
<form method="post" action="/web/form-editor?form_id=c6abff8da83ac3aea972e51a7e21d01a">
  <our-form-editor
    v-bind:fields="[...]" <!-- Здесь делаем to_json в шаблоне серверного фреймворка -->
  ></our-form-editor>
  <button type="submit">Сохранить</button>
</form>

Остальной контент статический.

А body - это vue-приложение, которое связывает все динамические компоненты на странице. our-form-editor умеет добавлять/удалять/итд различные поля в форме. Когда жмём «сохранить», у нас уходит обычный POST на сервер. Ошибки можно выкидывать в window.validationErrors = {...}, а в компонентах собирать.

Но как и всегда, везде есть плюсы и минусы.

Сейчас становится модно делать Server-side rendering

https://ssr.vuejs.org/ru/

Значит мои мысли не совсем извращение)