Как
fullstack с 10 летним стажем, из них 7 лет в качестве хобби на PHP; HTML, CSS, JQuery и 3 года профессионально NodeJs; ES6, ReactJs, NextJs ++ Typescript, SCSS я сделал для себя вывод:
При современных требованиях:
При условии, что и там и там используются стандартные наборы библиотек, т.е. на беке например не нужно прикручивать какую-нибудь сишную библиотеку или на фронте не нужно пилить какой-нибудь особенный видеоплеер, то фронт в проекте, всегда раза в два, как минимум, сложнее, чем бек, это даже с учётом того, что все расчеты, которые без лишнего запроса можно сделать на беке - делаются на беке.
Чем фронт сложнее бека:
1.
Разные среды исполнения. Сервер один и он под боком, а браузеров много и они где-то там.
2.
Пользовательский фактор. На сервере управляется проверкой входных данных запроса, а на фронте надо учитывать всё: пользователь нажал Отправить и до прихода ответа нажал Создать страница перерисовалась, а ответ с Отправить не нашёл нужного блока (пример так себе, но неожиданное поведение пользователя учитывать нужно).
3.
Логгирование. На сервере легко записывать в лог. На фронте придется делать авто отправку отчёта об ошибке на сервер, а промежуточные данные писать в
sessionStorage и прикладывать к отчёту. А необработанные исключения на фронте ещё сложней ловить, почти невозможно или очень дорого.
4.
Творческий фактор. На сервере всё сурово, отработал и гуляй, главное безопасно обработать данные. На фронте, помимо данных, часто некоторые визуальные эффекты вызывают неоднозначные эмоции, приходится их мять туда-сюда искать оптимальный вид чтобы не раздражать пользователя. А отсюда ещё вытекают дополнительные сложности по сдаче своего кода владельцу.
5.
Требования к чистоте кода. Если на сервере будет неиспользуемый метод, то он будет занимать несколько килобайт памяти на диске и всё. А на фронте это плюс те самые килобайты к весу каждой первичной загрузки.
6.
Жизненный цикл скрипта. На сервере всего две стадии: инициализация и запрос. На фронте сложнее и основных три: инициализация (подгрузка значений), рендеринг (отрисовка и навешивание обработчиков), эффект (внесение изменений с учётом дополнительных значений). Но это далеко не всё, если на сервере каждый компонент (API, роут), в плане жизненного цикла, изолирован от других, то на фронте ввиду его особенностей почти все компоненты являются вложенными в другие компоненты, поэтому, например: рендеринг дочерних компонентов может влиять на жизненный цикл родительских. Пример написан под влиянием React, поэтому термины могут подойти не везде, но всё равно, при любых методиках, вложенность компонентов, с пересекающимся жизненным циклом, на фронте всегда привносит дополнительные требования к безопасности.
Бекенд халява?
Конечно же нет! Бекенд это ответственнейшая часть приложения в плане обеспечения безопасной обработки и хранения данных. Но, как правило, основы безопаcности данных закладываются один раз при проектировании архитектуры, а далее просто наследуются. Также сложностями бекенда являются расчёты, сортировки, фильтры, запросы к сторонним ресурсам, вызовы сторонних сервисов. Плюс помимо взаимодействия, ещё сама архитектура базы данных чаще всего лежит на плечах бекендеров. Но это всё приятная рутина, в отличие от чудесных приключений на фронте)) Мне нравится разнообразие, поэтому я фуллстек. Надоедает засиживаться на чём-то одном.
P.S.:
По поводу "сложности библиотек", на мой взгляд, тут не зависит от края приложения.
