Вчера была опубликована статья на тему Печальное состояние веб-разработки. Сначала я хотел бы поблагодарить Дрю за написание такой провокационной статьи, поскольку она (в сочетании с реакцией сообщества Node.js) побудила меня, наконец, поднять свою задницу и на самом деле записать свои мысли для разнообразия.

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

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

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

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

  1. Вам, вероятно, не нужен и SPA, если только вы на самом деле не создаете настоящее приложение. К сожалению, я редко могу отказать, когда директор по маркетингу для клиента решает, что его простой информационный сайт должен петь и танцевать на экране пользователя вместо того, чтобы предоставлять действительно ценный контент. Помните сначала содержание? Это были хорошие времена.
  2. React может время от времени исчезать сам с собой. Я не уверен, что «понимаю» поток, и кажется, что существует множество библиотек и шаблонов, которые, похоже, предназначены для того, чтобы усложнить жизнь нормальным людям. Тем не менее, мне действительно нравится реагировать (базовая библиотека), если я не лезу во все эти дополнения.

Ладить с ней!

Момент, когда я чувствую, что могу что-то внести, заключается в его разочаровании:

О привет, мы используем PostCSS. Посмотрите на файл gulp/grunt/broccoli/brunch и посмотрите, какие плагины я использовал. Когда вы это сделаете, посмотрите, что делает каждый плагин. После того, как вы потратили на это целый день, начните писать CSS или PostCSS, что бы это ни было на самом деле. Я действительно просто хотел SASS, но вместо этого решил использовать эти 185 плагинов, и вы знаете, потому что он написан на Javascript.

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

Проблема здесь не в PostCSS. Проблема в том, что люди пытаются эмулировать SASS с помощью PostCSS. Многие разработчики начинают проект с такого мышления:

Хорошо, мне понадобится веб-пакет для создания вещей. И мне придется использовать препроцессор CSS. Я слышал хорошие отзывы о PostCSS, давайте посмотрим, на что он способен. О, ну, я думаю, мне понадобится этот плагин и этот, о, и мы не должны забывать об этом! Теперь мне нужно сделать его пригодным для продакшена и добавить кучу вариаций для разных сценариев…

Я знаю это, потому что это был я не так давно.

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

<!DOCTYPE html>
<html>
  <head>
    <meta charset=”utf-8">
    <title>Title</title>
  </head>
  <body>
  </body>
</html>

Я знаю, это прорыв. Добро пожаловать, но не забудьте отдать должное там, где это необходимо. Возможно, отправить пожертвования для хорошей меры.

Забудьте обо всех дополнениях до тех пор, пока вы не сможете их обосновать, и я действительно имею в виду обосновать их, потому что каждая строка кода и каждый добавляемый вами инструмент:

  1. Усложняет поддержку проекта.
  2. Добавляет больше точек отказа.
  3. Мешает работать с другими.

По той же причине я не люблю такие инструменты, как yeoman или любой из бесчисленных проектов `angular-gulp-browerify-keyword-buzzword-starter-pack`. Они существуют, потому что сложно настраивать проекты таким образом, но это сложно только потому, что вы включаете всю вселенную по умолчанию и пишете задачи сборки для каждого возможного будущего сценария, прежде чем вы даже написали одну строку кода. Единственный законный аргумент, который я вижу в их пользу, — это быстрое прототипирование.

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