Главная › Интернет › Сравнение веб фреймворков. Как выбрать тот самый PHP-фреймворк. Сравнительное тестирование. Методика тестирования и тестовый стенд

Сравнение веб фреймворков. Как выбрать тот самый PHP-фреймворк. Сравнительное тестирование. Методика тестирования и тестовый стенд

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

Александр Макарчук , qb
У каждого фреймворка есть огромное количество поклонников и противников. При выборе фреймворка необходимо учитывать несколько факторов. Во-первых, фреймворк должен иметь ровно столько возможностей, сколько необходимо проекту. Излишний функционал не нужен, но при этом никогда не должно возникать ограничений при доработке проекта. Во-вторых, время разработки сайта не должно увеличиваться за счет выбора того или иного фреймворка. В-третьих, фреймворк должен быть достаточно распространен, для того чтобы проект можно было передать другому разработчику. Наконец, безопасность фреймворка - один из важнейших показателей. Все фреймворки хороши, если находятся в правильных руках.

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

Александр Макаров , Yii
Нужно проанализировать задачу, понять, что нужно от фреймворка, выбрать топ-5 подходящих, написать на них небольшое приложение и оставить тот, что показал себя лучше остальных.

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

Александр Смирнов , Greensight
Выбрать из известного набора фреймворков несложно, так как при проектировании сразу видна потребность в тех или иных технологиях. Далее стоит вопрос увеличения известных фреймворков, но тут уже каждый по-своему подходит. Мне кажется, что стоит в первую очередь изучить фреймворки, которые охватывают разные технологии и наиболее отличаются друг от друга. Например, какой-нибудь классический MVC фреймворк и что-нибудь с другим подходом.

Алексей Федоров , «Одноклассники»
Как и с любыми инструментами, ответ сильно зависит от сроков проекта. Если проект короткий, берите или то, с чем можно быстро стартовать (например, Bootstrap), или то, что хотите изучить и с чем вы хотите «поковыряться». Если проект длинный, лучше собирать собственную библиотеку компонентов.

2. Фреймворки содержат большое количество готового функционала и заметно ускоряют разработку проектов. По сути у технических руководителей проектов встает вопрос уже не какие языки выбирать, а какие фреймворки. Продолжится ли эта тенденция? Какие за этим кроются риски?

Александр Макарчук , qb
Зачастую встроенный готовый функционал позволяет собрать достаточно неплохую «коробку». При каком-либо отклонении приходится либо «костылить», либо «перепиливать» функционал. Тенденция будет усиливаться, так как время разработки - очень важный показатель. Но это приведет к тому, что в интернете будет появляться все больше и больше «кривых» сайтов.

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

Александр Макаров , Yii
Да, продолжится. Риски, главным образом, в найме специализирующихся на одном фреймворке сотрудников. Как только задачи выйдут за рамки фреймворка или возникнет необходимость в использовании другого фреймворка, такой сотрудник может показать себя плохо.

Алексей Персианов, Михаил Парфенюк , ADV
Если сегментация технических решений будет углубляться, то так и будет. Но в данный момент большинство фреймворков поддерживают схожий функционал, и сегментация не слишком высока. Специфичные решения есть только для самых массовых видов задач.

Александр Смирнов , Greensight
Да, выбор технологического решения напрямую зависит от потребностей проекта, изученного техническим руководителем инструментария и его способности сопоставить одно с другим. Выбор языка - это скорее вопрос ресурсов: насколько легко найти разработчика в команду, если будет потребность ее расширения и т.п.

Алексей Федоров , «Одноклассники»
Языки и фреймворки, особенно на поздних стадиях развития, это ортогональные вещи. В развитых экосистемах фреймворки, как правило, имеют API для работы с несколькими языками и наоборот: языки с большой экосистемой имеют множество фреймворков, готовых для использования.

В современных условиях при старте проекта с нуля выбор фреймворка действительно часто стоит на первом месте, еще до выбора языка. Если же вам достался legacy-проект, то, как правило, большого выбора у вас нет и язык вам достается «в наследство».

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

3. Какие факторы дают гарантию надежности и стабильности фреймворка? Что позволит смело использовать инструмент на продакшне?

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

Александр Макаров , Yii
Наличие стабильных релизов, большое количество пользователей, наличие автоматизированных тестов, наличие активности, open source.

Алексей Персианов, Михаил Парфенюк , ADV
Поддержка фреймворка, его совместимость с предыдущими версиями и комьюнити.

Александр Смирнов , Greensight
Грубыми, но, как правило, работающими показателями стабильности и качества фреймворка являются размер сообщества разработчиков, возраст фреймворка, количество успешных кейсов, аналогичных поставленной задаче, частота изменений и количество звездочек (лайков) в репозитории фреймворка. Конечно, это грубая оценка, но с нее можно начать, и углубляться в обзоры, отзывы и т.д.

Алексей Федоров , «Одноклассники»
Во-первых, это open source, то есть открытый код. Это некоторая гарантия того, что если у вас что-то сломается в продакшне, вы сможете починить это своими руками. Во-вторых, вендор. Вендор языка или фреймворка может давать вам те или иные гарантии, часто подкрепленные контрактом. В-третьих, обратная совместимость. На практике это выливается в использование правильных версий языков и библиотек. Не стоит тащить в ваш продакшн библиотеку версии 0.7: как правило, если у языка или фреймворка версия ниже, чем 1.0, то нет никаких гарантий обратной совместимости.

4. Каково направление развития фреймворков, как они будут изменяться в дальнейшем?

Александр Макарчук , qb
Как ни прескорбно, но, на мой взгляд, фреймворки будут двигаться по пути «облегчения» разработки. Типовые решения, готовые модули и прочее - все для того, чтобы неподготовленный человек смог развернуть сайт.

Алексей Зубань , Wow
Для многих популярных платформ период наращивания функциональности прошел. Сейчас развитие сфокусировано на увеличении быстродействия. Это справедливо и для frontend-, и для backend-фреймворков. В качестве частного решения может служить разбивка фреймворка на логические модули. Для проекта должен собираться комплект библиотек, решающих только необходимые задачи. А также ожидаю решений, все плотнее связывающих клиентскую и серверную часть, фреймворков с единым синтаксисом и логикой работы с контентом.

Алексей Персианов, Михаил Парфенюк , ADV
Я не вижу явного тренда, кроме того, что востребованные функциональные ниши заполняются решениями. К сожалению, очень медленно.

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

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

5. Какие еще фреймворки могут появиться? Какие области еще не закрыты и ждут появления своего удобного инструмента?

Александр Макаров , Yii
Абсолютно любые. Всегда можно сделать лучше.

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

Александр Смирнов , Greensight
Развитие фреймворков зависит от потребностей рынка и возможностей браузеров и пользовательских девайсов. Развитие фреймворков напрямую зависит от развития и появления новых платформ: Canvas, WebGL, Node.js - как только появлялись эти технологии, в скором времени появлялись и фреймворки по работе с ними. Как только появляется новая технология, она сразу обрастает соответствующими фреймворками.

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

6. Сейчас фреймворками называют довольно широкий набор решений и библиотек. Может ли это измениться, появится ли более конкретная терминология? В рейтинге мы разделили фреймворки на frontend и backend. Как еще можно типизировать все это множество фреймворков?

Александр Макарчук , qb
Можно, но необходимости в этом не вижу.

Александр Макаров , Yii
Терминология есть и давно. API-фреймворки, REST-фреймворки, фреймворки-грабберы, фреймворки для мобильной разработки, модульные сетки, адаптивные фреймворки, фреймворки для модульной верстки. Перечислять можно бесконечно.

Алексей Персианов, Михаил Парфенюк , ADV
Да, фреймворками называют как «монстров», так и маленькие библиотеки с единственной функцией. В ближайшее время придет понимание, что такое фреймворк и библиотека, и появится четкое разделение. Что касается типизации, то на данный момент как раз и есть две ветки.

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

7. Использование фреймворков в работе - временная мода или необходимость? Какие существуют доводы «за» и «против» использования фреймворков?

Александр Макарчук , qb
Безусловно, необходимость. Писать с нуля то, что написано во фреймворке и потом «латать дыры» - это наступать на чужие «грабли».

Алексей Зубань , Wow
Фреймворки, не навязанные извне технологии. Большинство из них создается коллективно заинтересованным сообществом разработчиков. И они вполне успешно решают актуальные проблемы, стоящие перед разработчиками. Фреймворки - добро. Другое дело, если инструмент используется неправильно или в неподходящих условиях, но это не минус технологии, это вопрос образования разработчиков.

Александр Макаров , Yii
Необходимость. Достичь той же скорости и качества без популярных решений сейчас трудно. На разработку с нуля аналога того же качества уйдут годы.

Алексей Персианов, Михаил Парфенюк , ADV
Использование фреймворков - это необходимость, которая ускоряет, стандартизирует и удешевляет разработку. Доводами «за» и «против» является распространенность фреймворка и его реальная необходимость проекту.

Александр Смирнов , Greensight
Использование фреймворков - это скорее неизбежность. Даже если вы решите писать приложение сложнее «Hello, world» с нуля, в результате все равно получится какой-нибудь фреймворк.

Алексей Федоров , «Одноклассники»
Использование готовых решений, с одной стороны, сильно ускоряет разработку и внедрение, а с другой - вносит в ваш проект чужой legacy-код с кучей своих багов и ограничений. Фреймворки - это слой, на котором работает ваше приложение. Под этим слоем лежит ваш рантайм, под ним - операционная система, а под ним - железо. И все это, заметьте - готовые решения. Я не вижу тренда ухода с готовых процессоров на процессоры собственной разработки или тренда перехода с готовых операционных систем на что-то самописное. И для фреймворков я такого тренда тоже не вижу.

8. Когда при разработке веб-проекта наступает уровень, после которого уже сложно и неперспективно для дальнейшего развития проекта использовать CMS и лучше писать проект на одном из фреймворков?

Александр Макарчук , qb
Выбирать платформу нужно на этапе проектирования, а не в какой-либо другой момент жизненного цикла проекта.

Алексей Зубань , Wow
Понятие CMS и фреймворка не конфликтуют между собой. CMS - это шаблонный интерфейс по управлению приложением. В основе CMS вполне могут быть использованы фреймворки. И решение о необходимости использования или создания такого интерфейса должно опираться на функциональность приложения. Нетиповые вещи сложнее реализовывать в шаблонных рамках. Большая гибкость фреймворков может быть полезна, когда над проектом работает несколько команд и/или необходимо внедрять системы непрерывной интеграции.

Александр Макаров , Yii
Никогда. Есть проекты, которые вписываются в CMS. Есть проекты, которые не вписываются в CMS. Инструмент надо выбирать по задаче, а не задачи подгонять под инструмент.

Алексей Персианов, Михаил Парфенюк , ADV
Когда становится понятно, что в обозримом плане развития проекта слишком много задач приходится писать практически с нуля.

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

Алексей Федоров , «Одноклассники»
Когда затраты на разработку и поддержку становятся слишком большими.

Мы продолжаем рассказывать о самых популярных и полезных инструментах для работы с языками. На этот раз речь пойдет о PHP-фреймворках.

Laravel

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

Последний пункт проявляется в следующих возможностях:

Поддержка сторонних модулей, коих немалое количество, что значительно расширяет стандартные возможности фреймворка.
Обратная маршрутизация, позволяющая вам не тратить время на обновление ссылок при работе - всё происходит автоматически.
Шаблоны проектирования Eloquent ORM, что помогает в определении строгих отношений между объектами БД.
Автоматическая загрузка классов. Это, с одной стороны, уменьшает объем кода из-за отсутствия необходимости писать include…, с другой стороны - неиспользуемые классы не подключаются со всеми вытекающими.
Модульное тестирование - наличие большого числа тестов для предотвращения наслоения ошибок.
Система управления версиями БД. Если вы предполагаете часто несущественно обновлять свой продукт - данная функция позволит вам не тратить время на однотипные записи.

Как вы понимаете, это далеко не полный перечень возможностей, которые предоставляют своим клиентам разработчики Laravel. За полным перечнем обращайтесь на официальный сайт или окунитесь в мир данного фреймворка лично - вам обязательно понравится.

CodeIgniter

Данный фреймворк, которому уже более 11 лет, снискал славу благодаря непритязательности относительно используемых ресурсов, простоте, удобству, огромному количеству документации, рассчитанной на разработчиков любого уровня, отсутствию ограничений. В свое время Laravel создавался именно как конкурент CodeIgniter, так что до недавнего времени это был всеобщий ориентир.

Несмотря на простоту, как у любого популярного фреймворка, у CodeIgniter также есть парочка полезных особенностей:

Большая поддержка сообщества CodeIgniter Reactor, в том числе библиотеки, модули, шаблоны и документация.
Шаблоны для работы с БД, которые очень похожи на синтаксис SQL.
Возможность кэширования на стороне сервера.
Использование менеджера пакетов для быстрого подключения библиотек из командной строки.

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

Symfony

Несмотря на то, что релиз третьей версии состоялся еще в 2015 году, именно вторая версия Symfony единолично удерживает 3-е место по популярности среди фреймворков. Причина здесь схожа c CodeIgniter - скорость работы и общая простота. Но чтобы это не шло в разрез с функциональностью, пользователю предлагается выбрать одну из 3 версий для профильной работы:

Standard Edition - для знакомства и выполнения общих задач. На ней основан дистрибутив Hello World Edition, который содержит ровно один скрипт оптимизации для дальнейшего использования в бенчмарках.
Symfony CMF - адаптация для разработчиков, работающих с CMS-системами.
REST Edition - оптимизация для работы с REST-архитектурой (интернет-магазины, поисковые системы и т.д.).

Стереотипно считается, что Symfony - это фреймворк для любителей командной строки. Действительно, встроенный интерфейс SensioGeneratorBundle поможет вам из одной строки текста получить целый скелет для вашего кода.

Несомненным плюсом будет наличие официальной документации на русском языке. Стоит оговориться, что доступна она только для первой версии Symfony, но среди неофициальных релизов вы найдете и переводы официальных релизов, и самостоятельную качественную документацию.

Yii

Yii во многих рейтингах преподносится как главный конкурент Symfony. Основания для этого действительно есть: оба языка работают с полным стеком, у обоих исходники на GitHub, оба достаточно качественно представляют шаблонную разработку. Однако в то время как Symfony предоставляет лишь модель и контроллер, в Yii реализована полноценное MVC-взаимодействие. Кроме того, интерфейс в Yii куда удобнее, генерация кода с помощью браузерного элемента Gii здесь немного мощнее, да и вообще по факту Yii позволит вам сэкономить больше времени на разработке, а приложение будет работать чуть быстрее.

Nette Framework

Пожалуй, наименее известный из топовых PHP-фреймворков, что удивительно на фоне его 13-летнего возраста и широких возможностей. Вот некоторые из них:

Один из самых производительных PHP-фреймворков .
Прекрасно подойдет для новичков, кривая обучения достаточно плавная.
Мощные инструменты в помощь: Tracy - для отслеживания ошибок, Latte - быстрый и интуитивно понятный генератор шаблонов, Tester - утилита для качественного тестирования вашего приложения в приближенных к реальным условиям.
Возможность коллективной работы нескольких разработчиков над одним проектом.
Прекрасная документация и дружелюбное сообщество (и не только на чешском языке).

В общем, если вы еще не попробовали Nette - рекомендуем, если нашли какие-то недостатки - обязательно пишите в комментариях.

Короткой строкой

CakePHP - популярный клон Ruby on Rails, только ориентированный на PHP. Все преимущества также схожи.

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

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

Fat-Free - очень лёгкий, быстрый и простой фреймворк для разработки на скорую руку. Минимум посторонних забот.

Slim - этот фреймворк простой для изучения и начала работы с PHP, но практически не востребован во взрослом профессиональном мире веба.

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

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

Что такое веб-фреймворк

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

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

Типы веб-фреймворков

У фреймворков есть две основные функции: работа на серверной стороне (бэкенд) и работа на клиентской стороне (фронтенд).

Фронтенд-фреймворки связаны с внешней частью приложения. Простыми словами, они отвечают за внешний вид приложения. Бэкенд отвечает за внутренне устройство приложения. Рассмотрим оба типа поподробнее.

Серверные фреймворки . Правила и архитектура таких фреймворков не даёт возможности создать веб-приложение с богатым интерфейсом. Они ограничены в своей функциональности, однако вы всё равно можете создавать простые страницы и разные формы. Также они могут формировать выходные данные и отвечать за безопасность в случае атак. Всё это определённо может упростить процесс разработки. Серверные фреймворки в основном отвечают за отдельные, но критически важные части приложения, без которых оно не сможет нормально работать. Вот несколько самых популярных фреймворков и языки, с которыми они работают:

Django - Python;
Zend - PHP;
Express.js - JavaScript;
Ruby on Rails - Ruby.

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

Backbone+Marionette;
Angular;
Ember.js;
Vue.js.

Все эти фреймворки используют JavaScript.

Многофункциональные фреймворки . Meteor известен как фулл-стек веб-фреймворк. Это значит, что он удовлетворяет почти все потребности как со стороны клиента, так и со стороны сервера, что делает Meteor чрезвычайно популярным. Вам не нужно тратить время на то, чтобы наладить взаимодействие между двумя фреймворками через REST API - вы можете просто выбрать Meteor и ускорить процесс разработки. Но это не главная особенность этого фреймворка. Обе стороны - серверная и клиентская - работают на одном языке, поэтому вы можете создавать и использовать для них один и тот же код. Следующая особенность - «режим реального времени» - когда вы что-то меняете в одном интерфейсе, изменения происходят и в остальных. В качестве примера можно взять документ или таблицу с общим доступом. Когда вы добавляете комментарии или как-то изменяете содержимое, другие пользователи тоже это видят.

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

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

Например, если ваше приложение основано на Django и вам нужны веб-сокеты, то вы можете воспользоваться микрофреймворком aiohttp.

Другой пример: если ваше приложение не очень большое и вам нужна только простая маршрутизация URL и шаблоны с несложным контекстом, вы можете использовать Flask с Jinja2 (или другим шаблонизатором) вместо Django.

Особенности и архитектура

Несмотря на то, что все фреймворки отличаются друг от друга и выбрать какой-нибудь из них может быть очень сложно, есть несколько вещей, общих для них всех. Речь идёт об архитектуре и особенностях, которые так же важны, как и функции.

Архитектура

Архитектура почти всех фреймворков основана на декомпозиции нескольких отдельных слоёв (приложения, модули и т.д.), что означает, что вы можете расширять функциональность исходя из своих потребностей и использовать изменённую версию вместе с кодом фреймворка или использовать сторонние приложения. Такая гибкость является ещё одним ключевым преимуществом фреймворков. Существует множество open-source сообществ и коммерческих организаций, которые создают приложения или расширения для популярных фреймворков, например, Django REST Framework, ng-bootstrap и т.д.

MVC - Модель, Представление и Контроллер (Model-View-Controller) - три составляющих каждого веб-фреймворка.

Модель содержит все данные и уровни бизнес-логики, её правила и функции.

Представление отвечает за визуальное отображение данных, например, диаграммы, графики и т.д.

Контроллер просто трансформирует данные для команд предыдущих двух составляющих.

Они неотделимы друг от друга, поэтому важно как следует во всём разобраться, чтобы избежать ошибок во время работы приложения.

Особенности

Теперь давайте посмотрим на некоторые общие особенности, которые делают фреймворки многофункциональными и удобными на практике.

Веб-кэширование

Кэширование просто помогает хранить разные документы и позволяет избежать надоедливой перегрузки сервера. Пользователи могут использовать его в разных системах при определённых условиях. Также оно работает на серверной стороне. Например, вы могли заметить кэшированные веб-страницы на странице результатов поисковой выдачи Google.

Скаффолдинг

Если ваш выбор пал на Ruby on Rails, можете заглянуть в это , которое описывает все «за» и «против» этого фреймворка и учит всему необходимому, начиная с установки.

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

Если у вас появляются какие-то вопросы, то стоит заглянуть на StackOverflow .

Этим сайтом пользуются разработчики по всему миру. Здесь они делятся своим опытом и помогают другим решать их проблемы. Просто задайте вопрос, и вам предложат несколько возможных решений.

Итак, с фреймворками не так сложно разобраться, как кажется. Не тратьте время на панику - посмотрите пару руководств и попробуйте поработать со своим первым фреймворком.

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

Для этого нужно учесть достаточно большое количество характеристик, от «как быстро всё будет работать» до «а необходима ли нам эта фича?». И так каждый раз. Именно в моменты мозгового штурма команда сравнивает удобство фреймворка, скорость, набор фич, которые реализованы в нем или в совместимых с ним модулях.

Но какой же всё-таки лучше, быстрее и производительнее?

Разработчики постоянно проводят сравнение фреймворков, чтобы прояснить для себя этот вопрос. Например, в статье Lukasz Kujawa приведено сравнение PHP фреймворков. Одно «но» - статья за 2013 год. А ведь время идёт… Поэтому мы решили провести своё, актуальное сравнение фреймворков.

Для оценки производительности был использован PHP Framework Benchmark . Он предлагает для сравнения множество фреймворков (не только указанных выше), но автор не спешит добавлять в репозиторий новые версии проектов, что, конечно же, печально, хотя и не смертельно. При желании добавить новую версию не сложно.  

Одной из основных целей данной статьи также является попытка практическим путем определить улучшения в производительности и эффективности новых версий PHP. Поэтому тестирование было проведено на РНР 5.6/7.0/7.1

Что будем сравнивать?

Для сравнения были выбраны следующие фреймворки:

slim-3.0
ci-3.0
lumen-5.1
yii-2.0
silex-1.3
fuel-1.8
phpixie-3.2
zf-2.5
zf-3.0
symfony-2.7
symfony-3.0
laravel-5.3
laravel-5.4
bluz (версия 7.0.0 - для РНР5.6 и версия 7.4 для РНР7.0 и выше)
ze-1.0
phalcon-3.0

Тестирование условно разделено на 4 вида:

производительность (throughput),
занимаемая память (memory),
время выполнения (exec time),
количество подключаемых файлов (included files).

Методика тестирования и тестовый стенд

Машина, на которой производилось тестирование, обладает следующими характеристиками:

Operation system: Linux Mint 17 Cinnamon 64-bit
Cinnamin Version 2.2.16
Linux Kernel: 3.13.0-24-generic
Processor: Intel Core i3-4160 CPU 3.60 Ghz X 2
Memory: 8 GB

Server version: Apache/2.4.7 (ubuntu)
Server build: Jul 15 2016
php 7.1 / php7.0 / php5.6

Вводим команду git clone https://github.com/kenjis/php-framework-benchmark - и фрейм уже на нашей машине. Поскольку мы использовали Mint, необходимо выполнить настройку:  

# Added net.netfilter.nf_conntrack_max = 100000 net.nf_conntrack_max = 100000 net.ipv4.tcp_max_tw_buckets = 180000 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 10

Sudo sysctl -p

Немного о структуре самого php-framework-benchmark:

/benchmarks - содержит bash-скрипты, отвечающие за сбор информации о количестве запросов в секунду (при помощи утилиты ab), количестве информации, сколько времени было потрачено и сколько файлов вызывалось из файла «точки старта».

/lib - директория, в которой находятся файлы, отвечающие за обработку полученной информации после вывода страницы “Hello world”, вывод таблиц с результатами и построение диаграмм.

/output - директория, в которую добавляются логи после выполнения тестирования. Здесь находится по два файла для каждого протестированного файла: .ab.log - лог после работы утилиты ab, и.output - содержит информацию, которая была выведена на экран (обычно это hello world и данные по памяти, времени выполнения, использовавшимся файлам).

Остальные папки - это заготовки фреймов, в которые уже добавлен один контроллер, который вернет строку “hello world” при обращении по URI, составленному по правилам обращения к данному фреймворку.

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

Команда bash setup.sh настроит те фремворки, которые описаны в файле list.sh. Вы можете его редактировать: добавлять и удалять папки для тестирования. То есть конфигурировать так, как вам необходимо.

Командой bash setup.sh fatfree-3.5/ slim-3.0/ lumen-5.1/ silex-1.3/ вы можете установить какие-то отдельные фреймворки, задав их параметрами к команде. В некоторых случаях это удобно, но мы использовали первый подход.

После произведенной настройки фреймворков, мы запустили тестирование при помощи bash benchmark.sh .

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

Для отображения графиков мы воспользовались ссылкой http://localhost/php-framework-benchmark/ .

Как вы понимаете, необходимо было произвести настройку Apache и заставить его смотреть в папку с фреймом. Всё это описано в readme, поэтому вопросов не возникает.

Результаты тестирования фреймворков

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

Первая форма - это наглядный тип представления. Каждая характеристика содержит 4 диаграммы. Каждая диаграмма отображает сравнение фреймворков между собой, плюс накопительная диаграмма. Она была построена при использовании определенной версии РНР. Таким образом можно проследить эволюцию улучшений в PHP и фреймворках.

Вторая форма - это результат тестирования в виде таблицы (хватить наглядности, давайте говорить серьезно - дайте мне больше чисел!).

Производительность (throughput)

Применительно к нашей ситуации, характеристика throughput измеряется в количестве запросов, которые наш фреймворк может обработать в течении секунды. Следовательно, чем выше это число, тем более производительно наше приложение, поскольку оно сможет корректно обрабатывать запросы большого количества пользователей.

Мы получили следующие результаты (запросы в секунду):

	php 5.6	php 7.0	php 7.1
phalcon-3.1.2	5058.00	5130.00	7535.00
ci-3.0	2943.55	4116.31	4998.05
slim-3.0	2074.59	3143.94	3681.00
yii-2.0	1256.31	2276.37	2664.61
silex-1.3	1401.92	2263.90	2576.22
lumen-5.1	1316.46	2384.24	2741.81
ze-1.0	1181.14	1989.99	1741.81
phpixie-3.2	898.63	1677.15	1896.23
fuel-1.8	1044.77	1646.67	1770.13
bluz-7.3.1	- *	1774.00	1890.00
zf-2.5	198.66	623.71	739.12
zf-3.0	447.88	1012.57	1197.26
symfony-2.7	360.03	873.40	989.57
symfony-3.0	372.19	853.51	1022.28
laravel-5.3	258.62	346.25	625.99
laravel-5.4	219.82	413.49	600.42

Для наглядности построили графики для каждой версии PHP:

PHP5.6:

PHP7.0:

PHP7.1:

Занимаемая память (peak memory)

Эта характеристика (в мегабайтах) отвечает за количество занимаемой фреймворком памяти при выполнении поставленной перед ним задачи. Чем меньше данное число, тем лучше для нас и для сервера:

	php 5.6	php 7.0	php 7.1
phalcon-3.1.2	0.27	0.38	0.37
ci-3.0	0.42	0.38	0.38
slim-3.0	0.61	0.55	0.55
yii-2.0	1.31	0.91	0.91
silex-1.3	0.74	0.65	0.65
lumen-5.1	0.80	0.63	0.63
ze-1.0	0.79	0.56	0.56
phpixie-3.2	1.22	0.82	0.82
fuel-1.8	0.7	0.6	0.6
bluz-7.3.1	- *	0.69	0.69
zf-2.5	3.06	1.34	1.34
zf-3.0	2.12	1.09	1.08
symfony-2.7	3.11	1.41	1.42
symfony-3.0	2.86	1.30	1.32
laravel-5.3	2.91	2.04	2.04
laravel-5.4	3.04	1.45	1.49

* - bluz-7.3.1 не поддерживает php 5.6

PHP 5.6:

PHP 7.0:

PHP 7.1:

Сводная накопительная диаграмма (по фреймворкам):

Время выполнения

Время выполнения - время, затрачиваемое системой для выполнения поставленной задачи. Измеряется от начала выполнения задачи до выдачи результата системой.

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

Время приведено в миллисекундах (ms):

	php 5.6	php 7.0	php 7.1
phalcon-3.1.2	1.300	1.470	1.080
ci-3.0	0.996	0.818	1.007
slim-3.0	1.530	1.228	0.662
yii-2.0	1.478	1.410	1.639
silex-1.3	4.657	1.625	2.681
lumen-5.1	2.121	1.829	1.228
ze-1.0	2.629	2.069	1.528
phpixie-3.2	9.329	4.757	1.911
fuel-1.8	3.283	2.684	1.425
bluz-7.3.1	- *	1.619	1.921
zf-2.5	22.042	5.011	3.998
zf-3.0	12.680	2.506	2.989
symfony-2.7	6.529	3.902	2.384
symfony-3.0	9.335	3.987	2.820
laravel-5.3	19.885	4.840	2.622
laravel-5.4	19.561	4.758	3.940

PHP 5.6:

PHP 7.0:

PHP 7.1:

Сводная накопительная диаграмма (по фреймворкам):

Подключаемые файлы

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

phalcon-3.1.2	5
ci-3.0	26
slim-3.0	53
yii-2.0	46
silex-1.3	63
lumen-5.1	37
ze-1.0	68
phpixie-3.2	163
fuel-1.8	53
bluz-7.3.1	95
zf-2.5	222
zf-3.0	188
symfony-2.7	110
symfony-3.0	192
laravel-5.3	38
laravel-5.4	176

Разница в количестве подключаемых файлов между Laravel 5.3 и Laravel 5.4 может показаться странной и дать повод к обсуждениям, спорам и т.п. Спешим разъяснить ситуацию. Как вы знаете, с помощью команды

Php artisan optimize --force

В Laravel 5.3 можно сгенерировать файл compiled.php, и тем самым уменьшить количество подключаемых файлов, собрав их в один. Но есть одно «но»: команды для генерации этого файла в Laravel 5.4 больше нет. Разработчик решил удалить эту фичу, так как посчитал (https://github.com/laravel/framework/pull/17003), что для настройки производительности лучше использовать opcache.

Стоит ли обновляться?

Сводные данные по версиям более чем наглядно показывают, какой произойдет прирост производительности и эффективности использования ресурсов при переходе (или изначальном выборе) на новую версию PHP.

При переходе с PHP 5.6 на PHP 7.0 средний прирост производительности составил почти +90%, при этом минимальный прирост производительности составил +33% для Laravel 5.3, а максимум - >200% для Zend Framework 2.5.

Переход с версии 7.0 на 7.1 уже не так шокирует, но всё же в среднем даёт почти 20% прирост производительности.

Сведя все полученные данные по производительности различных версий PHP, получим вот такие «матрасы»:

Забавный факт : Laravel 5.3 показал наименьший прирост производительности при миграции с PHP 5.6 на PHP 7.0, но при этом наибольший прирост при миграции с версии 7.0 на версию 7.1, и как итог - производительность Laravel 5.3 и 5.4 на PHP 7.1 практически одинакова.

Потребление памяти тоже оптимизировали, так что переход с PHP 5.6 на PHP 7.0 позволит вашему приложению потреблять на 30% меньшем памяти.

Обновление с версии 7.0 до версии 7.1 практически не даёт прироста, а в последних Symfony и Laravel так и вовсе уходим в «минус», потому что они начинают чуть больше «кушать».

Осталось ещё посмотреть на время выполнения, и да, тут тоже всё отлично:

переезд с PHP 5.6 на PHP 7.0 подарит вам ускорение в среднем на 44%.
переезд с PHP 7.0 на PHP 7.1 подарит вам ускорение ещё на 14%.

Примечание. Тестирование при помощи ab - с чем мы столкнулись

«А что со slim и phpixie» - этот вопрос подтолкнул на расследование поведения утилиты ab при взаимодействии с этими фреймворками.

Выполним тест отдельно для Slim-3.0:

Ab -c 10 -t 3 http://localhost/php-framework-benchmark/slim-3.0/index.php/hello/index

Concurrency Level: 10
Time taken for tests: 5.005 seconds
Complete requests: 2
Failed requests: 0
Total transferred: 1800 bytes
HTML transferred: 330 bytes
Requests per second: 0.40 [#/sec] (mean)
Time per request: 25024.485 (mean)
Time per request: 2502.448 (mean, across all concurrent requests)
Transfer rate: 0.35 received

Что-то не так - количество запросов в секунду всего 0.4 (!)

Ab -c 10 -t 3 http://localhost/php-framework-benchmark/laravel-5.4/public/index.php/hello/index

Concurrency Level: 10
Time taken for tests: 3.004 seconds
Complete requests: 1961
Failed requests: 0
Total transferred: 1995682 bytes
HTML transferred: 66708 bytes
Requests per second: 652.86 [#/sec] (mean)
Time per request: 15.317 (mean)
Time per request: 1.532 (mean, across all concurrent requests)
Transfer rate: 648.83 received

Дело было в Keep Alive соединении, подробнее можно узнать тут.

“When you make requests with «Connection: keep-alive» the subsequent request to the server will use the same TCP connection. This is called HTTP persistent connection. This helps in reduction CPU load on server side and improves latency/response time.
If a request is made with «Connection: close» this indicates that once the request has been made the server needs to close the connection. And so for each request a new TCP connection will be established.
By default HTTP 1.1 client/server uses keep-alive where as HTTP 1.0 client/server don’t support keep-alive by default.”

Таким образом, тест для Slim должен выглядеть так:

Ab -H "Connection: close" -c 10 -t 3 http://localhost/php-framework-benchmark/slim-3.0/index.php/hello/index

Concurrency Level: 10
Time taken for tests: 3.000 seconds
Complete requests: 10709
Failed requests: 0
Total transferred: 2131091 bytes
HTML transferred: 353397 bytes
Requests per second: 3569.53 [#/sec] (mean)
Time per request: 2.801 (mean)
Time per request: 0.280 (mean, across all concurrent requests)
Transfer rate: 693.69 received

Заключение

Как и стоило ожидать безоговорочным лидером по производительности (но не скорости разработки) является Phalcon. Второе место, - а на самом деле первое среди PHP-фреймворков (а не C, на котором написан исходный код Phalcon) - занимает CodeIgniter 3!

Конечно же, не стоит забывать, что каждому инструменту своё предназначение. Если вы выбираете небольшой и легкий фреймворк и собираетесь написать на нём что-то отличное от простейших приложений или REST API, то, скорее всего, вы столкнётесь с проблемами при расширении функционала. И наоборот - избыточность полнофункциональных, больших фреймворков повлечёт за собой финансовые издержки на содержание хостинга даже для элементарных приложений под большой нагрузкой.

Это тестирование проводилось для того, чтобы убедить/рассказать/укрепить позицию языка РНР версий 7.0 и 7.1 в вашем сознании и в будущих проектах, донести информацию о том, что производительность действительно возросла.

Рефакторинг внутренних структур данных и добавление дополнительного этапа перед компиляцией кода в виде абстрактного синтаксического дерева - Abstract Syntax Tree (AST), - привели к превосходной производительности и более эффективному распределению памяти. Результаты сами по себе выглядят многообещающе: тесты, выполненные на реальных приложениях, показывают, что PHP 7 в среднем вдвое быстрее PHP 5.6, а также использует на 50% меньше памяти во время обработки запросов, что делает PHP 7 сильным соперником для компилятора HHVM JIT от Facebook.

Тесты полностью подтверждают и вдвое ускорившуюся обработку запроса в РНР7, и уменьшенное количество используемой памяти.

Вышла серия статей , посвящённая фреймворкам для разработки веб-приложений. А именно, в этих материалах исследованы платформы Angular 2+, React + Redux, Vue.js, Dojo 2, Ember и Aurelia.

Разработка веб-приложений без использования фреймворков - это, отчасти, согласие следовать за этими платформами и не пользоваться плодами трудов команд-разработчиков фреймворков, часто работающих в тесной связи с создателями браузеров. Фактически, разработчик, отказывающийся от фреймворков, как бы говорит о веб-технологиях: «Я смогу приручить этого дикого зверя».

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

Тут следует избегать ловушки, когда кажется, что все современные компании обладают одинаковыми возможностями. Конечно, существуют организации, где инновации в использовании и применении веб-технологий повышают их рыночную жизнеспособность. Например - Google, Facebook и Netflix. К большинству компаний это не относится и они должны это принять.

Angular 2+

▍Сильные стороны

Главное преимущество Angular 2+ - это его популярность. Можно говорить о том, что с ним связано имя компании Google и это влияет на то, как его воспринимают. Angular 1 быстро стал популярным так как те, кто пришёл из других сред разработки обнаружили в нём знакомый шаблон MVC для создания одностраничных приложений. После модернизации Angular 1 и перепроектирования некоторых частей фреймворка, Angular 2+ буквально выстрелил. Впечатляет число тренингов по нему, официальных и неофициальных. На рынке имеется серьёзная потребность в Angular-разработчиках. Кроме того, это - один из немногих фреймворков, рассмотренных в этом материале, у которого имеется официальный набор богатых возможностями компонентов для создания пользовательских интерфейсов.

Мы полагаем, что Angular сосредоточен на создании пользовательских интерфейсов одностраничных приложений и не соответствует нуждам разработчиков более крупных проектов. Это может привести к сложности поддержки проектов, если базовые принципы, на которых они основаны, не были чётко сформулированы в самом начале их разработки. На практике разработчикам приходится прибегать к чудесами изобретательности для того, чтобы заставить приложение на Angular делать то, что не является частью фреймворка. Это, кроме того, снижает интерес разработчиков к TypeScript, на котором написан фреймворк.

▍Будущее фреймворка

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

Как в любой большой организации, в Google есть множество людей. Снаружи взаимодействие тех, кто занимается Angular, и тех, кто работает над реализацией веб-стандартов в браузере, выглядит гармонично. Мы полагаем, что эта гармония, на самом деле, лишь видимость, и что в реальности Angular не даёт эффективных средств применения веб-компонентов и создания прогрессивных веб-приложений. По нашему мнению, стандарты, принятые в индустрии веб-разработки, вытеснят некоторые подходы, применяемые в Angular. В результате мы можем столкнуться, в среднесрочной и долгосрочной перспективах, с воздействием стандартов на то, как будут создаваться и проектироваться Angular-приложения. Это несёт в себе определённый риск.

▍Почему стоит выбрать Angular 2+?

Если вам нужно, чтобы специалистов по фреймворку было несложно найти в необходимых количествах, и чтобы знания этих специалистов можно было использовать в других областях, или вам нужно подготовить команду к работе с фреймворком и у вас есть некоторый уровень уверенности в том, что команда сможет, в короткие сроки, перейти к продуктивной работе, вы можете остановиться на Angular 2+. Однако, учитывайте, что Angular 1 (Angular.js) серьёзно отличается от современной версии фреймворка, и приложения, а также навыки и опыт разработчиков, нельзя напрямую перенести в Angular 2+.

Если архитектура вашего веб-приложения соответствует шаблону MVC, тогда вы тоже можете рассмотреть Angular 2+.

Если вам нравится подход к дизайну Google Material UX, тогда набор компонентов Angular Material - это быстрый, простой и надёжный способ всем этим воспользоваться.

React + Redux

▍Сильные стороны

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

▍Слабые стороны и возможные сложности при внедрении

Самые большие минусы React и Redux заключаются не в особенностях реализации того, что они умеют, а в том, чего они не могут. Для того, чтобы создать сложное веб-приложение, вам понадобится много других технологий. Как только вы отойдёте от основных функций React, Redux и пары других библиотек, вы столкнётесь с множеством мнений о «правильных инструментах», с бесчисленным количеством решений и шаблонов, которые иногда легко интегрировать в приложение, а иногда - нет.

Итак, так как React и Redux - библиотеки, которые сосредоточены на решении узкого круга специализированных задач, неопытные команды могут очень легко сделать на их основе нечто неподдерживаемое, не зная о том, что решения, которые они принимают, ведут к ухудшению производительности веб-приложений или к ошибкам. Даже опытные разработчики могут столкнуться с тем, что недостаток чёткого архитектурного планирования решения или строгих правил в начале разработки могут очень неприятно сказаться на проекте в будущем.

Легко обмануть себя мнимой экономией времени и ресурсов, которая заключается в том, что использование React и Redux во всей организации смягчит проблемы с эффективностью разработки. Без тщательно проработанных соглашений и стандартизации других библиотек и шаблонов, переход на React и Redux сродни заявлению: «Мы переходим на JavaScript для того, чтобы писать приложения и повысить эффективность работы».

▍Будущее фреймворка

Facebook и разработчики React, сравнительно недавно, начали прислушиваться к мнению сообщества. Мы полагаем, это помогло Facebook понять, что компания не может больше действовать по принципам: «Мы лучше разработчиков знаем, что им нужно», и: «Верьте в наш подход» в деле развития своих проектов. Хочется надеяться, что это движение продолжится, отразится на возможностях и на направлении развития React и связанных с ним проектов.

Рассматривая React и Redux, сложно предсказать будущее. Однако, то, что эти библиотеки узкоспециализированы, очень серьёзно увеличило их распространение, большинство шаблонов React + Redux продвигают разделённую архитектуру, которая способствует лёгкому рефакторингу и простоте применения итеративного подхода в разработке. Пару лет назад все говорили о связке React + Flux, но сообщество разработчиков быстро приняло Redux. Вероятно, и другие серьёзные изменения в моделях работы или шаблонах могут быть приняты так же легко. С этой лёгкость в восприятии нового, вероятно, мы встретимся и в будущем.

▍Почему стоит выбрать React + Redux?

Если вы находитесь в ситуации, когда вы ищете скорее хорошие библиотеки, нежели некий всеобъемлющий фреймворк, тогда, вполне возможно, связка React + Redux хорошо вам подойдёт. Кроме того, тут следует реалистично смотреть на возможности вашей команды и организации, не только на этапе первоначальной разработки, но и с учётом долгосрочной поддержки приложения.

Vue.js

▍Сильные стороны

Вероятно, главный плюс этого фреймворка заключается в возможности его постепенного внедрения. Vue отличается понятной и рациональной архитектурой, которую несложно освоить и просто применять на практике.

Существует сплочённое сообщество энтузиастов и сторонние проекты, которые делают Vue.js ещё интереснее. Кроме того, разные разработки, ориентированные на Vue, довольно просто совмещать в более сложных решения при создании новых проектов.

▍Слабые стороны и возможные сложности при внедрении

Желание как-то извернуться между идеями приложений, основанных на шаблоне MVC, и приложениях, основанных на контейнерах состояния, может запутать. Кажется, что у разработчиков фреймворка есть стремление сделать всё качественно, при этом не давая преимущества одному шаблону разработки приложений перед другим. Нам кажется, что это, как минимум, сбивает с толку тех, кто ищет в Vue.js платформу для полномасштабного веб-решения, и может привести к применению разных шаблонов, что, в итоге, усложнит поддержку приложения.

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

Мы полагаем, что хорошо бы увидеть в Vue.js интеграцию новых стандартов, однако сейчас мы видим в нём нечто вроде шаблона веб-компонентов, но не сами веб-компоненты, то есть, речь идёт скорее о планах внедрения новых технологий, а не о том, что уже реализовано.

▍Будущее фреймворка

Хотя Vue.js широко применяется и используется в разных проектах, сложно предсказать, что будет с фреймворком в среднесрочной перспективе. Его не поддерживают напрямую коммерческие организации, таким образом, его развитие во многом зависит от желаний и возможностей его разработчиков.

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

▍Почему стоит выбрать Vue.js?

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

Dojo 2

▍Сильные стороны

Dojo заполняет множество пробелов, которые существуют в чём-то вроде React + Redux. Речь идёт о том, что его создатели пытаются сформировать целостную среду разработки на основе шаблона реактивных компонентов, построенных на архитектуре контейнеров состояний.
При разработке Dojo 2 учитывается то, что он существует не в «безвоздушном пространстве». Он включает в себя возможности импорта и экспорта веб-компонентов и построен с учётом существования различных сценариев использования, которые надо поддерживать, но, в то же время, даёт возможности структурированного фреймворка, отличающегося определёнными особенностями. Кроме того, в основном функционале Dojo 2 большое внимание уделено модульности компонентов платформы.

Dojo 2 даёт решения для многих типичных задач, и возможности, наличие которых важно для полномасштабных веб-приложений, которым в большинстве других фреймворков особого внимания не уделяется. В частности, тут есть система интернационализации и шаблоны для обеспечения доступности приложений. Кроме того, здесь есть поддержка тем и шаблоны, которые ориентированы на аспекты разработки, выходящие за пределы TypeScript/JavaScript, например, на работу с ресурсами вроде CSS.

Dojo 2 нацелен на предоставление структурированного окружения разработки, удобного для программиста. Благодаря использованию TypeScript и различных шаблонов, он пытается дать разработчикам нечто вроде направляющих, ведущих их по пути продуктивной работы, но при этом не сковывает тех, кто точно знает, что делает. Фреймворк ориентирован на то, чтобы сделать разработку более продуктивной и безопасной. Его цель - дать командам разработчиков возможность быстро создавать более качественные веб-приложения.

▍Слабые стороны и возможные сложности при внедрении

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

Проблемой может стать то, что стремление к гибкости, к взаимозаменяемости компонентов, может поставить под вопрос сам смысл существования Dojo 2, не давая каких-либо внятных причин его использовать.

▍Будущее фреймворка

Будущее Dojo 2 зависит от него самого. Его разработчики, вероятнее всего, продолжат пытаться давать чёткие шаблоны и руководящие принципы для создания масштабных веб-приложений. В ходе развития стандартов создатели Dojo 2 будут стремиться включить их в фреймворк, интегрировать их в его механизмы. Скорее всего, Dojo 2 будет стремиться к открытости и модульности, в то время как команда его разработчиков не может не понимать, что им вряд ли удастся создать универсальное решение, которое всегда сможет соответствовать нуждам любых проектов.

▍Почему стоит выбрать Dojo 2?

Если вы хотите освоить гибкую и современную реактивную архитектуру веб-приложений, и при этом хотите, чтобы к вашим услугам были продуманные стандартные пути решения проблем, тогда Dojo 2 - это хороший выбор. Вместо того, чтобы собирать всё из разных кусков и придумывать некие правила для своего проекта, вы можете сосредоточиться на разработке функционала и быть уверенным в том, что то, что получится, весьма вероятно, будет готово к продакшну. Кроме того, Dojo 2 подойдёт тем, кто высоко ценит возможности TypeScript.

Ember

▍Сильные стороны

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

За годы существования Ember.js показал, что его команда может поддерживать фреймворк и своевременно интегрировать в него современные стандарты, но, в то же время, не забрасывать старые браузеры.

Ember имеет чёткую и рациональную архитектуру, подходящую для разработки сложных веб-приложений.

▍Слабые стороны и возможные сложности при внедрении

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

Определённые сложности может вызывать и то, что тут нет стандартного набора элементов пользовательского интерфейса, поэтому приходится пользоваться такими наборами сторонних разработчиков. Вероятно, может показаться неудобным и то, что эти наборы нельзя назвать всеобъемлющими, недостающие компоненты придётся искать или создавать самостоятельно. Так как Ember.js не регламентирует взаимодействие с DOM, вы можете оказаться в ситуации, когда в вашем проекте имеются неоднородные компоненты, из которых построен пользовательский интерфейс, которым не очень удобно управлять.

▍Будущее фреймворка

Разработчики, вносящие основной вклад в развитие Ember, являются и участниками комитета TC39, который занимается стандартизацией JavaScript. Ember.js оказал за последние несколько лет большее воздействие на JavaScript, нежели любой другой фреймворк. По нашему мнению это продолжится и в будущем, помогая развивать возможности и шаблоны JavaScript. Кроме того, это означает хорошую поддержку будущих стандартов в Ember.js.

Вряд ли Ember.js исчезнет в обозримом будущем, хотя инновации в его экосистеме, весьма вероятно, будут исходить от других проектов, связанных с ним, вроде Glimmer, который представляет собой фреймворк для построения пользовательских интерфейсов Ember.js-приложений, основанный на TypeScript.

▍Почему стоит выбрать Ember.js?

Если вы ищете зрелый, устоявшийся фреймворк, вы не ошибётесь, выбрав Ember.js. Кроме того, так как в основе Ember лежат простые и понятные механизмы и существует множество официальных и официально одобренных тренингов, из из-за того, что он основан на жёсткой конструкции, найти разработчиков, которые могут создавать Ember-приложения, вероятно, легче, чем в случае с другими фреймворками. Кроме того, вполне реально обучить большие команды тому, как разрабатывать такие приложения и обеспечить эффективное взаимодействие в таких командах.

Если вам хочется, чтобы ваша организация была уверена в том, что выбранные ей технологии всегда будут на современном уровне, и с осторожностью относитесь к возможным изменениям в платформах, тогда Ember тоже будет хорошим выбором. Вместо того, чтобы беспокоиться о том, что ранее выбранная платформа устареет или изменится до неузнаваемости, вы сможете просто заниматься разработкой своих приложений.

Aurelia

▍Сильные стороны

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

▍Слабые стороны и возможные сложности при внедрении

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

Большие объёмы работы над Aurelia выполняются единственным разработчиком, а значит, если он не сможет уделять проекту достаточно времени или решит что-то кардинально в нём изменить, те, кто выбрал данный фреймворк для долгосрочных проектов, могут столкнуться с проблемами.

▍Будущее фреймворка

У Aurelia есть множество возможностей. Если этот фреймворк останется верен положенным в его основу принципам, он сохранит шаблоны веб-разработки, отлаженные в Angular, но будет давать их в более стандартизированном и проработанном виде. Однако, мы не знаем, в этом ли направлении будет развиваться Aurelia.

▍Почему стоит выбрать Aurelia?

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

Итоги

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

Фреймворк - это всего лишь воплощение неких шаблонов, интегрированный набор каких-то технологий, и код, который облегчает разработку и поддержку веб-приложений. Если вы - самостоятельный разработчик, лучшее, что мы можем посоветовать - попробуйте как можно больше фреймворков, которые кажутся вам подходящими. Если вы - менеджер или архитектор, пытающийся принять решение, помните о том, что список возможностей фреймворка - это лишь одна из его характеристик, и иногда больше - не значит лучше. Задайтесь целью всеобъемлюще проанализировать фреймворк, привлеките команду разработчиков, но сначала составьте список того, что важно вам и вашей организации, в особенности - того, что выходит за пределы технических характеристик.
Dojo 2 Добавить метки