О фреймворках JavaScript’овых

23.09.2015

 

В последнее время наблюдаю ситуацию, когда на JavaScript’е пытаются сделать все, что только можно. Тенденция на самом деле пугающая. Популярность понятна – низкий порог вхождения; отсутствие строгих требований к пониманию того, как работают программные системы и распространенность инструментарий (фактически для начала нужен хром и блокнот). Однако, «программисты» на JavaScript’е большей частью люди, далекие от серьезной разработки (существуют конечно и уважаемые гуру, но их как правило гораздо меньше) пишут свой код бездумно и в больших количествах. И очень часто этот код попадает в рабочие проекты. И после этого, когда дело доходит до того, что «система не работает» с этим приходится разбираться. Для того, чтобы немного систематизировать информацию и, дай бог, уменьшить количество такого кода и предназначена эта статья.

Но для начала немного терминологии, которую будем использовать в этой статье. Разделим все Web-страницы, Web-сайты и Web-приложения на два «лагеря» – backend-ориентированные и frontend-ориентированные.

Backend-ориентированные в вопросах обработки бизнес-информации и бизнес-логики опираются на бэкенды, которые написаны как правило на таких языках как Java, PHP, Ruby, Python и даже C++ (надеюсь никого не обидел). Представление в таких приложения как правило не требует каких-то более серьезных вещей кроме как динамика представления данных, обработка событий пользователя и передача их на бэкенд.

Frontend-ориентированные приложения как правило оставляют бэкенду только вопросы взаимодействия с базой данных или другими приложениями и реже вопросы формирования самих представлений. Основная часть работы в таких приложениях ложится на непосредственно frontend, где необходимо кроме собственно динамики представления обеспечивать такие вещи как формирование представлений (сиречь HTML код), обработку переходов и взаимодействия между несколькими представлениями, получение и кэширование данных. Да что там говорить, вообщем-то весь MVC переезжает во Frontend.

Какой подход лучше зависит от многих факторов. Для начала давайте рассмотрим предположительные плюсы и минусы каждого подхода

Backend-ориентированные:

Плюсы:

• Бизнес-логика работает как правило на более структурированных и более производительных технологиях, нежели JavaScript, который хоть и кажется универсальным, достаточно медленен. (Поправка: в последнее время с развитием технологии V8 на некоторых задачах бэкенд на JS иногда даже рвет например Java)
• Бизнес-логика скрыта от конечного пользователя и заниматься ее реверсом (reverse engineering) он не имеет возможности
• Как правило в силу большей «взрослости» и более высокого порога вхождения, бэкенды как правило лучше спроектированы и реализованы
• Благодаря тому, что код бэкенда работает в известном окружении и управляется квалифицированными людьми, допустимые использования как правило шире, чем на JavaScript’е в браузере (который работает в песочнице)
• Как правило стеки технологий для реализация бэкендов закончены и самостоятельны, как правило вам приходится работать с одной определенной версией стека, следовательно вы можете давать некие гарантии надежности

Минусы:

• Как правило более сложная разработка, связанная с временем компиляции и более витиеватым развертыванием (привет долгие редеплои на сервере приложений и известная отмазка программистов - “мой код компилируется”)
• Более высокий порог вхождения означает более высокую стоимость разработки
• Необходимость фактического перехода между «экранами», которая выглядит как загрузка страницы в браузере, при медленном соединении может быть проблемой

Frontend-ориентированные

Плюсы:

• Низкий порог вхождения – большое количество специалистов, которых вы можете нанять (правда о их квалификации лучше задумываться заранее – скупой платит дважды)
• Ввиде того, что JavaScript – интерпретатор, возможна практически интерактивная разработка (а особенно если смотреть в сторону новомодных технологий, которые даже автоматом перерисовывают экран не меняя данные и путь к этому экрану - привет redux)
• Инструменты в виде браузера хром весьма и весьма хороши
• Отсутствие необходимости перезагружать страницу в браузере

Минусы:

• Скорость работы. Когда вы запускаете сложное MVC приложение со всей логикой запущенной в JavaScript, производительность решения оказывается как правило ниже плинтуса
• Спагетти код. Будьте готовы, низкий порог вхождения и отсутствие привычки думать перед написанием кода приводят к печальным результатам
• Чтобы исправить ситуацию, вам надо будет все переписать
• Количество браузеров практически неисчислимо, кроме собственно разных вендоров и их моделей (хром, файрфокс, опера, сафари и т.д.) вы имеете дело практически со всеми известными версиями этих браузеров, а чего стоят версии программы для скачивания браузеров версий 5.5, 6.0, 7.0 и т.д., которые практически несовместимы друг с другом, а ребро так и вообще некий непонятный зверь. Гарантии надежности, даже самые простые вы давать не можете.

Теперь, когда мы определились с терминами скажу свое слово относительно фреймворков. Честно говоря лично мне в данный момент они кажуться чем-то странным и ненужным, но требование объективного изложения требуют от меня аргументации. Что ж попробуем.

Принцип работы Backend-ориентированного приложения

• Все приложение разделяется на набор «экранов», выполняющих небольшую, но законченную функцию
• Представление (HTML) каждого такого экрана формируется на бэкенде, в том числе вспомогательные окна, сообщения и т.д. (тут кстати возможна простая локализация)
• Динамика описывается в виде сценариев JavaScript и описывает только конкретный «экран». Код нескольких «экранов» разделен на уровне JavaScript файлов
• Клиент запрашивает такой экран вместе с необходимыми представлениями и дополнительным программным кодом, обеспечивающим динамику
• ВСЯ сложная обработка обеспечивается на бэкенде и запрашивается представлением посредством AJAX запросов

Принцип работы Frontend-ориентированного приложения

• Бэкенд обеспечивает только отдачу статического содержимого и обработку запросов к источникам данных (БД, …)
• Все представления (в том числе отображаемый HTML) формируется в процессе отображения данных в браузере, что вызывает необходимость переноса таких вещей как модель и контроллер фактически в код представления на JavaScript
• После того, как клиент получил статику и сформировал представления на стороне клиента, AJAX запросы к серверу делаются исключительно при необходимости работы с источником данных
• Собственно, исходя из всего вышеизложенного вытекает инструментарий.

Для Backend-ориентированных:

• J2EE, Spring MVC, JSP – для бэкенда
• Twitter Bootstrap, jQuery, Knockout (или другой binding-фреймворк) – для динамики фронтенда

Большего не нужно, этого вполне хватает для разработки качественных backend-ориентированных приложений.

Для frontend-ориентированных

• Любой Web-сервер – для отдачи статики не важно, какой у вас там сервер, хоть с локальной файловой системы запускайтесь
• %любой JavaScript фреймворк% – любой из новомодных, а потому может быть еще сырых. Выбирайте любой

Иногда вам все же понадобиться что-то, работающее с базой данных. Конечно если вы не используете какой-нибудь MongoDB у которого есть REST-интерфейс

На этом все, можете писать комментарии – по ходу пьессы буду дополнять сий опус.