Антон Швец

Зачем вам БЭМ в ангулар? У вас есть инкапсуляция, не усложняйте верстку в том месте, где это вообще не нужно. Разберитесь в проблемах, которые решает инструмент под лейблом БЭМ и задайте себе вопрос - зачем он в ангулар?

почти 4 года на удаленке после 12 лет офисного рабства. Началось с декрета, так и не смогла себя заставить вернуться в офис.
Распорядка дня нет, так как нет "графика работы". Может быть завал, когда сутками сижу за компом, проходя за день 50 метров по кухне до чайника. Бывает несколько дней полного отдыха. Во многом тут конечно дело в самодисциплине, можно научиться брать заказы и выполнять их равномерно без пиковых нагрузок.
Повезло с работодателем. Первые пол года работала с разными заказчиками с сайтов по фриланс-услугам. Было не весело - новички ценник там вечно сбивают до "ниже плинтуса", лишь бы урвать себе работу. попадаются "кидалы", попадаются неадекватные.
В какой-то момент устала, разочаровалась и решила найти официальную работу, но на условиях удаленки. Нашла на HH вакансию, проработала в конторе в штате почти год. Устала от графика 10-19 5/2 с внеурочными без оплаты, гонки за KPI, ощущения "ты вынужден делать все, что сказано, потому что ты тут работаешь".
Ушла на фриланс обратно. Но заказы теперь беру у них же, в качестве внештатника. За год официальной работы наработата себе репутацию, вникла в процессы и правила, стала одним из ведущих исполнителей по проектам.
Сейчас ИП, заработок в месяц варьируется, но он уже в 2 раза выше того, что мне светило в качестве офисного работника просто благодаря тому, что оплата идет за заказы, и ты сам регулируешь темп выполнения и количество выполненной работы.
+. Живу сейчас в провинции, расходы минимальны по сравнением крупным городом. Если грамотно распорядиться средствами, можно запросто накопить на какую-нибудь недвижимость и через пару лет к своему фриланс доходу прибавить доходы от аренды.

Как и руби, go - это write only language...
Легко и быстро прототипировать. Когда нужно опробовать бизнес идею и выбросить на рынок MVP еще вчера - лучше языка и придумать сложно. Но вот поддерживать потом это больно и дорого...
Очередной раз скопипастив проверку на ошибку или проброс ее дальше, начинаешь молиться на тех людей, кто придумал DRY и проклинать авторов go, за дизайн этого языка.
И вот вроде лучик хорошего, вместо наследования нам пытаются продать композицию, только сделана она через одно место и Вы легко потеряете за ней контроль.
Полиморфизм? Я их знаю 3 вида. И я считаю, что полиморфизм - это как раз тот инструмент, который позволяет делать нам по с учетом DRY, SOLID и прочих красивых аббревиатур... Вот только в go нет ни одного из них... Вместо него Вам дают ужасную утиную типизацию. Серьезно... Когда мне говорят, что в JS утиная типизация, я смеюсь и говорю, что в JS прекрасная система типов и предлагаю посмотреть на go, так как если Вы хотя бы 10 минут изучаете чужой код, то Вы уже как минимум 3 раза спросили себя, какой калека написал здесь interface{} вместо типа...
PHP хороший язык. Он позволяет писать как говнокод, так и весьма красивое и правильное ООП. Мне лично не хватает в нем ФП, но жить без него там можно. PHP7+ весьма быстр, а с некоторыми аддонами может в многопоток... Не так просто как в go, но может...
Стоит ли та простота прототипирования и верчения горутинами нескольких человекожизней поддержки кодовой базы чуть сложнее хелловорлда? Решать Вам...

P.S. Если Вы действительно уперлись по производительности не в IO (БД, диск, сеть и т.д.), а в Ваш любимый php/js/python/java/C# - go Вам не поможет, Вы словите абсолютно те же stop-the-world от gc, в добавок Вы словите издержки на работу шедулера, рулящего Вашими 5 тысячами горутин на 4 потоках cpu... (вы еще не знали, что гипертрединг зло? посчитайте ченить cpu-зависимое на go в нескольких потоках...). Если Вы действительно уперлись в производительность своего ЯП - посмотрите в сторону C++ или Rust. Если не уперлись - переписывать все на хайповый go точно не стоит.

Как по мне, CCS-in-JS очень специфичная штука, хотя в продакшене можно встретить довольно часто.

Местами, его использование оправдано, например:
- При работе с динамически выделяемыми css свойствами, например когда обычный calc уже не справляется
- При очень сложном динамическом лейауте
- При темизации компонентов и вообще существовании такой концепции как "Тема" внутри вашего проекта.

Тем не менее, минусов как по мне не меньше:
- Проблема кеширования, такие стили не могут быть закешированы, т.к генерируются на лету и требуют того чтобы браузер распарсил ваш компонент и добавил стили в DOM. + Как результат намного больший размер финального бандла проекта.
- Хаос в файлах, когда приходится держать вместе компоненты и их стили. Опять же решаемо, но те проекты которые я видел, которые используют концепцию CSS-in-JS по большей части фигачат обычные статические стили, просто используя js нотацию, а изначально задумка была не в этом. Для такого, давно придумали более эффективные решения.
- Отвратительный DX при дебаггинге.

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