Стоит ли использовать фреймворк
Процесс создания веб-приложения требует немало времени и усилий. Чтобы сделать этот процесс более эффективным и экономичным, разработчики переходят на использование фреймворков — они помогают сократить количество требуемого кода, сделать приложение более стабильным, а вам не придется в тысячный раз изобретать колесо.
1. Они ограничивают творческое мышление
Если вы новичок в разработке, начинать изучение любого языка с них очень опрометчиво. Конечно, есть исключения — например, Ruby и Python, которые изначально не предназначены для использования в вебе без «родных» фреймворков. Но для большинства языков работает правило: сначала ООП, затем все остальное. Изучите архитектуру, паттерны, фундаментальные принципы программирования и создавайте проект с нуля, чтобы действительно разбираться в тонкостях.
Если привыкнете к удобному рамочному мышлению, искать нестандартные решения, выходящие за привычную систему, будет непросто, так как окажется, что вы плохо владеете чистым языком. Если же вы в нем ас, то фреймворк — лишь инструмент для оптимизации и структурирования кода.
Зачем использовать фреймворк?
Опытный разработчик назовет сразу несколько причин:
- ускорение разработки благодаря тому, что в фреймворках уже реализован базовый функционал, например, запросы к БД и многое другое;
- простота масштабирования и поддержки приложения;
- модель MVC (Model - View - Controller) — способ организации кода, где каждый модуль отвечает за свою задачу: модель — за структуру приложения и данные, представление (вид) — за то, что видит и с чем взаимодействует пользователь, контроллер — за связь между представлением и данными;
- организация базового уровня защиты приложения и многое другое.
Когда использовать JavaScript-фреймворк не нужно
Есть несколько ситуаций, в которых вместо JavaScript-фреймворка я рекомендую использовать микробиблиотеку или простой JavaScript.
- Ваше приложение — простое или маленькое. Например, у вас небольшой проект, вроде какого-нибудь эксперимента с новым JavaScript API.
- Высокие требования к производительности — если приложение должно быть высокопроизводительным даже при плохом интернет-подключении.
Есть множество инструментов, которые помогают в таких ситуациях. Но лучше предотвратить проблему, чем решать ее.
1. У вас большое приложение
Если вы разрабатываете большое приложение, использование JavaScript-фреймворка может быть разумным выбором, ведь в большинстве случаев у вас будет хорошая поддержка со стороны сообщества.
Обычно у вас будет много справочных материалов, которые помогут обеспечить долгосрочную поддержку приложения.
3. Быстрая разработка новых функций
У большинства фреймворков есть множество инструментов, которые позволяют быстрее реализовывать новые функции: разработчик может опереться на опыт знающих свое дело специалистов, которые вместо него хорошенько протестировали код.
Заключение
В этой статье преимуществ использования JavaScript-фреймворков оказалось больше, чем недостатков. (Если у вас есть что добавить — поделитесь в комментариях!)
Но даже если использование фреймворка звучит привлекательно, нужно внимательно следить за тем, что мы загружаем на свои веб-сайты и в разрабатываемые приложения.
Всегда задавайтесь вопросом: «Нужен ли здесь этот фреймворк? Может, лучше сделать всё своими руками или использовать что-то готовое?»
«Как применение фреймворка отразится на пользователях? Будет ли приложение на низкопроизводительном телефоне таким же удобным в использовании, как на флагманском устройстве?»
Поводом для этой статьи стала другая публикация на Хабре. Называется она «Не учите фреймворки, учите архитектуру» и почитать ее можно здесь.
Сразу оговорюсь, что с автором я полностью согласен и всего лишь хотел бы добавить свои «три копейки». Сначала думал сделать это прямо в комментах под статьей, но быстро понял, что «копейки» получаются довольно объемные. Так и родился этот текст.
Извечный вопрос
И что же делать? C одной стороны разработка на «чистом» языке — однозначно не вариант, а с другой и существующие инструменты не устраивают по целому ряду причин? Выход видится в создании инструмента, который бы оптимизировал наиболее часто используемые функции и одновременно не стеснял программиста, и не навязывал ему стиль программирования который автор этого инструмента считает единственно правильным. На практике, это означает, что инструмент должен:
К 2021 году появилось много статей о том, что фреймворки не нужны и не стоит делать из них культ. Отчасти это верно. Зависимость от фреймворка затрудняет процессы рефакторинга и тестирования, часто негативно влияет на выстраивание бизнес-логики приложения. Но во всём нужен разумный подход. И прежде чем встать на путь отрицания фреймворков, руководитель Программного комитета PHP Russia Александр Макаров советует прочитать статью Маттиаса Нобака (Matthias Noback) «Should we use a framework?»
В статье Маттиас рассказывает о том, какие вопросы должен задать себе разработчик, прежде чем выбрать фреймворк или отказаться от фреймворков вообще. Перевод статьи читайте под катом. В комментариях делитесь своим опытом выбора и использования фреймворков.
Так как я много пишу о разработке распределённых приложений, неудивительно, что один из моих читателей задал вопрос: «Зачем использовать фреймворк?». Короткий ответ: потому что он вам нужен. И вот почему:
- Фреймворк делает за вас слишком многое. Вам потребуется уйма времени и денег, чтобы заменить всё это на самостоятельно написанный вами код.
- Разработчики, поддерживающие фреймворк, исправили множество проблем ещё до того, как вы с ними столкнулись. Они постоянно заботятся о безопасности кода и исправляют проблемы по мере их появления. Вам остаётся только загрузить последнюю версию фреймворка.
- Отказавшись от фреймворка, вы не будете зависеть от Symfony, Laravel, Yii и так далее. При этом вы будете зависеть от своего фреймворка, а это ещё большая проблема, так как поддерживать его вам и очень вероятно что делать это вы не будете (по моему опыту, в проектах с самописным фреймворком, поддержкой самого фреймворка почти никто не занимается).
- Сложно угнаться за изменениями в фреймворке. При обновлении API, пользовательских соглашений или лучших практик фреймворка обновление кода проекта занимает слишком много времени;
- Трудно протестировать любую бизнес-логику без прохождения фронт-контроллера, анализа HTML-ответа или просмотра базы данных;
- Тестировать что-либо будет сложно, потому что изолированное тестирование в таких случаях невозможно. Обязательно нужно будет настроить схему базы данных, заполнить ее данными или поднять какой-либо сервисный контейнер.
- Сервисы приложения и командные объекты.
- Сущности и интерфейсы репозиториев.
- События домена и их подписчики.
- Запрос, ответ, сессия, хранилище токенов или менеджер безопасности,
- Локаторы сервисов, хэлперы для конфигурации, разрешители зависимостей,
- Подключения к базе данных, построители запросов, мапперы данных (или что там используется в вашем фреймворке).
- Могу ли я перенести это приложение из веба в консоль, не затрагивая ни один из основных классов?
- Могу ли я создать экземпляры всех классов в ядре моего приложения без подготовки какого-либо специального контекста или настройки внешних сервисов?
- Могу ли я перенести это приложение из базы данных SQL в документную базу данных, не затрагивая ни один из основных классов?
Если вы выполните все эти условия, ваш фреймворк будет выглядеть как обёртка вокруг изолированного ядра:
Фреймворк должен помочь вам:
- Хорошо справляется с задачами, обозначенными выше, чтобы мне не нужно было заменять или расширять что-либо самописными реализациями.
- Помогает разработчику: не нужно читать код, чтобы узнать, почему что-либо не работает.
- Экономит время на размышления обо всём этом, предоставляя правильные абстракции.
- Сопровождается хорошей, полной и актуальной документацией, так что каждый может узнать, как с ним работать
- Имеет четкие инструкции по обновлению, которые упрощают переход между версиями (или же это делается автоматически).
- Проводит четкое различие между сервисами и объектами других типов.
- Предоставляет неизменяемые объекты и сервисы без состояния, которые можно вызывать любое количество раз.
- Не предоставляет глобально доступные функции, позволяющие получать сервисы или конфигурацию.
- Запрещает изменять своё поведение через расширение классов. Всё-таки наследование — это опасная форма связанности.
Не изобретать велосипед, если есть уже готовая основа, — это выглядит очень привлекательным для начинающих разработчиков. Но с фреймворками, если использовать их бездумно, можно попасть во множество ловушек. Вот пять причин, почему вам не стоит использовать фреймворки.
3. Ошибки фреймворка — твои ошибки
Здесь все просто и очевидно. Даже в самом идеальном фреймворке может что-то сломаться и пойти не так. Но ответственным за это будет, увы, разработчик, особенно если он в команде один.
И если у популярной opensource-технологии, как правило, обширное сообщество, а у коммерческой — мощная поддержка со стороны консультантов, которые помогут решить проблему, то с более нишевыми инструментами все обстоит сложнее. Вероятно, со многими вопросами вы останетесь один на один и будете судорожно искать решение.
4. Негибкие и загоняют в рамки
Об этом мы отчасти сказали выше, но повторим еще раз. Даже опытный программист может облениться и попасть в ловушку использования чужих разработок, что уж говорить о новичках. Фреймворк определяет структуру вашего кода, и в каких-то ситуациях это хорошо, но не во всех без исключения.
Например, тенденция использовать поверх PHP еще один уровень абстракции в виде универсального фреймворка не может не удручать. PHP со всем его набором инструментов и библиотек для расширения кода сам является своего рода фреймворком. Некоторые программисты стремятся упростить разработку еще больше с помощью шаблонов, на деле же только затрудняя процесс. В итоге интерфейс усложняется, выдает больше ошибок и становится менее эффективным.
5. Снижают производительность
Всё это приводит к тому, что из-за множества уровней абстракции страдает производительность веб-приложения. Прежде чем запрос попадет в код, который написал разработчик, ему понадобится пройти огромное количество проверок и методов различных классов.
Сравните производительность JavaScript и фреймворков при поиске DOM-элемента по ID — первой строкой идет чистый код, данные взяты из этой отличной статьи:
Итак, фреймворки — абсолютное зло, если ими зло употреблять. Безусловно, их применение облегчает жизнь разработчику, но в то же время развращает. Поэтому всегда задумывайтесь о том, как использовать инструмент оптимальным образом, чтобы не начать стрелять из пушки по воробьям.
Знать нативный JavaScript на отличном уровне необходимо независимо от того, используете вы фреймворки или нет. Приходите на практический курс, где вы обучитесь работе с CSS, JS, jQuery, библиотеками и начнете уверенно программировать за полгода.
2. Вы (или компания) цените открытый исходный код
Самое лучшее в открытом коде — то, что его можно свободно использовать (в рамках лицензии, конечно).
Многие элементы таких фреймворков разрабатываются в свободное от основной работы время — поэтому за его использование ничего платить не нужно.
А если захочется внести вклад в открытый JavaScript-фреймворк, это принесет пользу и другим.
2. Ужасно сочетаются друг с другом
Если применить все на одной странице, разверзнутся врата ада, и на вас дыхнет пламенем прямиком из репозитория.
Если применить все на одной странице, разверзнутся врата ада, и на вас дыхнет пламенем прямиком из репозитория.
Самая главная проблема — их невозможно или очень сложно комбинировать друг с другом. Если фреймворки в JavaScript еще можно кое-как соединить с помощью jQuery, то для того же PHP это невыполнимая задача.
Frontend-разработчики вдобавок сталкиваются с тем, что под тот или иной фреймворк нет библиотеки. Или есть, но не с тем функционалом. Адекватный выход из ситуации — писать с нуля или самостоятельно доделать подходящую. Но зачастую в проектах используют jQuery с уже готовым решением просто потому, что время — деньги. В итоге получаются раздутые структуры, от которых затем страдают все.
Большие обещания маленькие достижения
Встретил я ее с энтузиазмом. Действительно — вроде бы появился инструмент призванный существенно облегчить разработку, способный избавить от большого количества рутины. Однако энтузиазм быстро улетучился. И вот почему.
Не знаю кто как, но я, в первую очередь, ждал избавления от большого количества однообразных действий, которые приходилось выполнять при работе над каждым новым проектом. Проектировать «костяк» базы, писать вывод по сути одинаковых текстовых страниц и т.д и т.п. Кто написал достаточное количество сайтов без труда дополнит это список многими и многими пунктами. И большинство фейерверков действительно избавляют от кучи рутины. Но какой ценой!
Плюсы и минусы использования JavaScript-фреймворков
В использовании JavaScript-фреймворка есть свои плюсы и минусы. И речь здесь не о плохих и хороших фреймворках, а о том, какие из них в каких ситуациях показывают себя лучше.
На основной работе я использую Angular, но люблю поэкспериментировать с React и Vue.js, а иногда пробую какую-нибудь небольшую микробиблиотеку JavaScript, которая делает что-то одно, но зато очень хорошо.
Как выбрать фреймворк?
Не стоит открывать наиболее свежий список php-фреймворков и бросаться на самый навороченный из них. Прежде всего изучите варианты и проанализируйте следующие параметры:
- каков функционал фреймворка и подходит ли он разрабатываемому приложению;
- насколько высок порог вхождения;
- как динамично развивается фреймворк;
- есть ли качественная документация и активное сообщество;
- гарантирована ли поддержка.
Сегодня мы кратко рассмотрим 3 фреймворка — Laravel, Symfony и Phalcon.
Отличный фреймворк с низким порогом вхождения — после внимательного ознакомления с документацией его смогут освоить разработчики, ни разу не работавшие с фреймворками на практике. Самый простой для изучения благодаря исчерпывающим руководствам и сообществу.
+ базовый функционал, достаточный для разработки несложного приложения, просто расширяется дополнениями;
+ много встроенных функций — кэширование, маршрутизация, управление ролями пользователей, аутентификация и многое другое;
+ легко интегрировать со сторонними библиотеками;
+ огромное, динамично развивающееся сообщество;
+ подробная документация, легко найти информацию на русском;
+ есть свой шаблонизатор Blade;
+ легок в освоении;
+ более 9 тысяч пакетов расширения.
Гибкая платформа разработки, которая послужила основой для других php-фреймворков, например, Laravel. Symfony — комплекс переиспользуемых php-компонентов, позволяющий разработать производительное веб-приложение. Выбор для тех, кому нужна действительно модульная платформа разработки.
+ простота интеграции с инструментами фронтенд-разработки;
+ включает возможность тестирования приложения;
+ поддерживает большое количество типов БД.
Php-фреймворк, основанный на С. Звучит довольно странно, не так ли? Однако эта особенность позволяет добиться высокой производительности и бережного потребления ресурсов. Как и Laravel, основан на архитектуре MVC.
+ бережное использование ресурсов;
+ "чистота" разработки — вы можете использовать только те библиотеки, которые действительно нужны вашему проекту;
Однако здесь стоит выделить и минусы. Согласно мнению разработчиков, Phalcon имеет достаточно высокий порог вхождения и менее дружелюбен к начинающему, чем тот же Laravel, поэтому не стоит осваивать его в качестве первого фреймворка. Кроме того, Phalcon проигрывает по документации и сообществу.
Выбирая фреймворк, не только проанализируйте его характеристики, но и узнайте, есть ли у вас вообще возможность развернуть приложение на фреймворке. Как правило, хостеры, размещающие на одной ВМ сразу несколько клиентов, не дают возможности полноценно развернуть приложение на том же Laravel из-за технических ограничений доступа.
Профессиональные методы требуют профессиональных средств. Однако не всегда это сопряжено с существенными вложениями. Виртуальный сервер от 1cloud обойдется вам всего от 550 рублей в месяц. Арендуйте или оставьте заявку на бесплатный тест прямо сейчас.
Понравилась статья? Тогда ставьте лайк и подписывайтесь на канал , чтобы не пропускать новые выпуски!
Фото — Maria Teneva, площадка Unsplash
Иногда React, Angular, Vue.js и т. д. — это лишнее
Правда ли, что JavaScript-фреймворков слишком много и выбор становится чересчур сложным? Или, может, мы просто забыли о соображениях производительности и о том, что за лишний трафик в итоге должны платить пользователи?
И это раз… и это два…
Моя первая претензия и к RoR, и Yii, и Symfony, и почти всем иным, с которыми пришлось познакомиться — их монстрообразность и тонны совершенно лишнего кода, который неизменно оказывается в проекте. Привыкнув за много лет работы, что код должен быть максимально чистым и лаконичным, что приложение должно быть как можно более быстрым, я в не мог согласится с тем мусором (уж извините по-другому сказать не могу), что оказывался в проектах.
Еще раз оговорюсь — я ни в коем случае не против учить что-то новое. Но только если это новое делает мой код лучше чище и быстрее. Если же мне нужно выучить что-то ради того что бы я потом как обезьянка мог клепать однотипные сайты и ни смел сделать шаг влево шаг вправо потому что просто не знал как — увольте.
Да самое плохое, что подобный подход к программирование просто отучает думать и когда этот новый супер крутой фреймворкер дает сбой, а это, поверьте случается сразу же как только клиент попросит от вас что-то хоть чуть выходящее за рамки, горе фреймворкер (недавно узнал, что есть теперь такая профессия) впадает в ступор и начинает задавать глупые вопросы на все доступных ему форумах. Закачивается же все тем, что кто-то из программистов (не фреймворкер) лепит для него костыль и дай Бог, чтобы заказчик не провел аудит кода.
Зачем использовать фреймворк?
Опытный разработчик назовет сразу несколько причин:
- ускорение разработки благодаря тому, что в фреймворках уже реализован базовый функционал, например, запросы к БД и многое другое;
- простота масштабирования и поддержки приложения;
- модель MVC (Model - View - Controller) — способ организации кода, где каждый модуль отвечает за свою задачу: модель — за структуру приложения и данные, представление (вид) — за то, что видит и с чем взаимодействует пользователь, контроллер — за связь между представлением и данными;
- организация базового уровня защиты приложения и многое другое.
Когда JavaScript-фреймворк — это разумный выбор
Часто использование JavaScript-фреймворка будет обосновано — но даже в этих случаях нельзя терять бдительности.
Сначала немного о себе
Эпоха чрезмерно большого выбора в мире JavaScript
Начинается 2020 год, и у наших сайтов и веб-приложений определенно есть «лишний вес». К нашим услугам Angular, React, Vue.js, Svelte, Polymer (и это далеко не всё) — но необходимость постоянно делать выбор в стремительно разрастающемся зоопарке фреймворков утомляет.
Вы можете подумать: «Говори лучше за себя». Но именно это я сейчас и делаю: я критически оцениваю собственную «усталость» от изобилия в мире JavaScript.
Скажем честно: никогда еще не было так просто сделать веб-сайт или веб-приложение. Сегодня достаточно одной команды: ng new ИмяПроекта
в Angular, … в случае React и т. д.
В большинстве случаев мы выбираем то, что лучше подходит. Однако при этом нужно уменьшать количество JavaScript-кода и внимательнее относиться к тому, что загружается в приложение.
Потому что — а вдруг сочетания HTML, CSS и JavaScript окажется достаточно?
И говоря о JavaScript-фреймворках, я имею в виду и библиотеки JavaScript: Angular, React, Vue.js и Svelte — всё это вместе (и многое другое).
И это три…
Все выше сказанное касается не только front, но и back. Как следствие возникает вопрос — в самом начале я признал, что в ходе любой разработки приходится выполнять множество ненужных телодвижений, которые хотелось бы оптимизировать, но можно ли это делать такой ценой? А кроме того есть еще один момент, который в большей части касается разработки на Ruby.
Вернемся в эпоху jQuery
Помните, было время, когда JQuery использовали для всего! JQuery то, jQuery сё — повсюду легкий аромат jQuery. На любом веб-сайте и в каждом веб-приложении — jQuery.
В чем причина популярности этой библиотеки?
Простой JavaScript казался слишком сложным в применении. К тому, же между браузерами было много отличий.
Но пришло спасение — библиотека jQuery избавила сообщество JavaScript от этой головной боли. Правда, большинство из нас в результате стали лениться, поскольку перестали понимать, что происходит «под капотом».
Я прозрел, когда появился этот сайт.
Читайте также: