nomta

Ты не правильно используешь. https://docs-lodash.com/v4/debounce/

Но бесит, что там нет единого собранного файла bundle.js

В шаблоне webpack-simple все скрипты собираются как раз в один файл build.js. Обратите внимание, он подключается в сгенерированный index.html. vuejs-templates/webpack-simple.

Этот файл недоступен в файловой системе при запуске dev сервера, потому что в режиме разработки он находится исключительно в памяти.

так он еще создает кучи других непонятных файлов и при режиме разработки запускает ненужный 'hot-load'.

Давайте разберемся, для чего нужен сервер в режиме разработки для Vue. При написания SPA приложения вы используете кучу библиотек, файлов в разных форматах и возможно еще обращаетесь к стороннему API(например twitter). Плюсом, вам хотелось бы использовать транспайлер, чтобы в js можно было красиво писать стрелочные функции и использовать другие вкусняшки ES2015. А еще это здорово было бы склеивать файлы одного формата в один большой для разных оптимизаций. Плюс, после того как вы измените что-то в одном файле, не пришлось бы тыкать каждый раз на перезагрузку страницы. Примерно эти вещи делает за вас dev сервер с webpack в режиме разработки.

— с помощью webpack вы можете собирать ваши файлы каким угодно образом и складывать их в любое удобное место в фс.
— вы можете их склеивать, минифицировать и использовать транспайлеры, препроцессоры, постпроцессоры и прочее.
— вы можете обращаться к стороннему API с локалхоста.
— если вам не нужен hot-load — отключите его в конфиге.

Оставить в покое django под портом :8000, а VueJS под :8080. И в nginx как-то слушать их обоих, раздельно, таким образом четко разделить фронт от бэка. Не будет ли проблем?

Проблем с проксированием nginx'ом? Не очень понятно что вы имеете в виду.

Если вам нужен кастомный шаблон vue-cli то вы можете легко его разработать один раз и в дальнейшем использовать: Vue-cli custom templates

Как правильно организовать структуру SPA + Backend

В целом, вопрос риторический. Это зависит от того, какая именно архитектура вам нужна и какие задачи будет выполнять ваш фронтенд и какие бэкенд.

Дело в том, что возникновение таких вещей типа SPA напрямую связано с разными парадигмами разработки. Django как фреймворк позволяет вам писать монолитные приложения. Вы пишете одно большое приложение где храните бизнес-логику, фронтенд, функции-хелперы вроде уменьшения размера загруженных картинок, etc. Деплоите монолитное приложение на одном сервере, возможно на отдельный сервер выносите базу данных.

Эта парадигма оправдана в определенных случаях, как и другие парадигмы.

В случае микросервисной парадигмы вы делите ваше приложение на много микро-сервисов. Давайте придумаем кейс, который может возникнуть в реальной жизни.

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

Ваше приложение схематически выглядит так:

Клиент: хочу авторизоваться => Сервер приложения: отправлю бизнес-логике => Бизнес-логика: спросим базу (данные для авторизации) => База данных: можно => Клиент: я авторизован

Используя другой подходе вы можете вынести ваш модуль авторизации пользователей в микросервис на отдельном сервере, уменьшив таким образом запросы к основной базе.

Теперь, в вашем фронтенде на Vue, например, вы можете отображать нужные вам данные (а соотв. делать запросы в основную базу), только если пользователь авторизован.

Теперь ваше приложение выглядит так:

Клиент: хочу авторизоваться => Фронтенд-микросервис: отправляю микросервису авторизации => Микросервис авторизации: можно => Фронтенд-микросервис: я авторизован, хочу данные => Сервер приложения: отправлю бизнес-логике => Бизнес-логика: спросим базу (данные отображения авторизованному клиенту) => База данных: данные => Клиент: я получил данные

Давайте теперь представим, что вам нужно быстро, а лучше сегодня набросать MVP для демонстрации инвестору или для проверки вашей концепции.

Авторизация? — микросервис — auth0.com
SQL База данных? — микросервис — Google CLOUD SQL
Уменьшаем размер картинок? — микросервис — AWS Lambda

Что получается в сухом остатке? Вам требуется лишь написать SPA из которого вы будете обращаться к вашим микросервисам. То есть, вы получаете приложение, которое можно хостить как статический сайт, переложив на микросервисы большинство задач, которые вам требуются в вашем приложении.

Конечно, это решает определенные проблемы, но и создает новые, поэтому, повторюсь, все зависит от ваших задач.

Давайте посмотрим на ваш пример с Django. Если я все правильно понимаю, то вы хотите использовать все плюсы Django, типа ORM, API доступа к БД, etc, заменив лишь систему шаблонов на Vue?

В таком случае, на мой взгляд, вам нужно реализовать на Django классический REST API и из SPA на Vue обращаться к endpoint'ам вашего API.

Ссылки по теме:
Архитектура микросервисов
SPA-архитектура для CRM-систем: часть 1
SPA-архитектура для CRM-систем: часть 2
AWS Lambda и никаких серверов

Нет,
server side rendering
и
single page web app
Это в корне противоположные подходы по написанию приложения.

В первом - абсолютно все (за исключением только что анимации) формируется на сервере бакэндом на любой чих, т.е. значение перменных состояния (например значения фильтров в поисковом запросе) передаются в виде ссылки на страницу, закодированные с помощью & = и %код_символа. Благодаря этому возможен переход по истории действий средствами браузера, так как каждое изменение состояния - новая ссылка

Во втором подходе используется обратный процесс, все что относится к интерфейсу переносится на клиентскую сторону, т.е. страница формируется (или только правится, если это шаблон) с помощью javascript, состояние сохраняется в локальных переменных, а данные запрашиваются с помощью ajax в компактной форме (бакэнд выдает простенький json). В этом подходе с точки зрения браузера все приложение это одна страница, и переходы по истории вперед назад не работают. Но есть хак, состояние можно кодировать в ссылке на страницу, с использованием анчор #. Это стандарт, позволяет задавать точки перехода по странице (например параграфы или страницы), без перезагрузки всей страницы, но с поддержкой истории переходов.

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

Ставите ref на прокручиваемый элемент, и читаете/назначаете его scrollTop.

Можете глянуть freecodecamp, целый раздел посвящен es6.
Так же можно просто писать знакомые задачи с возможностями es6+
Ps вот кстати статья, мало ли: ES6 по-человечески

https://www.npmjs.com/package/postcss-import
https://www.npmjs.com/package/postcss-nesting (https://www.npmjs.com/package/postcss-nested)
https://www.npmjs.com/package/postcss-advanced-var... (https://www.npmjs.com/package/postcss-simple-vars)
https://www.npmjs.com/package/postcss-mixins
Это базовые возможности
А так то легко можно найти нужные плагины https://www.npmjs.com/search?q=keywords%3Apostcss-...
Можно только sass компилятором пройтись. Если не лень извращаться, то дерзайте. Главное самому себе обосновать такую необходимость.

попробуйте так

Лично для меня Vue - это такой "фреймворк с человеческим лицом".
В целом JS-мир похож на поле боевых действий, где постоянно то налеты авиации, то кононада гремит, то хипстерская конница с новым логотипом на знамёнах проскачет.
А "обычный" человек сидит в подвале, обхватив голову руками, и думает - мама дорогая, куда я попал, и чё ваще вокруг происходит?
Какие-то новые паттерны, подходы, языки... Раньше, чтобы начать, достаточно было блокнота и браузера. Пишешь hello world и сразу его видишь. Теперь нужно поставить ноду, овер 9000 пакетов, десять транспиляторов, таск-менеджеров и бандлеров. Пока увидишь рабочий результат - поседеешь.
И вдруг какая-то добрая душа взяла у хипстоты всё самое лучшее и разумное, что та родила, но очистив от лишних абстракций и усложнений - и выкатила велосипед в виде велосипеда, а не турбо-космолета с инструкцией толщиной как "Капитал". И снова можно писать в блокноте и смотреть в браузере. При этом почти не проигрывая в возможностях.

if ('IntersectionObserver' in window) {

    let config = {     
        root: document.querySelector('#scrollArea'),   // если не указывать, root это viewport
        rootMargin: '0px',   // '10px 10px 10px 10px' отступы будут включены в зону отслеживания пересечения. Observer вызовет калбэк за 10px до пересечения секции c любой стороны root. 'px' обязательны.
        threshold: [.0,.1,.2,.3,.4,.5,.6,.7,.8,.9,1]  // вызывать калбэк при пересечении каждых 10%. [0] для вызова калбэка один раз при первом пересечении
    };
    
    // заводим observer с обработчиком и конфигом
    sectionObserver = new IntersectionObserver(onIntersection, config); 

     // прикручиваем созданный observer на нужные элементы    
    let sections = document.querySelectorAll('section');
    sections.forEach(section => {
        sectionObserver.observe(section);
    });

    // обработчик observer
    function onIntersection (entries, self) {
        if (entry.intersectionRatio > 0.5) {
            // секция пересекла observer's root на 50%
        }
    });
}

Можете попробовать эту библиотеку:
BackgroundCheck
Вот пример с фиксированным элементом и скроллом:
Пример

В самом простом случае тебе нужен nunjucks.
А так можешь использовать сборку типа blendid, там уже есть nunjucks, есть browsersync так что можно быстро и удобно верстать.
У blendid только в Винде небольшой баг(хотя это не у него, а у gulp/yarn), поэтому в package.json можно добавить:

,
   "scripts": {
    "start": "yarn run blendid",
    "build": "./node_modules/.bin/blendid -- build"
  }

Ну и тогда yarn start запустит сервер разработки(browsersync), а yarn run build соберет проект.
Ну и да для всей движухи нужно установить ноду и сам yarn