Хорошо известно, что PHP — это мёртвый язык программирования и его 22-летняя экосистема фактически стала бесполезна, когда появился Node и новые асинхронные фреймворки на его основе. Превосходство Node очевидно, потому что все знают, что однопоточные асинхронные программы более лучше по умолчанию. И быстрее.

«Но Саймон! Почему?!", вы, вероятно, прокричите увидев этот текст на экране. И вот почему:

Перспективы трудоустройства

PHP-разработчики не пользуются спросом. По прошествии 22 лет, все компании, использующие PHP, сразу же отказались от него, как только был выпущен Node v0.0.1, потому что этот стек разработки мгновенно стал лучшим. Кроме того, всем известно, что для успешного запуска (забудем про Slack) вам нужно создавать веб-интерфейсы на Node, а данные сохранять в MongoDB.

Иначе просто невозможно добиться успеха.

Приведем немного научных™ фактов, чтобы доказать эти утверждения:

$заголовок = ‘PHP-разработчики не могут найти работу чтобы содержать свои семьи’;

Сейчас мало кого удивишь инструментами управления зависимостями проекта вроде npm, composer, bundler, pip, maven, cargo и других. Их общий недостаток — невозможность управлять непосредственно средой выполнения. Такая задача решается через nvm, php-build, rvm, virtualenv, sdkman, rustup и прочие глобальные "манагеры" версий runtime, обычно написанные под Bash/Zsh.

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

Далее разброд и шатание настегает Continuous Integration & Delivery, где ручные танцы с бубном установки инструментов и активирования конкретных версий совершенно не приветствуются, а в идеале требуется в принципе максимально абстрагироваться от используемых технологий и довести процесс до примитивных нейтральных команд: подготовить к релизу, затегить, скачать, подготовить, построить, упаковать, выложить, проверить, одобрить(подписать), выкатить.

Тут сам собой напрашивается инструмент, унифицировано работающий поверх уже существующих технологий,
который из себя и представляет FutoIn CID — FutoIn Continuous Integration & Delivery tool.

• Примеры
• Репозиторий

Краткий обзор фреймворка Matreshka.js. В посте используется ECMAScript 2017, который можно переписать на ECMAScript 5.

Основные функции

Функция bindNode связывает свойство и элемент.

const object = { name: 'Brendan' };
const node = document.querySelector('.name');
Matreshka.bindNode(object, 'name', node);
object.name = 'Doug';

Если свойство меняется, меняется и элемент, если элемент меняется (например, пользователь вводит текст), меняется и свойство. Из коробки Matreshka.js умеет обрабатывать любые элементы форм. Можно объявить байндинг для произвольных элементов см. документацию.

Функция calc связывает одно свойство с другими.

Matreshka.calc(object, 'fullName', ['firstName', 'lastName'], (firstName, lastName) => {
    return `${firstName} ${lastName}`
});
object.firstName = 'Brendan';
object.lastName = 'Eich';
// ...
console.log(object.fullName); // "Brendan Eich"

Когда меняется свойство-источник (firstName или lastName), меняется и свойство-цель (fullName).

Вместе с функцией bindNode можно объявлять длинные цепочки зависимостей: свойство a зависит от состояния элемента e1, свойство b зависит от свойства a, свойство c зависит от элементов e2 и e3 и от свойства b, изменение которого, как следствие, меняет e1, e2 и e3...

Такие зависимости можно представить как таблицу в табличном процессоре (например, Excel): в каждый момент времени вы думаете об одной формуле, а не о многочисленных связях все ячеек. Как следствие, получаете меньше багов, так как нужно думать об атомарных сущностях, а не обо всей "таблице" (приложении). Больше информации в документации.

Runtyper — это плагин для Babel, выполняющий проверку типов прямо во время выполнения JavaScript кода. Он обнаруживает некорректные операции, например строгое сравнение строки и числа, и бросает предупреждение в консоль. Это позволяет вам находить ошибки типизации на ранней стадии, при этом не требует дополнительных аннотаций кода.

В предыдущей серии (Как слямзить Хабр по-быстрому) запустил проект на базе Create React App (CRA). Но это SPA, что не очень подходит, когда требуется индексация в поисковиках. Нужен Server Side Rendering (SSR). И желательно из коробки, а не на коленке. Крайне расточительно тратить ресурсы на самостоятельную разработку базовых технологий. Как выбирать платформу с поддержкой SSR? На практике, конечно, POC. Попробую реализовать CRUD с формой ввода на Material-UI, рассматривая кандидатов: React Starter Kit (RSK), NEXT.js и Electrode (не путать с Electron).

Исходники на GitHub.