skepsikmod

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

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

Поэтому теперь я отдаю фронтенд тому, кто умеет делать это быстро и качественно. Сам я трачу свое время более эффективно и зарабатываю больше (так как я сосредоточен на том, что мне интересно и в чем я развиваюсь очень давно).

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

Описанная тобой схема, при которой приложение разбито на две части: клиентское на 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.

Миксины .make-row() и прочие я использую, только чтобы сгенерировать альтернативную сетку. Например, параллельно стандартной 12-колоночной нужно использовать 5-колоночную с увеличенным гуттером.

В остальных случаях пишу классы «row», «col-*» и прочие бутстраповские сразу в вёрстке, мне так удобнее. Потому что нужно сбалансировать сложность в HTML разметке и сложность в CSS коде. Рассмотрим крайности.

1) Если каждому блоку в разметке писать уникальный класс, а потом в CSS миксинами накидывать rows, cols и прочие свойства из фреймворка, то в HTML сложность понижается, ведь у нас на блоке всего один класс, зато в CSS сложность резко вырастает: чтобы исправить баг, верстальщику придется бегать по миксинам, анализировать зависимости, чтобы не поломалось в другом месте. При этом растет размер CSS файлов: стили для модульной сетки повторяются в разных селекторах (дублирование кода), а верстальщику для каждого нового блока приходится придумывать новое уникальное имя класса. Два внешне похожих блока имеют 90% одинакового кода и этот код повторяется два раза. Такая ситуация называется «css bloating» (css наводнение).

2) Противоположная ситуация называется «html bloating»: когда в стилях создают простейшие классы типа .colorred, .fontsize14, fontweightbold, .padding20 и т.д., а в разметку на каждый тег кидают по 10-20 таких классов, пока блок не будет выглядеть как надо. В этом случае в CSS очень низкая сложность, нет никаких конфликтов, размер файла невелик. Но если дизайн хоть чуть-чуть поменяется, верстальщику придется переписывать классы на каждом тэге. Вся сложность из стилей ушла в разметку.

В первом случае (css bloating) у нас 100% отделение внешного вида от разметки. Это вроде бы хорошо, блоки выглядят независимыми, но достигается это высокой ценой: большой риск сломать что-нибудь, внося правки в миксины; повторения в коде и в результате обязательный gzip стилей. В чистом виде можно использовать, когда нет доступа к html-разметке: один и тот же виджет используется на разных сайтах и должен выглядеть по-разному, менять ему html опасно.

Во втором случае (html bloating) внешний вид смешан с разметкой (это лишь чуть-чуть лучше, чем инлайн styles) и даже самое маленькое изменение в дизайне влечет кучу тупой работы по перестановке классов в html, но зато в css конфликтовать нечему. Пожалуй, в чистом виде может встречаться в веб-приложениях, когда верстка генерируется через js-шаблоны (тупая работа автоматизирована). Отлавливать css баги в динамичной верстке приложений очень сложно, поэтому есть смысл увеличить прочность стилей, перенеся сложность в разметку.

Оптимальный вариант — распределить сложность примерно поровну между стилями и разметкой — «multiple classes». На каждый блок вешать 3-5 классов, которые отвечают за модульную сетку, геометрию, скин этого блока. Соответствующие классы можно переиспользовать в других блоках. Классы Bootstrap'а хорошо справляются с модульной сеткой и частично с геометрией, а скины и геометрию собственных компонентов верстальщик дописывает сам.

В БЭМ баланс сложности смещен в сторону css bloating: блоки должны быть независимыми, их нельзя смешивать, можно лишь вкладывать друг в друга, а значит увеличено количество повторений css кода.

В OOCSS баланс смещен в сторону html bloating: пишут больше мелких, но переиспользуемых конструкций, имена классов придумывать сложнее, т.к. они должны быть достаточно абстрактны, но всё ещё показывать, что этот класс делает.