Что за язык? Может тоже посмеюсь
19.06.2020, 07:10
шаблонизатор twig
Да не, twig он как jinja2 или джанговские шаблоны. А это что-то другое, но шаблоны, да, тут ты прав.
Я терпеть не могу фронт. В бэке все строго и чисто, я кайфую, когда пишу что-то на бэк.
В корне не согласен
В бэке надо быть хорошим архитектором, ибо многопоточность, [микро]сервисность, местами облачность, возможны осадки в виде дедлоков
Во фронте больше гимора от заказчика и кроссбраузерность
Учитывая сколько может обработать современный веб клиент, написать фронт так чтобы он заметно тормозил надо сильно постараться
При этом заказчик оценивает весь продукт по фронту
В бэке надо быть хорошим архитектором, ибо многопоточность, [микро]сервисность, местами облачность, возможны осадки в виде дедлоков
Во фронте больше гимора от заказчика и кроссбраузерность
Учитывая сколько может обработать современный веб клиент, написать фронт так чтобы он заметно тормозил надо сильно постараться
При этом заказчик оценивает весь продукт по фронту
Ну так и на фронте есть многопоточность, рейс кондишн, ленивая инициализация и вот это все.
> написать фронт так чтобы он заметно тормозил
Берешь Реакт, в котором плохо организована вертикальная передача данных. Чтобы хоть как-то разрешить проблемы с передачей, прикручиваешь Редукс, который на каждый чих с объектом возвращает его неизменяемую копию, распихиваешь данные по как можно большему числу объектов и готово - вроде фронт ничего не делает, а тормозит зверски.
> написать фронт так чтобы он заметно тормозил
Берешь Реакт, в котором плохо организована вертикальная передача данных. Чтобы хоть как-то разрешить проблемы с передачей, прикручиваешь Редукс, который на каждый чих с объектом возвращает его неизменяемую копию, распихиваешь данные по как можно большему числу объектов и готово - вроде фронт ничего не делает, а тормозит зверски.
у меня фейсбук ужасно тормозит на всех компах, ноутах и телефоне.
Ну, в общем-то, как правило - да. Ныне бэк на 90+% является прокладкой между фронтом и базой данных. С современными ORM-фреймворками это по силу любому джамшуту. Если вдруг окажется, что его кривые запросы отправляют базу в задумчивость, то крайним окажется "слабый" сервер. Если же джамшут ничего не знает о безопасности, то виноваты будут "хакеры", а не кретин, выставивший в инет API, позволяющий получить, например, список всех юзеров с паролями конечно же хранимыми в открытом виде.
Когда же джамшут столкнется с интересными проблемами бэка типа race condition, то виноватым снова окажется слабое железо. Ну и хакеры, конечно.
А фронту валить проблемы не на кого.
Когда же джамшут столкнется с интересными проблемами бэка типа race condition, то виноватым снова окажется слабое железо. Ну и хакеры, конечно.
А фронту валить проблемы не на кого.
Вопросы авторизации и раньше-то были херней, а с появлением фреймворков окончательно утратили даже минимальную сложность.
Задача интеграции с кучей внешних систем обычно сводится к написанию тривиального HTTP-запроса, коих на фронте могут быть сотни.
Конечно может быть уникальная задача, которая решается только на стороне бэка, но такие случаи единичны. А в 90%+ случаев анализ на стороне приложения случается потому, что разработчик имеет весьма смутное представление об SQL.
Это реально прямо эпидемия. Как каждый идиот на фронте полагает, что знает CSS (путаясь в простейших селекторах), так и каждый идиот на бэке полагает, что знает SQL (путаясь в простейших селектах).
Задача интеграции с кучей внешних систем обычно сводится к написанию тривиального HTTP-запроса, коих на фронте могут быть сотни.
Конечно может быть уникальная задача, которая решается только на стороне бэка, но такие случаи единичны. А в 90%+ случаев анализ на стороне приложения случается потому, что разработчик имеет весьма смутное представление об SQL.
Это реально прямо эпидемия. Как каждый идиот на фронте полагает, что знает CSS (путаясь в простейших селекторах), так и каждый идиот на бэке полагает, что знает SQL (путаясь в простейших селектах).
ага, давайте каждого клиента цеплять к БД напрямую без бека
какой пул подключений база может выдержать?
как соонтести роли пользователя сайта к роли и авторизации в БД?
для каждого пользователя сайта ещё и пользователя для базы создавать?
серьёзную логику перестали вешать на БД и хранимые процедуры не потому, что все резко отупели и забыли SQL, а потому что это не масштабируется и не отлаживается нормально
плюс, логика, выполняемая на стороне SQL будет тормозить запросы от других клиентов, удлинять по времени транзакции, повышать риск блокировок
какой пул подключений база может выдержать?
как соонтести роли пользователя сайта к роли и авторизации в БД?
для каждого пользователя сайта ещё и пользователя для базы создавать?
серьёзную логику перестали вешать на БД и хранимые процедуры не потому, что все резко отупели и забыли SQL, а потому что это не масштабируется и не отлаживается нормально
плюс, логика, выполняемая на стороне SQL будет тормозить запросы от других клиентов, удлинять по времени транзакции, повышать риск блокировок
Паренек еще не знает, насколько это лучше чем админить госуху.
Да всё просто.
Урок №1: JavaScript - говно
Урок №2: Java - это не JavaScript
Урок №3: Java - тоже говно...
Урок №1: JavaScript - говно
Урок №2: Java - это не JavaScript
Урок №3: Java - тоже говно...
так не хочет возвращаться
Чтобы написать коммент, необходимо залогиниться
