Дмитрий Кулаков

Используйте 2 тильды

~~зачеркнутый~~

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

Стандартные решения:
1. самодокументируемый код, составленный так, что читающий может понять что для чего и в какой последовательности работает.
2. описание интерфейсов (назначение метода, тип/суть параметров и т.п.) в форме комментов в коде.
3. автоматическая документация (генерится из комментариев) - эффективно, только если сам код закрыт.
4. модульные тесты, фиксирующие требования к коду и демонстрирующие его использование.
5. описание высокоуровневого дизайна (High Level Design, HLD), описывающий какие элементы существуют, их взаимосвязь друг с другом и основные сценарии взаимодействия.

Работающая документация - это компромисс из этих практик, релевантный конкретной ситуации.

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

Если тебе просто нужно получить данные о странице - можно воспользоваться и таким методом. Если же ты хочешь использовать эти данные для динамического изменения адреса страниц и тд - то предпочтительнее пользоваться библиотекой.
Смысл в том, что React - это по сути одна большая абстракция, построенная над домом. Если начать вылезать из абстракции на более низкие уровни - то она начнет протекать. Таким же образом можно и события вешать на addEventListener, но React не рекомендует это делать, так как для обрабатывания событий там имеется готовый инсрументарий

word_with_comma = [word for word in words if ',' in word]

Описанная тобой схема, при которой приложение разбито на две части: клиентское на JS и серверное, которые обмениваются данными через открытое API по HTTP - называется Rich Internet Application или Single Page Application. Реализуется на любом стеке. PHP/Python/NodeJS/Ruby/Go/C#/Java и др. с одной стороны и Vue/Angular/Meteor/React и др. (тыщи их) с другой стороны.

(Упомянуя схема "микросервисная архитектура" по сути декомпозиция серверной части на незаввисимые модули с открытым API, совсем не обязательно реализовано через HTTP. Частный случай SPA/RIA.)

Проблему назову одну. Только она не даёт покоя. Она выматывает душу, нервы и кошелёк.

Интернет магазин должен быть открыт для индексации поисковым ботам, а HTML генерится в runtime на JavsScript. Только Google умеет выполнять JS, и то весьма посредственно. Остальные вообще JS не трогают. Есть два решения:
для индексации сразу рисовать HTML на стороне сервера
или снимать "отпечатки" HTML c приложения через виртуальный браузер, что сбоит

Отрисовка HTML на стороне сервера (server side render) может быть реализована тремя способами:
* подменять выдачу через серверный язык программирования, то есть вместо шаблонизации в Vue рисовать в Falcon - блин, две шаблонизации, две логики работы с данными (через AJAX и напрямую из базы)
* имитировать исполнение JS на сервере (хм, это возможно опять же несколькими способами) - тут вообще танцы с бубном
* отказаться от PHP/Python/Ruby и др. в пользу NodeJS и изоморфного фрейморка, например MeteorJS или VueJS (Nuxt)

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

P.S. Про Google: проверено, глючит в тех местах, где клиентский JS начинает подкачку данных через HTTP - гугль обрывает рендеринг и в поисковом индексе лежат пустые HTML страницы. Толку от них никакого.
P.P.S Снятие "отпечатков" HTML для SPA можно через специальные сервисы (prerender.io или brombone.com) или сделать самостоятельно, например через PhantomJS или Electron. В любом случае для проекта с десятком тысяч страниц это расходы на оплату сервиса, либо на мощный сервер. И электрон и фантом виснут, а HTML довольно большие и со временем забивают диск/базу. Опят же надо не забывать про то, что страницы требуют подгрузки данных через AJAX, надо чуть подождать.
Пример: web-mastery-gauge.ru сделан на Angular, для поисковиков HTML отрисовывается через prerender.io - для проекта с 15 страницами это вообще никакой сложности не вызывает.
P.P.P.S. SPA просто идеально для реализации той части пользовательского интерфейса, которая не индексируется поисковыми ботами. Например, то доступно только авторизованным пользователям. В этом случае не требуется server side render и 75% проблем отпадают. В том же интернет-магазине может быть админка - её можно сделать на VueJS.