unclechu

Для начала нужно задаться вопросом: для чего вообще нужен SPA-фреймворк? Сокращённый ответ окажется краток: для декомпозиции больших сложных частей на более простые и понятные мылые (которые связываются между собой). В случае с лендингом, - едва ли вам нужен SPA ферймворк, только добавите боилерплейта (то-есть добавите сложности проекту, что противоречит изначальной цели фреймворка), да и jquery вам скорее всего тоже не нужен (разве что как обязательная зависимость для работы каких-то готовых интерактивных решений, слайдеров/галлерей).

Изучать какой-либо SPA-фреймворк или нет? Ну спросите себя, какого рода задачами вам хочется заниматься, хотите клепать лендинги? Или хотите работать в команде над созданием сервисов вроде того, на котором вы сейчас задали вопрос (т.к. тут уже применение парадигмы SPA будет уместно)?

В контексте сказанного попробуйте по пунктам ответить сами себе.

Вам нужно "мокать" данные от сервера, т.е. вам нужен некий временный http-сервер, который по указанным роутам просто отдаёт содержимое статических json-файлов. У вашего front-end приложения должен быть локальный конфиг, где указан путь до бекенда, туда, на момент разработки, вы подставляете свой псевдо-сервер, напр, http://localhost:9000/api, если вы используете webpack для сборки, то можно приспособить для этого webpack-dev-server, на своём опыте я так и делал, см. https://webpack.github.io/docs/webpack-dev-server.html, написав хэндлер определённого роута можете описать простую логику раздачи json-файлов или поищите готовые рецепты такого подхода. Можно описывать дополнительно в отдельном документе какой роут какого рода информацию должен отдавать для последующей передачи её бекендщикам для реализации в уже реальной серверной части.

Я считаю, что начать стоит с освоения UMD (по ссылке также имеются примеры jQuery-плагинов), т.к. на сегодняшний день сколько-нибудь сложный фронт-енд как правило не обходится без AMD или CommonJS. Хорошим живым примером будет jQuery UI.

Если это серверный js: https://www.npmjs.org/package/deep-extend

Можно объявлять локальные переменные внутри конструктора и оперировать с ними через getter/setter, которые объявлены методами от this опять же в конструкторе. Но вообще общепринято выделять используя нижнее подчёркивание в начале имени свойства (аналогично Python, там тоже нет настоящих приватных свойств). Если нужна «защита от дураков», — то тут поможет кнут и маны по «правилам хорошего тона».

Попробуйте посмотреть в сторону: gulp-ignore

В теории — можно программно менять данные сигнала и делать программный gain на канале — но это ж вычислительная нагрузка, звуков будет много (2D игра например).

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