Alex

Ну по большому счету особо проблем сегодня нет и под win, есть как минимум GitBash + есть встроенный Ubuntu под Windows этих штук уже для всего хватит(практически). Плюс есть удобная вещь - Vagrant + есть Docker. Все эти штуки помогут развернуть под Windows полноценную среду разработки для практичесик любого уровня Fullstack разработки.
Что касается "порезок" и прочего, то советую взглянуть на клевый инструмент Zeplin, он своих денег стоит.
А так в целом работайте там, где вам удобнее. Просто для текущего фронтэнд разработчика(я надеюсь вы понимаете что это не только верстка), желательно иметь POSIX совместимую систему, так как огромное количество инструментов на это завязано, но MS в последние годы много сделало чтобы и под win не было особых проблем.
Так что дерзайте, настраивайте и планируйте инструменты который вам лично нужны для работы, и уже после этого выбирайте ОС.
PS кстати, так же в последние годы одной из лучших систем для разоработчика считают MacOS, имеем гораздо более высокую стабильность относительно Линукса(я про пользовательскую часть) и все плюсшки *nix без особых усилий. Но повторюсь, при желании под Windows у вас тоже будет все хорошо скорее всего.

kenwheeler.github.io/slick

Вали от туда

А вообще вопрос глуповат. Если там php 5.4 и Kohana старенькая, то конечно они не используют композер.
Если нет тестов — не всегда плохо, очень много проектов без тестов работают. Да там ты не научишься хорошему программированию, но не так все ужасно... можно потихоньку их притащить, но не всегда это нужно бизнесу (вообще это задачи тимлидов и гигиены разработчиков)

А вот ответ Тимлида ужасен. Почему это выяснилось не на собеседовании?

Не ужели с вашим подходом к программированию и опытом вас не взяли в компанию получше?

UPD: Очень хороший ответ ниже по ссылке -- Разве Composer бесполезен в 2017?

И соответственно использовать фреймворки тоже не вижу смысла

А смысл в том, чтобы писать кашу - Вы видите?
Приучите себя писать нормально, используя хотя бы тот же MVC паттерн, и на эту вот писанину выше, через год будете смотреть и рыдать.

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

laracast.com отличный ресурс

В своей практике применяю такой подход:
nginx служит для проектов на php/nodejs/etc прослойкой, которая распределяется запросы - на статику (картинки, css, js) или динамику (html). Статику отдает самостоятельно, а вот динамикой уже занимается apache/nodejs/etc. Причем "наружу" смотрит только nginx, все остальное слушает только 127.0.0.1, куда и проксирует все запросы nginx.
Это в двух словах, если нужно более подроное или тонкая настройка - то маны Вам в помощь.

https://hangouts.google.com/
https://tox.chat/
https://wire.com/en/

Google пишут про 4 основных варианта:

• In-app payments – покупки внутри приложения
  
• One-time charge – разовый платёж
  
• Subscription – подписка
  
• Offering a limited trial version of your item – ограниченная (по времени или функциям) пробная версия
  

Как вы это делаете?! За 17 лет работы в ИТ у меня ни разу не возникало вопроса "Куда двигаться?", только "Где взять времени на освоение всего этого бесконечного изобилия технологий, углублённого изучения уже знакомого и реализацию множества идей?"

Как лучше отдавать данные? Как используете так и отдавайте, server-side рендер делается на nodejs в любом случае, и к бекенду с данными(go сервер/api ваш) относится примерно никак.
Для бекенда с данными(go сервер/api) это точно такой же клиент как и браузер.

Скрипач не нужен, родной (с)
Аргументы против jq:
- современные браузеры достаточно хорошо поддерживают единый синтаксис современного екмаскрипт(native js)(на самом деле нет).
- сторонняя библиотека, работает медленнее чем натив и в основном состоит из с-сахара (тоже не совсем правда)
- тащить еще один ресурс весом от 64 кб до 200 кб, еще и со сторонних ресурсов замедляет загрузку( правда, но бред)
Аргументы за:
- Современные браузеры как и всегда один другого "ровнее", всегда есть косяки и "нюансы", на которые еще и попадаешь обычно в самый неподходящий момент, в жк обычно все работает одинаково везде, ну или лучше чем в нативе.
- В жк реализована куча плюшек в 1 функцию которые в нативе занимают "многабукав", не каждый начинающий напишет их правильно, да и профи не все напишут оптимально, уверен что в большинстве случаев написанный нативом функционал будет хуже аналога из жк.
- размер мин пакета жк 64 кб, и все они лежат на быстрых цдн серверах. Думаю это последнее что может повлиять на скорость загрузки страницы.
- есть ОГРОМНОЕ количество скриптов написанных с учетом жк, не использовать их глупо, писать свой велосипед - вообще только в целях обучения(не берем крайние случаи когда плагин писал упоротый пингвин).
- Синтаксис и краткость записи - вообще вне конкуренции.
- Старые браузеры никто не отменял, часто заказчик требует чтобы работало в ие8, натив не канает или доставляет море анального удовольствия.
Вывод: Если ты крут в жс, еще и работаешь в ангуларе/ещечетамдляфронта и тебе нужно сделать 2 действия в очень современных браузерах - jquery не нужен, и ты это сам знаешь. Если слова ангулар, вуе и проч для тебя не больше чем шум листвы за окном, а навесить плагинов и эффектов нужно - jquery наше все.

UPD: для всех кто там отписался а ля "в связи (...), исчезновением проблемы совместимости со старыми IE (что и было основным назначением jQuery)." - свежачок

Если прям нужно ограничить по ширине 1920, то всем секциям так и пишем, а тем где нужно уже добавляем .wrapper с max-width: 1200px и margin: 0 auto.