Pull to refresh

Comments 19

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

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

P.S. Ну и поверьте, бэкенд-технологии тоже не стоят на месте, хотя лично я за мир-дружбу-жвачку, если что. Работы всем хватит.
Золотые слова! Все профессии важны.
Ну бросьте, мы скромные ребята, ни над кем возвышаться нам не надо. Понятное дело, без бэка нам никуда :) Но все же Вы не совсем точно заметили ошибку (имхо): бизнес логика будет дублироваться только для валидации данных. Логика процессинга этих данных никогда не перекочует на фронт и навсегда останется на бэке из соображений безопасности. Однако, во всех SPA на фронт выносится работа с роутингом, данными (агрегация и финальный процессинг), рендеринг (я имею ввиду механизм составления шаблона (и иногда кое-что ещё), так-то рендеринг всегда происходит в браузере), ну и всякие анимашки и прочее.

На мой взгляд, в данный момент бэк уходит больше в оптимизацию работы с данными (процессинг, хранение, выборка, анализ), оставляя на фронт построение GUI приложения.

И да, разумеется мы всегда будем не разлей вода, работы и правда всем хватит.
оставляя на фронт построение GUI приложения

Удивительно!
>бизнес логика будет дублироваться только для валидации данных

В сложных UI приложениях уже давно повсюду optimistic updates.
Большинство макетов программисты могли сверстать самостоятельно, ну что там сложного: table, table и table


Это так и надо было оставить. Ибо сейчас настолько жирной стала клиентская часть, что ради одного JS метода фронтендеры берут по 25 фреймворков без малейшего представление как оно работает и для чего. В итоге сайты грузятся так же долго, как 20 лет назад. Чего стоит сайт твиттера с его JS кодом в более, чем 25 тыс строк. Уверен, что если 80% кода сломать — на работоспособности сайта это никак не скажется.
UFO just landed and posted this here
Юмор это хорошо, но я на полном серьезе. Мы на работу долго ищем фронтендера, который в JS шарит. Вроде как все кандидаты нормальные.

Но стоит на шаг в бок отойти от общеизвестных фреймворков и попросить написать что-то свое — все чешут затылок со словами «а зачем? Можно же 15 фреймворков подключить». А потом мы слушаем от наших клиентов, что у них сайты невероятно долго загружаются на мобиле. В итоге получаем использование фреймворка Г по той причине, что в нем есть методы из фреймворка А. Но Г без Б не работает, как и Б без В.
Под все задачи свои инструменты. Ведь чтобы развести костёр вы используете зажигалку, а не камни, верно? Но не поймите меня неправильно: подключать весь underscore ради _.debounce или jQuery из-за селекторов, разумеется глупо. Радует, что авторы библиотек, выходящих в наше время, думаю о гранулярности своих решений и не создают огромных монолитных монстров.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Вы о каких фреймворках говорите сейчас?
UFO just landed and posted this here
Наконец-то адекватный человек на Хабре. А то смотришь вакансии, а там требуется человек со знанием нескольких фреймворков. Приходишь на собеседование — тебе в запой рассказывают о своих костылях: эта часть у нас на Angular, тут перешли на React и используем еще 100500 мелких библиотек. Да что там другие компании, от своих не могу добиться, чтобы выпилили lodash с фронтенда. Тащят 50 КБ ради трех методов. Ну хоть jQuery выпилили, уже прогресс.
«Шоп был», судя по оценке комментария.
Sign up to leave a comment.