DevMan

jsfiddle.net/yjkmxmtt/3

для того чтобы твое воображение позволило тебе делать все что вздумаеться

Циклы\условия и т.д - это обычные конструкции которые необходимы в любом коде. Их просто не могли не придумать.

Посмотри как пример функциональные языки (Haskell, Erlang), там другая философия.

Токен можно передавать и в заголовке, не обязательно выводить его в формы. Но в целом - это самый распространённый способ, который прост как тапок и работает.

если, вдруг, понадобилось вернуть всё обратно, в голову приходит только такой вариант:

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

обратите внимание на подчеркивания в меню ctrl+alt+j. если нажать на клавиатуре первую букву аббревиатуры шаблона, будет применён конкретный шаблон из списка. так что название выбирайте так, чтобы было удобно нажимать его первую букву.

Да. 2y - метод
А вообще читайте мануал. там чёрным по-русски написано про это

Горлышко бутылки - это сам Selenium. То, что на питоне и джаве - это обвязка, которая, хоть и будет работать на джаве быстрее, не даст никакого прироста.
Согласись, разницы нет, сработает обвязка за 50 микросекунд или за 10 микросекунд, если сам Selenium будет грузить страницу 1 секунду?

Создаете несколько разделов server, в одном listen ip1:80; а во втором listen ip2:80;
Ну и для SSL соответственно, если используется.

php.net/manual/ru/migration70.incompatible.php

Чувак, идешь сначала сюда https://learn.javascript.ru/
Пока Илья с товарищами по команде тебе надоедают, учишь английский.
Потом переключаешься на бритоголового https://egghead.io/
Потом, если покажется мало, начнешь курить спеки. К этому времени уже освоишь гугл и сможешь сам их найти.

Лучшие практики SPA

1. KISS - использовать только то, что действительно нужно. Например вам не нужен Javascript, если нужно просто сделать выпадающее меню. Достаточно просто CSS. Тоже самое применяется и к JS, вам не нужен Angular, если есть просто форма обратной связи. Такая задача решается на vanillajs.
   
2. Использование фреймворков, например bootstrap, foundation и т.д. Обычно из них берется типография и сетки. Иногда формы. Я обычно беру bootstrap-stylus и собираю из него.
   
3. Critical rendering path - минимальный набор CSS, который требуется для отображения первого экрана страницы, который потом будет встроен внутрь html-файла. Пример.
   
4. Применение систем сборки, например gulp. Основной смысл заключается в том, что сначала вы дробите SPA на множество мелких компонентов/модулей/блоков. Затем унифицируете их. В итоге получается набор небольших файлов. Затем из этого набора собирается два больших файла (css, js) и они прогоняются через оптимизатор и минификатор.
   
5. Использование CDN. CDN позволяет ускорить загрузку для часто-посещаемых и популярных страниц за счет уменьшения времени доставки контента. Особенно актуально для SPA, поскольку они представляют собой статический контент, который можно кэшировать без последствий.
   

Системы сборки

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

Модули AMD, CJS, UMD

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

Сборка и подключение css

Здесь и так ясно, что нужно сначала освоить сборщики. postcss - это когда обычный css скармливается фильтру, который разбирает его, добавляет префиксы к свойствам, оптимизирует наименования цветов и т.д. Убирает дублирующие свойства.

В целом очень толково про оптимизацию расписано здесь https://developers.google.com/web/?hl=ru

Никак не надежна.

Возможность подмены IP есть, и она не теоретическая, а практическая.

Да, нужен VPN

Дисклеймер: я не системный архитектор, и даже не знаю, кто конкретно должен так называться, наверное это что-то вроде технического директора.

Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?

Да, чрезмерно. Архитекторы (как вы их называете) не боги и даже не "вторые после бога".

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

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

Опять же, отрасль очень бурная - когда успевать работать и следить за всем, что в ней происходит?

А надо уметь главное выделять. Ну к примеру, вот позавчера анонсировали докер на винде на нативных контейнерах. Что нужно знать хорошему техническому директору? Что в 2016-й винде есть контейнеры (причём двух видов, настоящие и поверх hyper-v), что докер теперь будет их использовать со всеми вытекающими. Само собой нужно представлять что такое контейнер и чем от отличается от ВМ. Вот и всё что нужно знать, ну и посматривать за отзывами первых, кто осмелится опробовать технологию в деле.

Ну или вот возьмём TypeScript. Не обязательно писать на нём или знать его досконально. Достаточно понимать, что такое статическая типизация в языке, и уже можно будет представить разницу между использованием в большом проекте ES5/ES6 и TypeScript. Достаточно принять решение опробовать его у себя (как сейчас делаем мы) на небольшом куске проекта, и сделать вывод о дальнейшем использовании.

Возьмём, наконец, базы данных. Не думаю, что хороший "архитектор" обязан знать, что в какой-нибудь Монге какие-нибудь запросы с агрегацией по двум свойствам работают в 5 раз медленнее, чем по одному свойству. Однако то, что в Монге нет атомарной записи сразу нескольких документов, знать очень полезно, я бы даже сказал, критично (иначе можно пытаться написать какой-нибудь биллинг на Монге вместо какой-нибудь реляционной базы, и сорвать пучок проблем).

Техническому директору проекта ("архитектору") гораздо важнее уметь правильно обрабатывать информацию, уметь снимать маркетинговую шелуху (вроде той, что была и есть с NoSQL от всех проблем и несчастий), спокойно реагировать на модные баззворды, и собирать библиотеку доверенных людей и информационных ресурсов. И важно знать о вещах, которые с течением времени не меняются, или меняются медленно и неохотно:

• для каких задач подходят функциональные языки, а для каких - ОО;
  
• что графовая СУБД как правило быстрее обрабатывает запросы на поиск с большой длиной цепочки;
  
• что утверждение из предыдущего пункта неплохо бы проверить на практике с конкретными СУБД;
  
• что веб-фреймворки бывают толстые и тонкие;
  
• какие сегодня есть вариации паттерна MVC;
  
• что сборка мусора это всегда накладные расходы и иногда не вполне предсказуемое поведение;
  
• что данные от пользователя нужно фильтровать, иначе в вашей системе найдут машину Тьюринга не там, где надо;
  
• что в информационной системе есть компоненты с разным уровнем доверия, равно как и сотрудники;
  
• что транзакции в СУБД придумали не для того, чтобы учебники стали толще.
  

Вам нужно сделать небольшой GUI для вашего python-скрипта. Для этого есть всякие tkinter, pyqt и иже с ними. Потом получившийся скрипт перегнать в .exe с помощью одной из следующих тулз: py2exe, cx_Freeze, pyinstaller. Лично мне очень нравится последний своей простотой.
Нет никакой кардинальной разницы в "упаковке" GUI-скрипта и безинтерфейсного - всего лишь тягается разное количество библиотек и модулей.