Самый популярные фреймворки в мире php. Веб-фреймворки: введение для новичков

Выбор слишком велик, а выделить правильный фреймворк стало довольно проблематично. Как и у множества других разработчиков, ваш взгляд может пасть на популярные, проверенные и надежные фреймворки Bootstrap и Foundation. Однако новые, но не такие известные фреймворки могут намного больше подходить под ваши нужды. В таких условиях вам просто необходимо разобраться в самых популярных фреймворках на сегодня.

На что нужно смотреть при выборе front-end фреймворка

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

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

Адаптивный дизайн – любой разрабатываемый вами сайт должен хорошо отображаться на всех устройствах, так как все больше людей заходят в интернет через мобильные устройства. Сайт Similar Web выпустил отчет состояние мобильного интернета в США за 2015 год , в котором говорится, что 56 процентов потребителей трафика ведущих сайтов в США заходят в интернет с мобильных устройств. Ищите front-end фреймворки с поддержкой адаптивного дизайна, тогда у вас будет на одну проблему меньше.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

CSS препроцессоры – если вы используете CSS препроцессоры, к примеру, Sass или LESS, проверьте, чтобы они были совместимы с фреймворком.

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

Прототипы – идеальный front-end фреймворк позволяет быстро создавать вайрфреймы и прототипы для ускорения процесса дизайна и разработки.

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

Без лишних слов представляю вам восьмой по популярности front-end фреймворк в 2016 году.

Bootstrap

ТОП был бы неполным без очень популярного front-end фреймворка Bootstrap . Авторами фреймворка являются создатели Twitter, которые выпустили его в 2011 году. Самый используемый open-source фреймворк в мире.

Как и в любой другой эффективный front-end фреймворк, в Bootstrap входят компоненты HTML, CSS и JS. Фреймворк придерживается стандартов адаптивного веб-дизайна, позволяя вам создавать адаптивные сайты любой сложности и размеров.

Постоянные обновления Bootstrap гарантируют, что вы получите самые новые и лучшие функции. К примеру, почти сразу в фреймворк были добавлены темы, отвечающие стандартам material design от Google. Темы были улучшены для поддержки Sass.

поддержка адаптивного веб-дизайна (можно отключить по желанию);

обширная документация.

редко используемые стили увеличивают вес стандартного фреймворка до 276 Кб;

слишком много HTML классов и DOM элементов, что загрязняет код и путает пользователя.

Подходит для новичков и тех, кто предпочитает надежные front-end фреймворки.

нет заблокированных стилей, что дает вам больше гибкости;

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

довольно большой вес файлов по умолчанию;

немного сложноват для новичков.

Подойдет разработчикам с приличным опытом, чья основная задача – быстрая разработка, привлекательные и адаптивные сайты.

Materialize

Фреймворк Pure создан командой разработчиков Yahoo. В комплекте идет легкий массив CSS модулей, которые подходят под любой проект. С Pure вы с легкость сможете создавать адаптивные кнопки, меню, сетки, таблицы и т.д. Фреймворк написан на чистом CSS и не поддерживает JS или JQuery плагины.

После минификации и сжатия через Gzip фреймворк Pure сжимается до 4.5Кб, что делает его одним из самых легких и проворных front-end фреймворков. Pure идеально подходит для мобильной разработки, из-за чего он приглянулся множеству разработчиков.

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

гибкий массив CSS модулей можно использовать в абсолютно любом дизайне и проекте.

написан на CSS без поддержки JS или JQuery плагинов.

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

Skeleton

Skeleton – легковесный адаптивный шаблон всего лишь из 400 строк кода. Фреймворк включает минимально необходимый функционал для старта разработки. В отличие от описанных выше фреймворков, это не комплексное решение.

Skeleton – адаптивный фреймворк, в основе которого лежит 12-ти колоночная сетка. В комплекте только необходимые элементы: кнопки, списки, таблицы, формы и т.д.

очень легкий;

простота и удобство для написания маленьких проектов.

отсутствие широкого выбора компонентов, в отличие от больших фреймворков.

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

UIKit

UIKit – высокомодульный front-end фреймворк, выделяющийся среди большинства по множеству причин. Главная причина – наличие двух препроцессоров, LESS и Sass.

Благодаря своим гибким и адаптивным компонентам с понятными именами, UIKit стал одним из самых популярных front-end фреймворков.

Еще большую универсальной фреймворку придают 30 модульных компонентов. Среди компонентов: меню, HTML формы и таблицы, JS компоненты, например, выезжающие вкладки и модальные окна, общие элементы, такие как кнопки, знаки и перекрывающие слои, а также компоненты макета, такие как жидкие, адаптивные системы сеток.

высокая кастомизация;

уникальная модульная структура, позволяющая добавлять компоненты к стилям, не оказывая влияния на общие стили;

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

фреймворк еще новый, в сети по нему очень мало ресурсов.

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

Milligram

Milligram – еще один легковесный фреймворк, похожий на Skeleton. После сжатия через Gzip размер файла достигает 2Кб, что обеспечивает разработчикам простой и удобный старт.

Система сеток в Milligram отличается от большинства, так как она использует стандарт CSS Flexible Box Layout Module. Также в комплекте есть пара ключевых компонентов, которые помогут вам начать работу, среди которых шрифты, кнопки, формы, списки, таблицы, цитаты и т.д.

очень легкий, всего 2Кб после сжатия через Gzip;

использует систему сеток Flexbox.

фреймворк довольно новый, про него очень мало информации;

минимальное количество компонентов стилей по сравнению с более крупными фреймворками.

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

Susy

Некоторые скажут, что Susy – не совсем front-end фреймворк, так как он решает сложные задачи по макетированию. По факту, множество людей расценивают Susy, как систему сеток, но она может стать незаменимым инструментом для людей, работающих с макетами.

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

Susy позволяет создавать сетки любой сложности. Если вы пытались решить проблему с созданием сложной системы сеток, вам поможет Susy.

повышенная гибкость позволяет создавать сетки любой сложности;

автоматические вычисления.

не покрывает все вопросы дизайна сайта, что потребует еще одного фреймворка;

нет встроенных сеток.

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

Статистика по front-end фреймворкам

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

Bootstrap: 101,433 звезд

Semantic-UI: 28,170 звезд

Foundation: 24,127 звезд

Materialize: 21,515 звезд

Material UI: 19,631 звезд

Pure: 14,967 звезд

Skeleton: 12,622 звезд

UIKit: 7,433 звезд

Milligram: 4,195 звезд

Susy: 3,506 звезд

Кроме того, в сравнении ТОП-5 front-end фреймворков на Google Trends видно, что Bootstrap все еще на голову опережает своих конкурентов по числу упоминаний.

Заключение

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

Перед выбором front-end фреймворка определите свой уровень знаний, а также базовые требования вашего проекта. Скорее всего, один или несколько продуктов из списка идеально подойдут вам.

Приветствую вас, мои постоянные читатели и случайные посетители сайт!

Сегодня наш разговор будет посвящён особенностям создания сайтов на фреймворке, а точнее, обзору плюсов и минусов frameworks как для разработчиков, так и для заказчиков.

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

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

Те, кто уже работал с фреймворками знают, каким образом это достигается.

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

Фреймворки, как и другие движки для сайтов, бывают самописными и официальными. О самописных фреймворках и своём отношении к ним я уже писал в отдельной статье по ссылке выше, поэтому не буду вдаваться в подробности.

Фреймворк, как вы могли убедиться, — это понятие универсальное, выходящее за рамки веб-программирования. У того же C++, оказывается, есть фреймворк – Juce. Однако, такого их количества, как в web, наверное, нет больше нигде.

Для одного только языка PHP их существует несколько десятков (всем известные Yii, Laravel, Symphony, CakePHP и др.). Также существуют фреймворки и для других языков, применяемых в web:

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

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

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

Учитывая огромное количество PHP frameworks и их распространённость среди разработчиков, в дальнейшем разговоре о преимуществах фреймворков и их недостатков как для заказчиков, так и программистов под данным термином будут подразумеваться продукты именно для PHP.

Поэтому, если вы увидите какие-то нестыковки приводимых аргументов с frameworks для других языков, не спешите раздражаться 🙂

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

5 плюсов и 3 минуса фреймворков для создания сайтов для разработчиков

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

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

1. Полная свобода творчества. Заключается в том, что создание веб-ресурса с помощью фреймворка – это написание его кода с нуля, а не пользование «тем, что дают», как в случае с CMS.

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

В CMS же, повторюсь, помимо указанных ограничений вы будете иметь дело с готовым кодом сайта, который бывает не всегда читабельным (сколько людей, столько и стилей кодирования)

2. Разработка заключается именно в написании нового функционала, а не в урезании имеющегося, как в случае с CMS.

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

В то же время вся эта масса дополнений создаёт дополнительную нагрузку на железо сервера и снижает производительность сайта, т.е. он попросту тормозит.

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

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

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

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

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

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

4. HighLoad-адаптация. Честно говоря, даже не знаю, есть ли такой термин или нет 🙂 Просто захотелось описать одним словом огромный плюс фреймворков, который заключается в их относительно лёгкой (по сравнению с CMS) настройке под HighLoad (т.е. высокие нагрузки).

Реализован он наличием или поддержкой (есть все необходимые адаптеры и настройки) HighLoad-технологий (Memcached, Redis, Gearman) из коробки.

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

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

CMS – это всё-таки уровень мелких веб-студий, которые зарабатывают себе на жизнь штамповкой типовых сайтов. Исключение, пожалуй, составляют 1С-Битрикс и , которых уважают и боятся разработчики, способные стать базой для многофункциональных HighLoad-ресурсов.

О преимуществах поговорили. Теперь самое время разобрать недостатки фреймворков для программистов . Сразу скажу, что их не так много, как достоинств.

По крайней мере, лично я их не нашёл так много, как плюсов frameworks.

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

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

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

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

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

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

3. Фреймворк – инструмент для профи, новичкам создать полноценный сайт с его использованием будет весьма сложно.

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

Так что решать вам 🙂

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

Я ощутил это на себе: когда пытался найти работу, то во всех компаниях, способных платить серьёзную з/п, интересовались моими знаниями именно фреймворков, а не CMS. Про CMS спрашивали, в основном, владельцы мелких веб-студий.

Поскольку на тот момент я не был знаком с frameworks, то я вообще не понимал в чём дело. Только потом, при анализе портфолио обоих классов работодателей я заметил, что серьёзные компании занимались либо развитием своих крупных HighLoad-проектов, либо брались за разработку исключительно больших и перспективных сторонних проектов.

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

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

Естественно, в веб-студиях больших денег мне не предлагали.

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

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

Так что на инвопрос «На чём быстрее создать сайт – на CMS или фреймворке?» очень сложно ответить, т.к. отключение лишних функций может по времени занять столько же, сколько разработать ресурс с нуля на framework.

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

Как-то так 🙂

Достоинства фреймворков и недостатки для заказчиков

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

В отличие от предыдущей точки зрения, заказчиком лично я не был. Зато я много с ними общался как при работе на фрилансе, так и через Project Manager-ов на постоянном месте работы.

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

Начнём традиционно с приятного, и поговорим о преимуществах PHP фреймворков для заказчиков .

1. С помощью фреймворка можно реализовать проект абсолютно любой сложности и с функционалом, каким только душа не пожелает.

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

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

На базе framework можно сделать абсолютно всё, что возможно реализовать с помощью кода (чтобы вы не подумали, что фреймворк – это ключ к решению всех мировых проблем). И точка!

2. Сайты на фрейморках более производительны, чем на CMS, т.к. в них присутствует только необходимый функционал.

Как уже и говорилось, фреймворки совсем не похожи на ЦМС, в которых по умолчанию напичкано множество функций и инструментов, порой совершенно не нужных.

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

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

3. HighLoad-адаптация, о которой я уже говорил, перечисляя особенности фреймворков для программистов.

Поскольку frameworks более гибки в HighLoad-настройке, чем те же CMS, то сделать сайт производительным при большой нагрузке в данном случае будет достаточно быстро и, следовательно, дешевле, чем «подпиливать» CMS или другие типы движков.

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

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

1. Разработка сайта занимает большое количество времени.

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

2. Следовательно, стоимость сайта, разработанного на базе фреймворка, будет больше аналогичного проекта, реализованного на CMS.

Хотя, правды ради, нужно сказать, что проект проекту рознь. Как уже говорилось, разработав Интернет-магазин на ЦМС вместо фреймворка, вы выиграете по времени, а, следовательно, и по деньгам.

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

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

Как уже говорилось, дополнительный функционал для frameworks в большинстве случаев реализован в виде пакетов.

Для того, чтобы установить в фреймворк пакет, для начала на хостинге нужно будет установить пакетный менеджер (Composer для PHP, Bower для JavaScript и CSS, npm для Node.js и т.д.), затем настроить его, научиться с ним работать, а только уже после всего этого найти и установить требуемый пакет.

Согласитесь, что данный способ расширения «слегка» усложняет работу с фрймворками простым смертным 🙂 И в данном моменте фреймворки существенно уступают CMS, где установка модулей и шаблонов занимает, от силы, 1 минуту.

4. Фреймворк – инструмент для профессионалов, следовательно, в тематических сообществах можете даже не пробовать создавать топики с названиями типа «Настройка корзины заказов» или «Как добавить новую категорию», которыми рябят форумы, посвящённые CMS.

В лучшем случае вам предоставят простыню кода, с которым придётся разбираться самостоятельно, или насоветуют кучу библиотек, с которыми вы не будете знать, что делать. В худшем — высмеют или вообще забанят 🙂

К чему эта куча букв? Да к тому, что самостоятельно добавить новую функцию на сайт, разработанный на базе фреймворка вам вряд ли удастся самостоятельно. Как выход из ситуации – придётся обращаться за помощью к профессиональным разработчикам, которые имеют опыт работы с требуемой платформой.

5. А услуги профессионалов — это, в свою очередь, — дополнительные расходы.

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

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

Или заказать разработку сайта «под ключ», т.к. фреймворк идеально подходит для этого.

Вот такие они, эти PHP frameworks. Где-то выигрываем, а где-то теряем. В общем, как и везде.

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

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

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

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

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

Думаю, не стоит говорить, что для проектов такого масштаба ребят с фриланса лучше не дёргать 🙂 Разве что для консультации по поводу стека технологий и стоимости.

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

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

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

Пишите свои отзывы в комментариях и делитесь статьёй со своими друзьями и единомышленниками в социальных сетях с помощью кнопок под статьёй.

Также не забывайте вступать в наше

Вышла серия статей , посвящённая фреймворкам для разработки веб-приложений. А именно, в этих материалах исследованы платформы 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 Добавить метки

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

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

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

Разработчики постоянно проводят сравнение фреймворков, чтобы прояснить для себя этот вопрос. Например, в статье 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, и уменьшенное количество используемой памяти.

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 не хватает гибкости и приходится ее ломать, чтобы реализовать задачу. Это же касается и фреймворков: при длительном развитии проекта не всегда хватает гибкости и приходится переходить на другое решение или переписывать ключевые его части.

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