Александр Меньщиков

Какой-то пакет из ваших зависимостей требует babel 7+, а у вас - 6.
Читайте, обновляйтесь.

https://babeljs.io/blog/2018/08/27/7.0.0

Во-первых, у шаблонных сайтов есть ряд неудобств.
Ввиду универсальности верстки, они как правило содержат очень большое количество ненужного кода.
Как объяснить эту проблему клиенту решайте сами.
Я обычно говорю, что такие сайты сложней поддерживать, чем сайт, созданный "специально по его заказу".
Во-вторых, давите на уникальность.
Обычно на клиентов действует фраза "Вам же не нужен сайт, который будет копией другого проекта в интернете".
Расскажите ему, что сайт - это лицо компании, он не должен быть копией чего-то (может даже оказаться копией конкурентов, что принесет ряд неудобств и ему и конкурентам).
Должен "цеплять" зашедшего клиента, запоминаться.
Но вы не должны навязывать это.
Если клиенту все равно и он хочет дешево, то у вас есть два пути.
Послать его нахер или сделать ему так, как он хочет)

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

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

Нет, я не согласен с тем, что созерцание чужих сайтов даёт навык проектирования хороших своих. Максимум - вдохновление. А тут нужны склад ума, навыки, определённая техника.

Под хорошими я понимаю сайты, которыми удобно пользоваться посетителям

Я рекомендую обратиться к направлению User eXpirience (EX) - создавать удобные пользователям решения.
Это большое направление. Там есть немного от художника, но много от самого пользователя. Нужно давать пользователям задания, которые можно решить на твоём сайте, чтобы они при тебе делали и рассказывали - что хотят сделать, какой элемент интерфейса они бы кликнули, какие ожидания у них в голове до клика, что они получили после клика, получили ли они желаемое, достаточно ли просто было получить желаемое. Это в общем называется User/Usabity Testing. Нужно несколько таких ревью. Затем принимается решение, устраивает ли пользователей ваш способ удовлетворить его потребности, не стоит ли упростить или усложнить сценарии поведения пользователей, изменить размеры или цвета, переставить элементы местами.
Через некоторое время, на N+1 проекте, у вас в голове начнёт складываться правильное понимание того, что ожидают пользователи, как удобнее для пользователя реализовать в интерфейсе решения его проблем. Идеального решения не будет. То, что вы придумете для N проектов, на N+1 вообще может не сработать. Главное знать как определить, что именно является причиной неудачи и иметь идеи, как это изменить.
Ещё есть такая техника, как A/B тестирование, сплит-тестирование.
В общем - делайте, проверяйте, исправляйте.
Небольшой обзор для затравки www.zenexmachina.com/what-we-do/user-experience

Под хорошими я понимаю сайты, ... которые приносят прибыль своим владельцам

Этот раздел называется маркетинг и, в частности, интернет-маркетинг. Первая задача: найти потребность и удовлетворить её. Вторая задача: удовлетворить потребности бОльшего количества потребителей, то есть "зацепить" больший процент аудитории либо увеличить аудиторию. Третья задача: найти оптимальную цену, то есть сбалансировать возможности производства, затрат, потребления и покупательской способности. Ну и ещё много задач.

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

Ищите новые потребности новых потребителей. Ищите новые потребности старых потребителей. Обозначу всё это словом диверсификация.
Ищите новые способы удовлетворения старых потребностей, более эффективные или менее затратные. В том числе, новые клиентские технологии, более современный дизайн, если пользователю так будет удобно.
Не останавливайтесь. Развивайтесь.
Вот такой мини-обзор поможет: uxmastery.com/resources/process

Опыт показывает, что меньше всего в этом вопросе помогают умные книги. Из них можно почерпнуть знания, но навык от этого не растёт ни чуть.

Не согласен. Но конкретных книг не дам. Я просто не записывал, что именно я прочитал.
Издательство МИФ много современных иностранных книг переводит. Много источников на английском.

Но главное ...

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

Не так уж и быстро она растёт. А ещё, часто бывает, что знания растут, а на практике ничего не меняется. Цель изучения не в том, чтобы знать, а в том, чтобы действовать. Обычно лучше запоминается именно то, с чем сталкиваешься в реальности. А ещё, зная как делать, начинаешь экспериментировать.

P.S. Тут какая то "серебрянная пуля", а не "золотая середина" ж))

Только домен, хостинг и желание? Диздока нет, wireframe'ов нет, только задумка? Если есть хотя бы одностраничный питч, уже можно начинать работать. А без этого — очередное прожектерство.

Мартин Фаулер круто пишет обо всех паттернах. Про DI можно почитать тут. Вообще у него отличный блог. И он же автор книги P of EAA. Правда русский ее перевод крайне не рекомендую читать, можно только запутаться, так что читайте в оригинале.

Если хотите разобраться с паттернами, то самая простая (и при этом дельная!) книга - это Фриман&Фриман. Ее можно читать и на русском.

Применительно к PHP - вот лучшая книга про шаблоны (и не только), которую я видел PHP. Объекты, шаблоны и методики программирования от Мэт Зандстра.

Порядок прочтения рекомендую следующий: Фриман&Фриман, затем Мэт Зандстра, и на десерт Фаулера P of EAA.

UPD:
Важно отличать паттерн Dependency Injection от Dependency Injection Container.
Простейший пример внедрения зависимости:

interface IEngine {}
 
class V8Engine implements IEngine {}
 
class Car {
  public function __constructor(IEngine $engine) {
    $this->engine = $engine;
  }
}
 
$car = new Car(new V8Engine());

Простейший пример игнорирования явного внедрения (для такого кода трудно писать unit-тесты, его труднее понимать и править):

class V8Engine {}

class Car {
  public function __constructor() {
    $this->engine = new V8Engine();
  }
}

$car = new Car();

Отличный (и легковесный) пример DIC - это pimple:

// define some services
$container['session_storage'] = function ($c) {
    return new SessionStorage('SESSION_ID');
};

$container['session'] = function ($c) {
    return new Session($c['session_storage']);
};

Советую прочитать и понять его исходники, чтобы убедиться, что в DIC (во всяком случае для PHP) нет никакой магии. Первая версия была всего ~100 строк. Необходимо также отметить, что класс Session использует шаблон Dependency Injection, явно определяя свою зависимость от SessionStorage. А контейнер делает лишь правильную связку.

И да, контейнер сам по себе можно использовать как service locator, если к нему, например, есть глобальный доступ. Но это очень плохая практика, потому что если что-то обращается к сервис локатору, то формально оно начинает зависеть сразу от всех компонентов системы.