Перейти к содержимому

24.10.2014

Философское: from __future__ import web.framework.* или где искать идеальный фреймворк?

JS_FrameworksВ последнее время обсуждали с ребятами текущее положение дел в веб-разработке, современные фреймворки и, конечно же, что будет в будущем. Поэтому решил оформить свои рассуждения на эту тему в виде поста. А спустя сколько-нибудь лет посмотрим, как оно будет на самом деле.

Последнее время веб очень сильно и интенсивно развивается, и, кажется, скорость развития с каждым годом только увеличивается. Еще лет 10 назад JS-код и стили спокойно лежали себе рядом с html или php файлами, подключались в <head> и все прекрасно работало и все были счастливы.

Но даже тогда веб не стоял на месте и появился XMLHTTPRequest, ознаменовавший эру Web 2.0. Постепенно начали появляться разные клиентские фреймворки, которые пытались решить те или иные задачи и упростить жизнь разработчикам. Первопроходцами были такие мастодонты как Dojo, Scriptaculous и, конечно же, Prototype.

Параллельно с этим пришли такие люди как Стив Содерс из Yahoo!, затем Илья Григорик из Google и прочие и начали рассказывать о том, как надо оптимизировать клиентский код, появились такие инструменты как Page speed и YSlow, которые выдавали свои рекомендации о том, что надо сжимать и конкатенировать файлы, оптимизировать CSS, подключать JS-файлы в конце <body> и так далее. Это послужило появлению многих утилит и инструментов, без которых сейчас не обходится ни одно веб-приложение. Grunt, gulp, cssmin, uglify, png-optimize, svgo и много-много других.

Сейчас, чтобы написать современное веб-приложение, разработчику помимо непосредственно самого кода необходимо знать и владеть еще целой кучей дополнительных инструментов. Что же касается фреймворков, то здесь так же не все однозначно. С одной стороны, современные фреймворки обладают большой функциональностью и вроде как помогают решать множество разных повседневных задач. Но с другой стороны, для того, чтобы начать эффективно пользоваться каким-либо фреймворком, необходимо потратить час/день/неделю на его освоение. И в большинстве случаев, необходим достаточно высокий уровень знания JavaScript и просто широкий кругозор в области программирования. Взгляните хотя бы на react.js — вы думаете новичок сможет реально освоить его за пару часов? — Мне кажется, нет.

Давайте попробуем взглянуть на то, какие проблемы решают современные фреймворки. Конечно, они бывают разные, и, следовательно, решают разные проблемы. Наверное, грубо их можно разделить на 2 больших направления: интерфейсные и системные. К интерфейсным можно отнести все фреймворки которые так или иначе занимаются отображением интерфейса и взаимодействуют с пользователем. Обычно в состав таких фреймворков входят компоненты по работе с моделями данных, роутинг и конечно шаблонизатор. Angular, React, Ember, Backbone — фреймворки как раз из этой категории. К системным можно отнести инструменты, упрощающие работу с DOM, вспомогательные инструменты по работе с данными и так далее. Lodash, Underscore, jQuery — представители этой группы.

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

  • Рендеринг шаблонов
  • Роутинг и навигация
  • Биндинг и маппинг моделей на элементы интерфейса
  • CRUD-операции над моделями и взаимодействие с хранилищем (будь то на клиентской стороне или же не сервере)

Однако чудес не бывает на свете, и еще не был придуман универсальный фреймворк, который позволил бы решить абсолютно любую задачу штатными средствами. Почти всегда находятся моменты и задачки, которые не укладываются в привычную архитектуру выбранного фреймворка и разработчикам приходится, что называется, «плясать под дудку фреймворка» и изворачиваться для получения желаемого результата. Но данные проблемы всплывают не сразу, а уже в процессе, когда разработка идет полным ходом и выбран конкретный фреймворк и спроектирована архитектура приложения в целом.

Так что же лучше: бОльшая гибкость или меньше кода но с бОльшими ограничениями? Наверное, это краеугольный камень всех современных фреймворков и их разработчиков. Например, мой любимый backbone пошел по первому пути, он настолько гибок, что в реальности придется писать много рутинного кода, которого нет в других фреймворках. Именно поэтому появилась Marionette.js, которая дополняет бэкбон, беря на себя рутинные операции. С другой стороны, есть ExtJS, то есть Sencha, в котором есть все-все-все. Но стоит вам захотеть сделать нестандартный контрол и все, вам придется погрязнуть в внутренних дебрях фреймворка.

Сейчас с каждым днем появляется все больше и больше новых фреймворков, но все они ничем не отличаются от уже существующих, и только увеличивают дефрагментацию технологий. Никто не хочет попытаться решать более глобальные задачи. А как мне кажется, проблема именно в стандартах, протоколах и взаимодействии программных компонентов между собой. Наверное, это потому что веб еще очень молод, и у него все впереди. Именно поэтому есть просто REST, который описывает в общих чертах как должны быть устроены CRUD операции, а уже авторы фреймворков выбирают свою реализацию работы с данными. И поэтому нельзя просто так взять заменить один фреймворк другим, чтобы, не меняя бэкенд, получить работающую систему.

Мне очень нравится SOA подход к построению информационных систем, который основывается на модульности и использовании открытых стандартов, и в особенности пакет Oracle SOA Suite, который все это реализует. SOA Suite позволяет разработчикам и архитекторам сконцентрироваться на бизнес-процессах и функциях, и не тратить время на рутинные операции. Например, не надо думать о том, как токен авторизации пользователя будет передаваться по цепочке вызовов сервисов, SOA Suite берет такие задачи на себя. Или же, например, так называемые Human Task’и, то есть некоторые шаги в рамках бизнес-процессов, требующие вмешательства пользователей, скажем подтверждение транзакций на сумму больше 10000. От результата выполнения этой задачи, зависит дальнейшее выполнение алгоритма бизнес-процесса. Так вот, SOA Suite, опираясь на описание моделей в XSD, может сам сгенерировать формы, которые будут заполнены соответствующими данными и выдаваться пользователям для принятия решений. И разработчику не нужно об этом думать, его задача — спроектировать какая модель данных должна отправляться в Human task и какие ветки алгоритма будут задействованы в последствии. Хочется верить, что и в мире веба появится что-то подобное. Но это невозможно без наличия необходимых стандартов, описывающих и затрагивающих все этапы и грани разработки веб-приложения.

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