Что такое фреймворк простыми словами

Сегодня слово «framework» стало обыденным в web dev’е. Как только jQuery и Prototype, Rails и Django получили широкое распространение, кажется, что теперь каждый использует какой-нибудь framework для создания своего сайта.
Но что же такое framework? Они полезны программистам, или даже веб дизайнеры могут воспользоваться их преимуществами.

Что такое “framework”?

Итак, давайте договоримся — хотя бы на протяжении этой статьи — считать, что “framework” — это набор инструментов, библиотек, хорошего кода, который поможет превратить рутинные задачи в модули, которые можно использовать неоднократно. Задача framework’а — позволить дизайнеру или разработчику сфокусироваться на задачах, являющимися уникальными в рамках данного проекта. Иначе говоря, не изобретать колесо раз за разом. Вобщем, это подход, выбранный вышеуказанными web и JavaScript framework’ами.

Framework для дизайнеров

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

В Lawrence Journal-World, где я работаю, мы недавно создали CSS framework и обнаружили, что он значительно увеличил нашу производительность. Конечно, для его создания потребовалось потратить несколько дней, но как только он был готов, скорость, с которой мы могли создавать качественные страницы, резко возросла. Более того, с тех пор, как мы начали использовать наш framework, каждый дизайнер мог что-то исправить в чужой работе, и им уже не требовалось 20 минут, что понять, почему что-то написано именно так. Они просто погружались в работу.

Что именно можно абстрагировать?

К тому же, многие сайты используют одни и те же виджеты, такие как drop-down меню, закладки в навигации, кнопки, и т.д. Эти вещи хорошо подходят для абстракции. Помимо этого, вы можете выработать некоторые свои идиомы, как скажем, список фотографий, показывающийся в виде thumbnail’ов. Вы можете стандартизировать CSS класс “thumbnail-list”, и в следующий раз вам всего лишь потребуется вставить этот класс, чтобы получить работающий вариант.

Это действительно принесет мне пользу?

Имея такой framework, вы сможете быстро окунуться в создание новой страницы. Вы создаете новый (X)HMTL документ, подключаете framework, и вам уже не потребуется времени, чтобы избавиться от ненужных отступов, у вас уже будет нужная вам типографика, чистые формы, работающие виджеты и много другое!
Вероятно, что вам захочется как-то изменить внешний вид конретного сайта. Чтобы это осуществить, все что вам нужно, это добавить или изменить уже существующий стиль. К примеру, если ваш framework устанвливает стандартную панель с навигацией для каждого «ul» с классом “tabs”, который имеет серый фон и черные границы. Чтобы это изменить, вам всего лишь потребуется добавить (или изменить существующий) стиль. Например:

Как должен быть спроектирован CSS framework?

Заключение

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

Опубликовано с разрешения A List Apart и Jeff Croft’a

Источник

Фреймворк

Фреймворк (с англ. framework — «каркас, структура») — заготовка, готовая модель в IT для быстрой разработки, на основе которой можно дописать собственный код. Он задает структуру, определяет правила и предоставляет необходимый набор инструментов для создания проекта. В основном фреймворки используются в веб-разработке.

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

Чтобы понять, что такое frameworks, можно представить строительство дома.

Первый вариант — использовать готовый типовой проект. В нем будут продуманы способы заливки фундамента, расположение коммуникаций, теплоизоляция стен. Но при этом нельзя изменить планировку, затрагивая несущие конструкции.

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

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

Зачем нужны фреймворки

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

Чем фреймворк отличается от библиотеки

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

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

Особенности веб-фреймворков

Универсальность

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

Эффективность и простота

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

Надежность

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

Безопасность

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

Адаптивность

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

Архитектура фреймворков

Чтобы поделить проект на логические части, модули, фреймворки зачастую используют архитектуру Model-View-Controller (MVC). Она подразумевает деление на три сегмента: модель, представление и контроллер. Можно изменять каждый независимо от других.

Какими бывают фреймворки в веб-разработке

По типу задач

Бэкенд-фреймворки

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

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

Django. Популярный и мощный веб-фреймворк на языке Python. Помогает масштабировать проект в процессе работы. Работает по принципу DRY (Don’t repeat yourself), отличается стандартной структурой и наследованием шаблонов.

Symfony. Один из самых старых PHP-фреймворков. Часто используется для разработки больших порталов благодаря стабильности. Гибкий и масштабируемый.

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

Фронтенд-фреймворки

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

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

Bootstrap. Это открытый и бесплатный CSS-, HTML- и JS-фреймворк. Позволяет создавать проекты с отзывчивым и стильным дизайном. К преимуществам относится большое количество шаблонов, стилей, постраничный дизайн, высокое качество адаптивной верстки, низкий порог вхождения.

Узнать больше о фреймворке можно в этой статье.

Фуллстек-фреймворки

Фреймворки решают задачи и на клиентской, и на серверной стороне.

Meteor. Обе стороны работают на JavaScript. Можно использовать для них одинаковый код. Работает в режиме реального времени: при изменениях в одном интерфейсе происходят изменения и в других.

Next.js. JavaScript-фреймворк, созданный поверх React.js. Разработан для решения проблемы React.js, которая связана с отрисовкой приложения на стороне сервера — SSR.

Nuxt. JavaScript-фреймворк, который разработан для создания универсальных приложений на Vue.js с помощью Node.js.

По размеру

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

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

Источник

Что такое фреймворки и как ими пользоваться?

Для чего нужен фреймворк?

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

Framework vs Библиотеки

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

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

Особенности веб-фреймворков

2. Открытый исходный код

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

3.Ограниченность в использовании

Плюсы работы с фреймворком

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

Универсальность (адаптивность)

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

Эффективность и простота

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

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

Надежность

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

Безопасность

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

Виды фреймворков

Классификация по типу задач

Бэкенд-Framework

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

Самые популярные на 2022 год: Express на платформе Node.js (JavaScript), Spring Boot (Java), Django (Python) и NET (C#) от Microsoft.

Фронтенд-Framework

Абсолютное большинство фронтенд продуктов создано на языке Javascript. Его понимают все платформы. Примеры фреймворков для фронтендеров: React, VueJS, jQuery, EmberJS, Angular и Svelte.

Пример “начинки” Angular на Javascript.

Фуллстек-Framework

Если фреймворк решает задачи и на серверной, и на клиентской стороне, то он относится к категории фуллстек. В качестве примера можно назвать Meteor. Он работает на JavaScript.

К фуллстек также относятся фреймворки Next.js (React.js) и Nuxt (Vue.js). Они не такие популярные, так как разработчиков, отлично разбирающихся как в бэке, так и в фронте, не так много.

Многие поймут вот этот код “Meteor”, но не многие смогут писать и серверную структуру, и внешний фронт.

Классификация по размеру

Например, если приложение основано на Django и вам нужен WebSocket (обмен сообщениями между браузером и веб-сервером в режиме реального времени), то вы можете воспользоваться micro framework aiohttp.

Источник

Веб-фреймворки для начинающих: простое объяснение с примерами

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

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.

Веб-фреймворк — это каркас для написания веб-приложений. Он определяет структуру, задаёт правила и предоставляет необходимый набор инструментов для разработки.

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

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

Бэкенд-фреймворки

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

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

Фронтенд-фреймворки

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

Все эти инструменты используют JavaScript.

Фуллстек-фреймворки

Если фреймворк решает задачи и на серверной, и на клиентской стороне, то он относится к категории фуллстек. В качестве примера можно назвать Meteor. Обе его стороны — серверная и клиентская — работают на JavaScript. Поэтому вы можете создавать и использовать для них один и тот же код. Следующая особенность — «режим реального времени». Когда вы что-то меняете в одном интерфейсе, изменения происходят и в остальных.

К фуллстек также относятся фреймворки Next.js и Nuxt. Первый создан поверх React.js, а второй работает на базе Vue.js. Такие веб-фреймворки могут быть сложными для начинающих.

Можно работать и с серверной, и с клиентской стороной веб-приложения

Фреймворки и микрофреймворки

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

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

Архитектура веб-фреймворков

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

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

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

Модель MVC используется во всех веб-фреймворках

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

Особенности веб-фреймворков

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

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

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

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

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

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

Приложения — фреймворки позволяют разрабатывать разные веб-приложения. Наиболее распространённые инструменты используются для создания блогов, форумов, универсальных веб-сайтов, систем управления контентом (CMS)

Как выбрать подходящий веб-фреймворк

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

Полезно также изучить сравнение нескольких фреймворков. Например, вот сопоставление возможностей Django и Ruby on Rails.

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

Как научиться пользоваться веб-фреймворками

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

Если в документации нет простых гайдов, можно поискать их на других площадках. Например, на freeCodeCamp есть бесплатный курс по React, а на сайте Tutorialspoint — туториалы по разным языкам и технологиям.

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

Источник

Знакомство с фреймворками. Часть 1. HTML/CSS, PHP и Python

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

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

Если обратиться к истории самого слова «фреймворк», то этот неологизм появился в языке относительно недавно, примерно в начале XXI века. С английского слово “framework” можно перевести как «конструкция», «структура», «каркас», «корпус» или «остов». Понимание перевода слова ведет к понимаю сути фреймворка: это специальная программная среда выполнения, программный каркас, который облегчает разработку программ и объединение компонентов, так как уже содержит в себе некую основу, не меняющуюся от конфигурации к конфигурации часть, которую следует лишь наполнить сменными моделями или точками расширения.
В отличие от динамической библиотеки (DLL), которая предоставляет собой лишь набор ограниченных функций, фреймворк является каркасом, согласно которому будет строиться архитектура приложения, то есть он определяет взаимосвязь между компонентами. Более того, фреймворк может содержать много разных по тематике библиотек.

При этом фреймворки можно поделить на следующие виды:

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

Сравнение чистого кода, фреймворка и CMS

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

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

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

Третий вариант – установка готовой CMS. Этот путь популярен у людей, далеких от веб-разработки, так как он позволяет легко и быстро создать свой собственный сайт, при этом все необходимые действия можно выполнять из административной панели. Но в то же время этот подход является самым несвободным по сравнению с предыдущими двумя и обладает массой ограничений.

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

HTML/CSS-фреймворки

Bootstrap (или Twitter Bootstrap) – один из самых известных и современных фреймворков, впервые анонсированный в 2011 году. Одно из главных свойств этого фреймворка – адаптивность. Используя Bootstrap, вы можете создать сайт с отзывчивым дизайном: ваш проект будет самостоятельно подстраиваться под размер экрана пользователя. Другие плюсы этого фреймворка: простота в использовании, наличие множества шаблонов и стилей, что значительно экономит время при разработке, согласующийся постраничный дизайн, открытое программное обеспечение. Bootstrap нельзя назвать только HTML/CSS-фреймворком, так как он включает в себя также готовые стили и плагины под jQuery (библиотека на JS).

Foundation – один из ведущих front-end-фреймворков на данный момент. В последних версиях авторы сделали упор на функционал для мобильных устройств. Семантический подход позволяет писать более чистый код на HTML и использовать SCSS. Этот фреймворк хорошо подходит для быстрого прототипирования.

Semantic UI – этот фреймворк, как и Bootstrap, поможет вам создать переносимые интерфейсы. Это достаточно молодой фреймворк, который постоянно развивается; он имеет множество различных кнопок, иконок, изображений, надписей и других элементов.

Uikit – фреймворк, обладающий легкой и модульной структурой. Выделяется на фоне остальных фреймворков двумя особенностями: во-первых, markdown (предварительный просмотр в реальном времени), во-вторых, синтаксическая подсветка для HTML.

Pure by Yahoo! – фреймворк, который содержит небольшие адаптивные CSS-модули, пригодные для использования в любом проекте. Как можно понять из названия, к этому фреймворку стоит обращаться тогда, когда вам нужно использовать некоторые возможности фреймворка, но в то же время вы не хотите использовать слишком тяжелый программный каркас.

PHP-фреймворки

Yii – фреймворк, название которого расшифровывается как “Yes, it is!”, существует уже более 8 лет и постоянно обновляется. У него широкие возможности: одна из самых высоких производительностей (по сравнению с другими фреймворками), кэширование, обработка ошибок, миграция баз данных, возможность использовать и объединяться с jQuery и многое другое. В отличие от других PHP-фреймворков, Yii можно изучить достаточно быстро, работа с ним стабильна и безопасна. Именно по этим причинам данный фреймворк часто советуют тем, кто только начинает свой путь в PHP-программировании.

Laravel – этот фреймворк часто лидирует в разнообразных опросах, касающихся PHP-фреймворков. Например, в 2013 году Laravel был назван самым многообещающим проектом 2014 года, а в 2015 году занял первые места в категориях «Фреймворк корпоративного уровня» и «Фреймворк для личных проектов». Laravel прост в освоении и отлично подходит для небольших и средних проектов, когда необходимо быстро и удобно написать код.

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

CodeIgniter – один из старейших фреймворков, первый публичный релиз которого состоялся в 2006 году. Этот фреймворк имеет массу преимуществ: быстрая установка, хорошая документация, малый вес; с ним вы можете легко реализовать задуманный проект. Именно поэтому некоторые начинают освоение фреймворков именно с CodeIgniter. Немаловажным фактом также являются регулярные релизы новых версий, в которых исправлены баги и добавлены новые возможности.

Phalcon PHP – написанный на языках программирования C, С++ и PHP фреймворк имеет открытый исходный код, а также предлагает разные версии для самых популярных операционных систем: Windows, Linux и Mac. Если взять во внимание тесты, то данный фреймворк является одним из самых производительных. Также Phalcon PHP можно использовать на собственных серверах.

Python-фреймворки

Django – это один из самых известных фреймворков в целом и, безусловно, самый популярный фреймворк на языке Python. Удивительно, но для того, чтобы начать использовать Django, вам даже не нужны глубокое знание языка Python. Отличительной особенностью Django является его принцип DRY, который расшифровывается как “Don’t repeat yourself”. Мысль, выраженная в этой фразе, ведет к тому, что разработчикам не следует повторять те строки кода, которые они уже использовали, и благодаря этому исходный код выглядит более лаконично и понятно. К преимуществам фреймворка можно также отнести стандартную структуру (благодаря которой даже сторонний программист сможет разобраться в коде) и наследование шаблонов. Многие знакомы с Django в качестве системы администрирования, однако эта CMS подойдет только опытным пользователям, знакомым с программированием.

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

TurboGears – известный Python-фреймворк с более чем 10-летней историей. Он предназначен для разработки веб-проектов и состоит из различных WSGI-компонентов, в том числе Pylons и CherryPy. Благодаря этому можно говорить о TurboGears как о мощном фреймворке с богатым функционалом. Он поддерживает множество баз данных и форматов обмена данными, также поддерживает различные JavaScript-библиотеки и горизонтальное масштабирование данных.

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

Web2spy – этот фреймворк, как и некоторые другие, основывается на концепции RAD (rapid application development). Иными словами, при его разработке особое внимание было уделено оптимизации процесса создания проекта, чтобы программист мог как можно быстрее создать хороший продукт. Фреймворк имеет открытый исходный код и помогает создавать динамические сайты при помощи языка Python. Это полнофункциональный фреймворк, который содержит компоненты для всех основных функций.

Во второй части будут рассмотрены фреймворки следующих языков программирования: Ruby, Java, JavaScript.

Источник

Framework — это что? Простым языком о том, что такое фрейморк

Написали статью для новичков, чтобы рассказать, что это такое и какие виды framework-ов бывают.

Framework — это что?

Из этой статьи о framework вы узнаете:

Framework это что?

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

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

Framework — это тот самый план постройки продукта для разработчиков.

Разница между CMS, фреймворками и написание кода с нуля

Разбираем на примере фронтенд-разработки. Предположим, вам нужно создать сайт. Есть 3 подхода, которые можно использовать: написать код с нуля, использовать framework или использовать CMS.

Что такое framework?

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

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

Плюсы использования framework

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

Популярные фронтенд фреймворки это

React.js — это framework на JavaScript. Его создал Facebook 7 лет назад, в 2013 году. Framework React.js обычно применяют чтобы проектировать интерфейсы, которыми будет пользоваться конечный клиент.

Хотите быстро и легко понять, как работает framework React.js? Запишитесь на консультацию к ментору!

Angular — framework для веб-разработчиков, который разработали в компании Google. Этот фреймворк обычно используют для создания динамических приложений. Он удобный благодаря открытому исходному коду и большому количеству внутренних возможностей.

Vue.js — framework, который разработал и выпустил в 2014 году сотрудник Google Эван Ю. У него также исходный открытый код и 89% разработчиков, который использует его, довольны.

JQuery — один из самых ранних framework. Он появился в далеком 2006 году. Этот framework неплохо подходит для создания небольших проектов, в которых не используется большое количество дополнительных элементов JavaScipt.

Антон Волков, CTO в Solvery:

React.js проще, быстрее и гибче конкурентов, потому что из коробки в нем меньше функционала. Это один из самых популярных фреймворков по фронтенду. Также популярен Angular. Он не такой гибкий, как React, и тяжелее его. Но в нем из коробки зашито больше функций, поэтому на Angular быстрее сделать готовый продукт. Соответственно, если вы не хотите думать о структуре и архитектуре проекта, то логичнее использовать Angular. К тому же, у него есть официальные подробные и качественный гайдлайны. А если важна гибкость, скорость загрузки и возможность вносить максимум изменений — выбирайте React.

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

Популярные бэкэнд framework

Laravel — один из самых популярных бэкенд framework для языка программирования PHP. Его выпустил американский разработчик Тэйлор Отвел в 2011 году. Framework регулярно обновляется. У него открытый исходный код. И много удобных инструментов для решения стандартизированных задач.

Хотите быстро и легко понять, как работает framework Laravel? Запишитесь на консультацию к ментору-специалисту, который объяснит вам все детали работы framework!

Flask — молодой framework от австрийского разработчика Армина Ронахера. Flask часто относят к категории микрофреймворков. Это значит, что в нем присутствуют только самые базовые конструкции.

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

Популярные мобильные framework

Flutter — самый популярный мобильный framework для Android от создателя самого Android — компании Google.

Станьте специалистом по Flutter и напишите свое первое приложение для Android с помощью ментора!

Ionic — один из самых популярных Android framework с открытым исходным кодом. Его структура похожа на структуру фронтенд framework-ов. Ionic может работать совместно с Angular и React.

AFNetworking или Alamofire — фреймворки Objective-C и Swift, соответственно. Они помогают упростить работу мобильных приложений на IOS с сетью.

Популярные Python фреймворки

Django — этот framework был выпущен в далеком 2005 году. Он заточен под быструю и эффективную разработку. Очень практичный фреймворк.

Pyramid — фреймворк Pyramid представили в 2010 году.

Источник

Что такое фреймворк и как выбрать фреймворк для фронтенда: советы бывалых

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

Иллюстрация: Simon Lee / Unsplash / Bhalej / Walcker / Cleanpng / Adrian Ciurea / Turbosquid / Themes.getbootstrap / Meery Mary для Skillbox Media

Фреймворк — это программная платформа, которая упрощает разработку программного продукта, определяет структуру проекта и помогает удобно объединять в нём разные компоненты.

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

Что такое фреймворки и чем они отличаются от библиотек и паттернов проектирования

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

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

Фреймворки иногда путают с библиотеками и паттернами проектирования. Но разница между ними существенна.

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

А фреймворки накладывают достаточно жёсткие рамки на правила проектирования программы. К тому же внутри фреймворка может быть много разных библиотек. Примеры библиотек: jQuery и React (да-да, это именно библиотека).

Паттерн проектирования — это просто абстракция, схема, метод решения проблемы, который помогает правильно выстроить программный продукт. Нередко в основе фреймворков лежит какой-то паттерн проектирования — например, Django, Laravel и Ruby on Rails реализуют модель MVC (Model-View-Controller).

MVC помогает разделить логику приложения на три независимых части:

Сергей Черненко

Magento Tech Lead Front-End at Overdose

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

Примеры веб-фреймворков (для фронтенда и бэкенда):

Виктор Карпов

разработчик из Amazon, живёт в Эдинбурге, Великобритания. Автор Telegram-канала Coding interviews

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

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

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

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

Фреймворк решает типовые задачи и не знает о бизнес-области, в которой применяется: React, Angular, Vue.js — то, что поможет организовать роутинг (где-то как часть оригинального фреймворка, а где-то — как стороннее решение поверх, но не так важно), разделение моделей (данных) и вьюшек (шаблоны), перерисовку частей интерфейса при изменении данных.

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

Классика и новичок Svelte

Виталий Матвиевич

Исторически сложилось, что мой родной фреймворк — Vue.js. Легковесный, простой, подробно документированный, со множеством коробочных решений — отлично подходит для стартапов, любых MVP, с крупными проектами тоже справится отлично при умелом обращении.

С выпуском третьей версии пришло много улучшений, но были и проблемы: для SSR-проектов удобно использовать Nuxt, но Nuxt 3 пока слишком далёк от production-ready-состояния — и неясно, когда он там окажется. Так что либо живёшь с Nuxt на Vue.js 2, либо решаешь задачи с SSR без Nuxt.

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

В «МойОфис» я сейчас работаю на React — этот фреймворк как будто чуть более требователен к уровню разработчика, документирован чуть хуже, зато у него очень большое и активное сообщество. А ещё он отлично подходит для монструозных долгостроев, нет проблем с масштабированием, он упоминается в большом количестве вакансий и используется многими разработчиками — что хорошо и для бизнеса, и для соискателей вроде бы. С другой стороны, из-за обилия вакансий искать разработчиков и масштабировать команду не сильно проще, чем в случае с Vue.js.

С технической точки зрения в React.js мне не очень нравится уход в функциональные компоненты, но в остальном это мощный, контролируемый, популярный инструмент. Ну и круто, что есть React Native, а значит, можно в родном стеке собрать мобильное приложение приемлемого качества (у Vue.js есть Vue Native, но на деле это просто надстройка над React Native, что меня в итоге не впечатлило).

Из новых фреймворков я бы обратил внимание на Svelte, который, по сути, является компилятором: ни виртуального DOM, ни фреймворка в рантайме — интересный сдвиг парадигмы. Близко ещё его не смотрел, вакансий не видел, но, насколько успел понять, Ozon уже мигрирует на Svelte с Vue.js. Так что технология явно заслуживает внимания.

Выбор фреймворка в аутсорс‑разработке

Илья Башилов

руководитель фронтенд-направления глобальной IT-компании SimbirSoft

SimbirSoft — сервисная компания, поэтому на практике у нас всегда есть три варианта развития событий.

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

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

3. Заказчик просит нас провести анализ и понять, на каком фреймворке лучше сделать IT-продукт. В большинстве случаев это React, поскольку в будущем окажется проще найти разработчиков для поддержки проекта, а сама разработка получится менее затратной в сравнении, например, с Angular.

Есть несколько критериев выбора фреймворка/библиотеки: масштабность проекта, прозрачность и понимание функциональных возможностей, которые нужно реализовать, наличие специалистов на рынке и уровень их экспертности.

Для enterprise-проектов с большой долей вероятности подойдёт Angular. Если будущая бизнес-логика ещё не до конца известна, лучше обратить внимание на React.

Мы в SimbirSoft ведём несколько проектов, которые по масштабности не уступают крупным проектам на Angular, но пишутся на React, так как заказчик сразу обозначил, что требования могут изменяться в процессе и необходима гибкость в разработке. А поскольку React — это всё же библиотека, а не фреймворк, он эту гибкость предоставляет.

Для MVP хорошо подойдёт Vue.js. Но если нет свободных специалистов, React тоже прекрасно справится с этой задачей.

Мы уверены, что в ближайшее время React, Vue.js и Angular останутся актуальными. На наш взгляд, уделять время изучению устаревших фреймворков, например jQuery и AngularJS (не путайте с Angular), нужно только в особых случаях — скажем, если вы работаете с легаси-проектом, на котором были использованы эти технологии.

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

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

React, Solid, Vue.js, Web Components и Svelte

Иван Плесских

фронтенд-разработчик и преподаватель

Расскажу о разнице между React, Solid, Vue.js, Web Components и Svelte. Важное замечание: все они поддерживают TypeScript.

React

React — не совсем фреймворк, его принято относить к библиотекам.

Vue.js

Далее идут уже менее распространённые библиотеки.

Solid

Solid — это React плюс MobX минус Virtual DOM.

Библиотека с очень интересной концепцией — полностью построена на реактивности, как и Vue.js, при этом работает без Virtual DOM, но с JSX. Сложнее React, зато одна из самых быстрых — потому что работает напрямую с DOM, изменяя только необходимые её части, которые выявляются в момент компиляции JSX и отслеживаются с помощью реактивности. Сообщество пока крайне маленькое, но сама идея очень примечательна и может перерасти во что-то большее. Поддерживает все фичи React.

Svelte

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

Web Components

Это фреймворк от GitHub. Можно писать и на чистом JS или TS, используя веб-компоненты, — таким путём идёт сам GitHub. Сильная инкапсуляция компонентов через Shadow DOM (что влечёт и свои проблемы — например, глобальные стили придётся подключать в каждом компоненте) и максимальная нативность.

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

Выбор фреймворка по сообществу

Виктор Карпов

разработчик из Amazon, живёт в Эдинбурге, Великобритания. Автор Telegram-канала Coding interviews

Каждый из фреймворков для фронтенда имеет свои особенности, хоть и решает одну задачу, у каждого есть свои плюсы и минусы. Однако нельзя сказать, что условный React лучше Angular (или наоборот), — потому что конкуренция заставляет их расти и развиваться.

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

Фреймворки против CMS

Александр Шулепов

Расскажу о своём опыте. Мы с командой пилим проект, посвящённый подбору тренеров по большому теннису, — 40-30.ru. Пока успели доделать анкеты, форму регистрации и чаты между клиентами и заказчиками.

Вообще, мы нередко делаем сайты на CMS — например, том же WordPress. И по сравнению с разработкой на CMS фреймворки — это дорого и долго.

Однако у CMS, хотя они тоже в каком-то смысле являются фреймворками, есть ограничения — на них сложно собирать кастомные решения, многое упирается в стандартные функции. Например, всё очень непросто с разработкой личных кабинетов: если вам нужны ЛК с кучей сценариев, CMS такой проект вытянуть не смогут. А с фреймворком мы можем сделать то, что захотим, — и тут нас ограничит только наша фантазия и знания.

Изначально я планировал собирать проект на Laravel. Хороший PHP-фреймворк — даже некая экосистема. Но я не стал рисковать, поскольку проект у нас планируется серьёзный: как Profi.ru, только с фокусом на большом теннисе. Ещё мне все советовали React, объясняя, что на нём, в принципе, сейчас и делают все сложные проекты.

Однако я пообщался с разработчиком, и в итоге мы выбрали Angular — фреймворк, разработанный Google. На моё решение повлияли два момента:

Количество вакансий на разных фреймворках в СНГ и на Западе

Константин Бирюков

Frontend Developer в LightBox. Увлекается игровой индустрией, любит путешествия, Vue.js и картографические JavaScript-библиотеки

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

Три самых важных и популярных в последние несколько лет фреймворка: React, Vue.js и Angular. Каждый из них имеет свои особенности, но в целом все они справляются со своей главной задачей на отлично. Безусловно, существуют и другие фронтенд-фреймворки, но я предположу, что более 95% проектов и вакансий содержат требования именно по этим мастодонтам.

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

Количество вакансий. Если мы заглянем на один из самых популярных сайтов по поиску работы в РФ, hh.ru, и выберем Россию, то на 29 марта 2022 года увидим 4463 упоминания React в вакансиях, 2157 упоминаний Vue.js, 1883 упоминания Angular. Этот топ-3 прекрасно отражает популярность фреймворков в России на текущий момент.

Времена величия и популярности Angular в странах СНГ постепенно уходят, хотя он и занял свою нишу — большие и серьёзные финтех-проекты. Поэтому зачастую немалая часть Angular-проектов — это поддержка легаси-кода, хотя, конечно же, и новые проекты иногда решают делать на Angular. Этот фреймворк также горячо любим многими разработчиками, имеет свой особый путь и философию и очень контрастирует с React и Vue.js.

Порог входа. Angular достаточно «тяжеловесный» во всех смыслах этого слова — плюс у него довольно высокий порог входа. Для контраста: Vue.js можно освоить за один день на уровне, достаточном для написания простенького проекта, — и даже начать выполнять простые задачи на более крупном проекте. React по сложности занимает промежуточное положение между Angular и Vue.js.

Производительность. С точки зрения производительности React и Vue.js одинаково хороши, а Angular немного отстаёт.

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

Популярность на Западе. Уместно будет сравнение российского рынка с западным, в частности с США. Я, как Vue-разработчик, столкнулся с тем, что на Vue.js работу в США найти крайне сложно и большинство вакансий с требованием Vue.js в США — это работа в очень маленьких стартапах (менее пяти человек) с отсутствием адекватного финансирования.

Я пользовался множеством ресурсов для поиска работы в США, но, как правило, самым действенным всегда был LinkedIn. Если мы заглянем в LinkedIn и выберем United States, то на 29 марта 2022 года увидим 142 565 упоминаний React, 77 556 упоминаний Angular и всего лишь 17 294 упоминания Vue.js. React лидирует с большим отрывом, а Vue.js с таким же большим отрывом отстаёт.

Примечание: числа с LinkedIn и hh.ru — не количество вакансий, а количество упоминаний технологии в вакансиях. Например, можно встретить Angular, React и Vue.js в одной вакансии — порой работодателю достаточно, чтобы вы знали хотя бы один из фреймворков, если вы готовы освоить нужный уже в процессе работы. Тем не менее на больших цифрах статистика упоминаний показывает вполне достоверный результат.

В итоге я прошёл несколько десятков собеседований и убедился на практике: всем нужен React — от крупных корпораций до небольших стартапов. При этом популярность React в США только растёт. Такая же тенденция прослеживается и в странах СНГ, хотя тут серьёзно растёт и популярность Vue.js.

Свои личные проекты я стараюсь делать на Vue.js — он прост, комфортен для разработки, субъективно привычен, имеет эталонную документацию и замечательное комьюнити. Однако на работе я использую React. В результате получается своего рода круговорот: чем больше компаний предлагают работу на React, тем больше разработчиков станут его учить. И чем больше разработчиков будут знать React, тем больше компаний будут начинать или даже переписывать проекты на React.

Также я заметил, что в США даже многие крупные проекты написаны на «ванильном» JS (+ jQuery), а компании нанимают сотрудников, чтобы переписать их на один из фреймворков. И какой фреймворк они обычно выбирают? Правильно, React. Поскольку на React можно найти больше квалифицированных разработчиков. В результате имеем то, что имеем: React в США стал практически стандартом индустрии. Несмотря на огромную любовь к Vue.js, изучить React пришлось и мне 🙂

Как мы на Svelte кассы в X5 писали

Антон Крылов

руководитель группы разработки интерфейсов складов «Яндекс.Маркета»

Дело было так: сначала кассы писались на React и всё шло хорошо. Но в какой-то момент мы поняли, что не дотягиваем по перформансу — нужно было оптимизировать добавление товара в корзину до 200 мс. Мы исследовали разные способы оптимизации, но всё было тщетно.

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

Сравнивали по следующим показателям:

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

Ну, и обобщённый совет: фреймворк — лишь инструмент, под каждый проект можно выбирать свой на основе того, что нужно для выполнения требований, что удобно для вас как для команды и что нравится конкретно вам. Хотя, конечно, можно писать всё на React (но лучше так не делать).

Источник

О фреймворках

В сегодняшней статье поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.

Роман Ивлиев на примере множества проектов портала banki.ru, а также заказной разработки в студии крупных проектов Онтико. Рассмотрим следующие темы и поищем ответы на вопросы:

О фреймворках

Роман Ивлиев (Банки.ру)

Я очень давно ковыряюсь в IT и прошел путь от инженера до директора за 10 с лишним лет.

Про что мне с вами сегодня хотелось поговорить?

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

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

Перед тем как пробовать у себя то, о чем я вам сейчас наговорю, лучше сначала попробуйте у соседа, потому что, естественно, лучше пусть у него потом что-то болит, чем у вас.

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

Вот картинка. Кто узнал себя? Кто-то еще и чем-то самодельным пользуется — есть конторы, которые сами чего-то наделали крутого. И я признаюсь — в каждой из контор, в которых я работал, был свой фреймворк. Причем, в Банки.ру у нас есть фреймворк, который построен на базе Битрикса. Поэтому про боль я могу говорить долго. У нас есть Битрикс образца 2008-го года, который прекрасно выполняет свои задачи, в нем очень мало осталось от Битрикса, кроме имен, классов и кучи булшита, который туда напихали за долгие годы. Но тем не менее.

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

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

Это, наверное, топ-4, почему их пишут:

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

Есть еще пара моментов, почему это делают. Например, потому что «тот, что есть, он плохой». Это на моей практике такой решительный аргумент. Говоришь: «Ппочему ты взял фреймворк А, а не Б?» — «Б — плохой». «Почему?» — «Потому что». Про это тоже чуть позже поговорим.

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

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

Плюсы и минусы. Казалось бы, решений вагон. Давайте будем искать.

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

Посмотрим, какие плюсы, исходя из того, для чего их пишут.

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

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

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

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

Подразумевается, наверное, что люди, которые выкладывают фреймворки (не абы какие, а вот те, которые были на картинке в начале прещзентации) — профессионалы. На той картинке были собраны одни из самых популярных фреймворков на PHP, Python, Java и JavaScript. Вещи, которые разрабатываются почти промышленно, подразумевают, что разрабатывают их профессионалы, поэтому, когда вы это решение берете в руки, вы в целом можете быть уверены, что с вероятностью почти 100% то, что там написано, оно работает.

Минусы. Что такое фреймворк? Это груда чужого кода, которая иногда документирована, иногда не очень документирована, иногда документирована не совсем корректно. И самое главное, что не всегда понятно, как это работает. Т.е. если вы берете большой толстый фреймворк, разобраться в том, как реально в нем что-то происходит, достаточно сложно. Поэтому в ситуации, когда вы упираетесь в тормоза (как любят говорить «что-то тормозит»), то чтобы понять, что тормозит внутри вот этой коробки, нужно приложить определенные усилия. Даже если вы поймете, что в этой коробке работает не так, переписать эту коробку — это тоже определенные усилия. Потому что каждый фреймворк накладывает на разработчика некий стиль программирования. Можно взять очень крутой фреймворк, и программировать на нем настолько бездарно, что результаты вашего творчества перечеркнут все, что было заложено этими замечательными людьми-профессионалами, все их идеи.

Еще минус — надо переучиваться. Даже если вы берете фреймворки в рамках одного и того же языка программирования, то они на самом деле очень сильно друг от друга отличаются. Если взять на PHP какой-нибудь Symfony, как они внутри устроены, как нужно ими пользоваться — это совершенно разные диалоги. Когда, например, в объявлении о работе пишут, что «нам нужен программист на таком-то фреймворке» — это специально пишут. Потому что, если вы пишете на другом фреймворке, то у вас уже деформированное сознание, скорее всего. У людей, в принципе, деформируется сознание, когда они долго работают с одним и тем же. Если вы, например, долго-долго программировали на Ассемблере и умеете в голове переворачивать систему исчисления из троичной в 25-тиричную, то вряд ли вы что-то простое после этого сможете сделать. Вы уже обречены делать сложное. То же самое с фреймворком — есть очень простые, очень легкие каркасные решения, которые вот так вот, на раз-два программируются, а есть реально штуки, которые даже специалистам очень сложно заставить работать нормально.

Таким образом, вы попадаете на некий крючок, связанный со всеми предыдущими минусами. Т.е. если вы в своей компании разрабатываете огромное количество чего-то, используя один из фреймворков, то шансов перейти на другой у вас практически нет. Либо у вас очень добрый бизнес, или вы стартап, который готов жертвовать ночами, 25-ый час и т.д. Потому что по-разному все. Во многих языках, даже в той же самой Java, заложена разная идеология — там разные способы обработки данных, по-разному все это подходит. В итоге, вы становитесь заложником. По сути, так же, как с языком — если вы начали писать на PHP, то вы и будете дальше писать на PHP. Либо у вас есть сервисно-ориентированная архитектура, и суть в том же самом — вы можете брать кусками и переписывать. Пожалуйста, она вас спасет. Все остальное не спасет.

Есть мифы. Связанные с тем, что в первую очередь, человеку свойственно верить в доброе и вечное. Мало кто начнет утверждать, что «Все тлен, PHP — тлен, Perl — тлен, Go — тлен, все тлен. Common Lisp — наше все! Напишем на Common Lisp свой язык, на своем языке напишем свой фреймворк, и будем пилить на нем весело и задорно, зато все будет как «я хочу», и все другие будут просто восхищаться». Тем не менее, есть частые мифы и это из жизни, на самом деле. Это те штуки, с которыми реально пришлось столкнуться лбами. Т.е. казалось бы, разрабатывают профессионалы…

Миф 1-ый — безопасность. Даже несмотря на то, что фреймворки разрабатываются профессионалами, несмотря на то, что некоторыми из них пользуются миллионы людей, тем не менее, это открытый код. Безопасность — это бич открытого софта, потому что вы официально анонсируете патчи по безопасности, иначе как про них народ узнает? Вы берете и пишете на сайте: «Вот, мы тут нашли дырку… Пожалуйста, кто не успел защититься, кто не успел обновиться, тот попал». Разработчиков сторонних — вагон, вы можете схватить чужое решение, с какого-нибудь плохого GitHub’а, на котором лежит плохой код (наверняка такой где-нибудь есть). В принципе, из-за этого изобилия вы можете спокойно попасть в ситуацию, когда вы совершенно целенаправленно своими собственными руками в свой собственный код впихиваете чей-нибудь експлойт… Безопасность — вещь важная. Многие из вас тестируют безопасность своих приложений?

Классный миф про инженеров. Все считают, что если у нас все стандартизованно (все же пишут на работе стандарт, регламент), то мы легко заменим инженера. Это же классно — полный рынок инженеров на Haskell, например. Полно инженеров. Открываете HeadHunter — просто толпы инженеров на Haskell мечтают поработать в вашей компании. Это классно работает при условии, что вы только-только начали. У меня 35 инженеров, и у нас есть стандарты на разработку, еще у нас популярный фреймворк, и проект у меня уже давно начат, ему 11 лет, и я хочу сказать, что время входа человека в команду без ментора, старшего, который просто так сидит и говорит, что делать, ну, месяц. С ментором — 2 недели. И плюс еще ищешь черти сколько, потому что у меня есть то, что принято называть зоопарком. Мы пишем на PHP, у меня есть Битрикс, Symfony, двух версий каждая из того, что я назвал до этого, и еще на фронте у меня есть такой же список – штук семь, я даже сейчас все и не вспомню. Тем не менее, даже если это все хорошо работает, фиг вы быстро найдете инженера. Потому что каждым инструментом можно пользоваться так, как тебе хочется — инженер А, который программирует на каком-то Java фреймворке на Spring’е, пишет вот так, инженер Б — пишет вот так. И когда эти два парня встречаются, первое, что начинает говорить второй парень: «Нет, ну так нельзя делать, давай, я сейчас все перепишу по-быстренькому», тем самым он вышибает третьего парня, который, вообще, только пришел, он молодой. Он смотрит-смотрит на этих двух людей, и говорит: «Блин, да все же работало?».

Из этого вывод: без сноровки — овнокод, и с ним, в принципе, по большому счету сделать ничего нельзя.

Все говорят о скорости разработки: «Сейчас мы быстренько возьмем фреймворк, фреймворк классный, фреймворк быстро работает, мы по-быстренькому прикрутим, завертим, и все у нас быстренько пойдет». На самом деле все это хорошо работает при условии, что вам нужно типовое решение. Если вам нужно не типовое решение, фиг вы найдете подходящий фреймворк. Например, если вам нужно тупо отправлять файлики и что-то там делать — это хорошо, а если у вас на пути встает какое-нибудь устройство, которое перестает адекватно реагировать на http, и записывать нужно уже не в одно, а в 121 место, вам все равно придется писать все самим. И тогда вы попадаете в известную историю, когда у вас есть то, что работает, вы говорите, что это работает плохо, потому что предыдущий фреймворк плохой, постепенно на базе этого фреймворка, вы начинаете строить свой.

На самом деле, я везде немного утрирую, естественно, потому что не так все плохо, фреймворками пользуются и пишут, но боль, определенно, есть. И на самом деле все это классно, когда у вас есть специалисты. Группа лиц, собранных в одном месте, работающих над одной задачей, взявших инструмент, но не умеющих им пользоваться, все равно быстро ничего сделать не смогут. Даже если они все очень круто пишут на PHP, например, или на Phyton, или на Java, или на любом замечательном языке. Если они не очень сильно разбираются в этом фреймворке, быстро у них не получится. Более того, понять, что ты разрабатываешь хорошо на том инструменте, которым ты пользуешься, можно только спустя какое-то время. Либо если у тебя уже есть какой-то специалист по этим вопросам — сходил к нему в гости. Поэтому есть комьюнити (чуть дальше про них будем говорить), и оно реально спасает.

Есть еще мода. Мода — это страшная вещь, которая касается не только фреймворков, но и IT в целом. Приходит человек к знакомому IT’шнику и говорит: «Слышишь, чего там сейчас на рынке, вообще, круто?» — «На рынке круто — вот это». Он говорит: «О! Хочу вот это». Занавес. Слезы, плач, печаль и т.д.

По большому счету чуваку нужно, чтобы это все реально работало, ему больше ничего не нужно. Ему нужно, чтобы это было простое решение.

Еще есть куча несвязанных вещей, которые я выделил:

Фреймворк, естественно, плохой, потому что он что-то не может из коробки. Ну, потому что вряд ли вы найдете комбайн. Кто-нибудь читал на Хабре шикарную статью про фабрику фабрик для изготовления универсальных молотков? Вот здесь примерно то же самое. Естественно, человечество хочет сделать что-то универсальное, потом оно понимает, что что-то универсальное никому не нужно. Оно начинает делать механизм для построения чего-то универсального, потом механизм для построения построения и т.д. Это замкнутый круг.

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

Естественно, что-то не получается. Вот именно вот «так» нельзя сделать. Это вечный холивар, когда говорят: «А вот здесь нужен active directory, а он вот так вот не через activ, а через прямые SQL-запросы, вот так вот все круто, память экономят, все здорово…». Да фигня все это. Все делают одно и то же. Плюс-минус. Есть решения специализированные, есть решения вендоровские, которые заточены под какие-то конкретные решения.

И последний пункт, это реально боль.

Я вам как менеджер говорю. Это самая большая проблема, когда у вас есть сильный инженер, который давно сидит, он уже умеет очень сильно на этом всем программировать и в конечном итоге: «Все, что вы мне предлагаете, это все фигня». И объяснить ему, почему, например, его фреймворк, не его фреймворк и т.д. — это достаточно сложно, потому что реальных критериев отбора очень много, сейчас мы по ним пробежимся.

Как это все выбирать? Конкретных рецептов нет, потому что, естественно, задач бешеное количество. Тем не менее, на что имеет смысл обращать внимание.

Как давно на рынке — это важная вещь. Вы слышали, что такое хайп? Про агрессивную рекламу. Т.е. если в Google внезапно в первых строчках вылезает какое-то решение, которое на рынке не проболталось еще и года, у которого сайт сделан в виде этих продающих сайтов, которые скролишь-скролишь-скролишь — «скачать». Эти длинные. Скорее всего, это тоже какая-то фигня. Либо это кто-то из Javascript-чуваков слепил какой-то новый супер-пупер модный фреймворк, который решает все проблемы предыдущих супер-пупер модных фреймворков, которые он же написал в предыдущей конторе, когда работал. Либо это какая-то фигня.

Ваш опыт — очень важно. Если вы до этого ничего не программировали сложного, то если вы возьметесь за вот этот дрын, которым можно и копать, и гвозди забивать, и все, то, скорее всего, вы обречены на провал.

И время. Насколько вы готовы во всем этом поковыряться. Потому что, я за другие языки не скажу, но в PHP, например, есть четкая градация фреймворков (плюс-минус) по скорости ввода человека в суть процесса. И есть такой Макаров Саша, один из разработчиков Yii, который утверждает, что у Yii вход прям чуть ли не в разы быстрее, например, чем в Symfony войти. Эта штука тоже важна, потому что вам нужно врубаться, либо вам нужно уже сейчас взять и бежать-копать.
Про «бежать и копать» есть совершенно классная штука, например, если вам очень-очень быстро-быстро нужен интернет-магазин, то его можно очень-очень быстро-быстро купить готовый. И не надо, вообще, его писать. И за время, пока вы будете его раскручивать, вы напишете свой. Тем не менее, если у вас нет времени на изучение, зачем за это, вообще, браться, зачем?

Процесс разработки. Сколько лет, вообще, планируется эту штуку поддерживать? У каждого фреймворка, вообще, у любого open source софта есть как в DNS time to live, что называется, т.е. время, которое эту штуку потенциально готовы поддерживать. Кто-то анонсирует это, кто-то не анонсирует, кто-то показывает, кто-то не показывает. Где-то есть прям четкий, как у взрослых, time line, когда «30 декабря 2016-го года выпустим вот это, потом вот это и вот это». Это признак того, что продукт качественный. Если чуваки просто пилят и ничего не говорят, то, скорее всего, этот продукт не очень качественный. Но если мы возьмем топ 5-10, они все плюс-минус одинаково анонсируются, другой вопрос, что за сроками этими никто не следит.

Автоматизация, документация, стилевые библиотеки, т.е. например, где-то прикручена поддержка Bootstrap’а из коробки, где-то поддержка Bootstrap’а из коробки не прикручена. Если вам нужно что-то сделать быстро и «на коленке», то, конечно, будет прикольнее взять то, что у вас с поддержкой Bootstrap’а, потому что она тоже уже есть, не надо будет мудохаться.

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

По большому счету, их навалом, и есть даже целые хранилища этих навалов, где можно посмотреть, там даже есть рейтинги — можно в GitHub’е посчитать звездочки. Это то, что нужно обязательно учитывать в процессе выбора. Если вы можете, например, взять фреймворк, взять три каких-то его дополнения, прикрутить простенькую мордочку и разом решить все свои проблемы — это то, что доктор прописал (с моей точки зрения). Если вы вынуждены искать ночами, гуглить так, что Google вас уже просто банит, говорит, что вы бот, и показывает вам капчу на слово «фреймворк», например, то, скорее всего, что-то не то.

Тестирование — тоже очень важный момент. Не все фреймворки одинаково подлежат тому же юнит-тестированию. Есть фреймворки, которые поддерживают его легко и замечательно, есть такие, с которыми вы будете кривляться и проще, вообще, отдельно все написать. Есть со всякими юнит-штуками — JUnit, PHPUnit и др. — уже все это завязано. Вам уже ничего делать не надо. Это все уже есть. Если тестировать код, который вы написали, сложно, т.е. если у вас, например, для того чтобы протестировать какой-то код нужно сил приложить больше, чем его написать, зачем вам такая ерунда? Что вы с ней будете делать? Если вы, конечно, не какой-нибудь там mail.ru, например, компания, в которой здоровенный отдел тестирования, который может себе позволить много тестировать. Скорее всего, в вашем отделе тестирования только вы. Даже несмотря на то, что вы не инженер по тестированию. Сейчас с учетом всех псевдокризисов и т.д. все-таки на тестировании народ экономит, как может.

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

Есть ли обратная совместимость? Например, что сделали с той же Yii на PHP. Они версию 1 сделали не совсем совместимой с версией 2. Отличия не принципиальные, но тем не менее, взять и просто обновить фреймворк с версии 1 до версии 2, чтобы поиметь все плюсы версии 2, фиг получится. А, например, если вы берете какой-нибудь Symfony и программируете без деприкейтед методов, которые заранее были объявлены, то вы потом просто возьмете, накатите свежую версию и получите все плюшки.

В принципе, такая же история, как с языками программирования, когда у вас язык мигрирует. Python возьмем — «двойка» с «тройкой» что-то не очень дружат. Языки разные, протоколы разные в API этих фреймворков. Сейчас, например, модно выкидывать xml, везде вкидывать json. Т.е. ваше поделие было сделано с учетом того, что там xml, теперь бац — json.

Как с этим бороться? Понятно как — нужно, чтобы все было гибко, логично, слоисто и сервисно. Если вы хотите и планируете все это развивать долго и замечательно.

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

Еще классный критерий — есть ли что-то работающее на рынке с использованием этого фреймворка? Более-менее серьезное, не какой-то там чатик клана какого-нибудь в world of tanks, а что-нибудь более навороченное, какой-нибудь солидный магазин запчастей и т.п. Скорее всего, если люди эту штуку используют, то почему нет?

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

Я, например, не стесняюсь никаких «косяков» наших, и если кто-то придет и спросит, как мы решили вопрос перехода с Yii 1-го, на Yii 2-ой, я скажу, что мы отказались от Yii и перешли на Symfony. Потому что у меня есть пара сильных инженеров, которые убедили меня, что возможности, которые предоставляет Symfony (это один из PHP-фреймворков), нам более подходят, чем те, которые у нас есть. Мы очень долго с ним бодались. Вообще, вопрос появления фреймворков — это совершенно отдельная штука. Они у нас появились случайно. Заказали на out source проект и забыли спросить, на чем они его «запилят», а когда они его уже «запилили», оказалось, что они его «запилили» не на том, на чем у нас все остальное было «запилено». Но не выкидывать же, поэтому оставили. Так появился еще один фреймворк.

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

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

В заключение про камушки, которые собираются.

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

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

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

Поэтому нужна стратегия. Стратегия выбора фреймворка на самом деле вот такая:

За все эти годы, сколько я кривлялся со всеми этими выборами, ничего более умного в голову не приходит.

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

Я вам сейчас расскажу, как мы шли к Symfony. Мы начали собирать инженеров, которые умеют программировать на Symfony. У меня сначала он был один случайно, так получилось, он не ушел. Потом их стало два, три, сейчас их стало целых пять, когда их стало пять, стало понято, что эти пять могут научить остальные 15. Когда он был один, он не мог этому научить. Сейчас мы почувствовали себя спокойно, мы попали в ситуацию, которую я показывал на одном из слайдов — мы оценили свои возможности, поняли, что да, мы можем. Мы провели этот самый сравнительный анализ, мы запустили пару пилотов.

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

Перспективы проекта — тоже очень важная вещь. Если вы сейчас не знаете, что с ним будет, но вам уже нужно получать profit сейчас, ну их на фиг эти фреймворки. Вы лучше сразу придумайте архитектуру, как бы вы хотели, чтоб она выглядела, а потом купите Битрикс 24 облако и все там уже запрограммируйте по-быстренькому мышкой.

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

Там еще есть profit — важный пункт, до него нужно дойти, т.е. по кругу вот так вот ездить.

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

В ряде случаев это работает. Как у нас — у нас не очень большая нагрузка, хотя на самом деле, около 500 тысяч уникальных посетителей в сутки мы принимаем, и сервисная машина — это одна машина, это просто, физически один сервер. Он один умеет обслуживать достаточно… Еще есть Битрикс на семи серверах — сзади такой притаился, но это его сервера, он на них же и живет. А то, что новое — новое просто, чтоб понимать. Т.е. взяли, переписали технологию, получили прирост по производительности примерно раз этак в семь. Сейчас мы еще перейдем на PHP 7. Это о языках и версиях, и парни из Badoo говорят, что вообще прямо рай наступит. Ну, не знаю, мы проверим. При переходе с 5.3 на 5.6 рай почти наступил, т.е. мы процентов 30% поимели. Тут говорят, еще 60% поимеем.

Фреймворков столько, что времени не хватит их всех детально изучить. Как же выбрать? Какие критерии использовать? Что стоит изучить, а что стоит лишь просмотреть?

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

Источник

Начинающим программистам: что такое фреймворки и библиотеки

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

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

Фреймворки

Представьте: вам нужно построить дом. Можно выбрать готовый типовой проект и немного поиграть с планировкой, пока архитектор не против и вы не трогаете капитальные стены. А можно нарисовать план самому и получить именно тот дом, который хотите — даже если вы хотите цилиндрический дом со входом на втором этаже.

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

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

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

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

Библиотеки

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

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

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

Мы сами решаем, как и когда вызывать библиотечные функции и что с ними делать. Библиотека — это просто набор заранее определённых функций, из которых, как из кирпичиков, можно складывать то, что нам нужно. Ещё одно интересное свойство: внутри фреймворка можно использовать другие библиотеки. Например, если вам нужен адаптивный сайт и удобная работа с формами — используйте Bootstrap для адаптива как фреймворк и подключите к нему библиотеку jQuery.

Что теперь

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

Источник