> У веб-кодеров свои представления о "много", это да. Процессоры слишком быстрые стали.
> Вообще, правило номер один это не доверять клиенту. Немного иная специфика,
> и если ты экономишь ресурсы тебе разнесут сервер рано или поздно.
> А на клиента плевать, пусть обновит страницу на актуальную ревизию и
> всё ок, никакого смысла проверять невозможное на нём.Частоиспользуемые методы что на стороне браузера, что на стороне гибридных приложений, обычно JIT-ятся и проверка содержимого какой-либо переменной нередко состоит всего лишь из нескольких машинных инструкций.
Но, кроме шуток, на каком-нибудь Си можно позволить себе наговнокодить несравненно больше, чем на JS, поскольку компилируемые ЯП прощают несравненно бОльшие огрехи в оптимизации.
У бэкендеров - недоверие к фронтендерам( поскольку с клиента что угодно прилететь может ), у "фронтендеров" - к бэкендерам( поскольку с бэка черти что прилететь может, нередко вообще не соответствующее договоренностям о структуре ответов ).
Поэтому в конторах, в которых ранее иногда работал, бэкендеров, которые нередко не способны были сделать корректное удаление данных( иначе, удаляется, к примеру, пользователь, а его предложения о товарах - выдаются как ни в чем не бывало, только user: null и любые попытки сделать заказ и проч вываливаются с ошибкой, но уже со стороны бэка ) или выдачу данных, согласно какой-то схеме, довольно часто под задницу выпинывали, поскольку предрелизное тестирования могло затянуться на недели из-за неведомых сбоев и ошибок, 95% которых приходилось на некорректную выдачу с сервера. Но, к сожалению, подобных бэкендеров на фрилансе больше половины.
А потом - начал разрабатывать мобильные приложения, а привычки остались
Все-таки, из-за криворуких бэкендописателей не должны страдать конечные пользователи, у которых приложение "валится", к примеру, при пустой коризне( ведь "гений" выдает в качестве списка товаров null вместо пустого массива ).
Но, хотя бы какую-то минимальную проверку данных в плане соответствия структуре, особенно, тех, которые прилетают с АПИ, делать необходимо вне зависимости от ЯП и проч.
