Эта статья была рецензирована Стефаном Максом и Нильсоном Жаком . Спасибо всем рецензентам SitePoint за то, что сделали контент SitePoint как можно лучше!
Фреймворки JavaScript предлагают множество функций, и неудивительно, что они становятся все более и более популярными. Они сильны и не так сложны в освоении. Как правило, мы используем их для больших и сложных приложений, но в некоторых случаях и для небольших. Узнав, как использовать фреймворк, у вас возникает желание использовать его для каждого приложения, которое вы хотите разработать, но вы забываете, что иногда достаточно использовать только старый добрый JavaScript.
В этой статье я расскажу о плюсах и минусах использования фреймворка и о том, что вы должны рассмотреть, прежде чем начать свой проект.
Рамки мощные
Каркасы имеют свои преимущества. Прежде всего, вам не нужно беспокоиться о пространствах имен, кросс-браузерной совместимости, написании нескольких служебных функций и так далее. Вы работаете над хорошо организованным кодом, созданным одними из лучших разработчиков в отрасли. Если вы хорошо знаете фреймворк, ваша скорость разработки может быть невероятно высокой. Более того, если у вас есть проблемы с какой-либо из функций, легко найти документацию по фреймворку, тонны бесплатных обучающих программ и большое сообщество, готовое помочь. Что делать, если вам нужно больше рабочей силы? Там нет хлопот с наймом. Если вы знаете, как работает данная структура, независимо от того, о чем идет речь, вы будете чувствовать себя как дома. И код самой платформы развивается каждый день, чтобы стать еще лучше, сильнее и безопаснее. Таким образом, вы можете просто сосредоточиться на том, что имеет значение: ваша работа.
В заключение, фреймворки очень мощные и предлагают множество функций, таких как шаблоны, маршрутизация и контроллеры. Но вопрос в том, нужны ли они вам для вашего проекта?
Часто фреймворки — хороший выбор, но это не так для каждой ситуации. Фреймворк имеет много полезных функций, которые в свою очередь увеличивают его вес. К сожалению, в некоторых случаях этот вес не оправдан, потому что небольшие проекты используют только крошечную часть фреймворка. В таких ситуациях сырой JavaScript (иногда называемый Vanilla JavaScript) может стать решением всех ваших проблем.
С помощью необработанного JavaScript ваш код будет легче, и вам будет легче разрабатывать и расширять его. Вам также не нужно тратить время на изучение одной или нескольких платформ для использования. Каждый фреймворк работает по-своему, поэтому даже если вы уже знаете, какую функцию создавать (возможно, потому что вы уже делали это в прошлом), вы реализуете ее по-разному в зависимости от фреймворка, который вы выбрали. Это правда, что чем больше вы знакомы с фреймворками JavaScript, тем быстрее вы изучаете новую, но вам всегда нужно тратить время на углубление темы (более или менее в зависимости от ваших навыков). Более того, всегда есть вероятность, что выбранный вами фреймворк не станет популярным и будет заброшен. Напротив, в вашем собственном коде такой возможности нет, и вам не нужно беспокоиться об обновлениях и прерываниях изменений более новых версий.
Фреймворки иногда излишни, и они усложняют структуру небольших проектов. Если вам нужны только некоторые из их функций, вы можете разработать их самостоятельно.
Например, одна из самых популярных функций современных JavaScript-фреймворков — двусторонняя привязка. Если вам это нужно, вы можете написать код, который реализует его самостоятельно. Вот пример двусторонней привязки всего в 100 строках JavaScript . Сто строк, без запутанности, эффект похож на решения фреймворков и, прежде всего, отсутствие ненужной функциональности. Для реализации этой функции также существует более современный подход. Вы когда-нибудь слышали о Object.observe () ? Вот пример возможности двустороннего связывания с использованием этого решения . Это может показаться слишком футуристичным, потому что не каждый браузер поддерживает его, но все же интересно взглянуть на него. Если вы хотите увидеть другое решение, вы также можете проверить bind.js. Подобная функциональность, но без Object.observe()
Минусы не использования фреймворков
Игнорирование фреймворков JavaScript иногда может быть хорошим выбором, но вы должны помнить о минусах этого подхода.
Во-первых, без основы у вас нет прочной базовой структуры. Вам нужно проделать большую работу, прежде чем вы действительно сможете приступить к разработке функций вашего продукта. Чем больше функций вы хотите добавить, тем больше времени вам нужно. Если вы разрабатываете для клиента, это может быть очень важной проблемой, потому что сроки редко бывают дружелюбными.
Во-вторых, качество кода имеет значение. Очевидно, этот фактор зависит от навыков разработчиков. Если вы очень опытный, качество будет хорошим. Но не все действительно освоили JavaScript, и вы не хотите, чтобы источник проекта был грязным. Плохо написанные фреймворки не будут жить слишком долго, в то время как хорошо написанные фреймворки будут поддерживать высокое качество как личных, так и коммерческих проектов.
Поскольку мы говорим о коде, мы не можем забывать об ошибках. Каждую серьезную основу составляют более одного или двух человек. Благодаря вкладу тысяч людей, жучкам очень трудно остаться незамеченными. Если вы решите отказаться от использования фреймворка, ваше приложение будет проверяться только вами и вашей командой. Если вы продолжите углубленные тесты, вам потребуется еще больше времени, которого у вас может не хватить!
То же самое относится и к безопасности. Это может быть намного хуже, чем в рамках по тем же причинам, о которых я упоминал ранее. Если над одним проектом работают несколько человек, есть больше шансов, что проблема безопасности будет замечена. Можно сказать, что разработать приложение несложно, а самое сложное — сделать его хорошим и безопасным. Если вы не чувствуете себя экспертом или беспокоитесь о безопасности, фреймворки или библиотеки вам очень помогут.
Также существует проблема кросс-браузерной совместимости. С хорошей основой вы можете забыть об этом. Если вы работаете с необработанным JavaScript, вы должны обрабатывать его самостоятельно или просто игнорировать (что не рекомендуется).
Я также хочу упомянуть проблему с наймом разработчиков. Это может быть реальной проблемой, особенно если вы хотите сделать это на более поздней стадии разработки. Если у них нет хорошего опыта, вы должны подробно объяснить им источник проекта, прежде чем они начнут работать над ним, и, опять же, это будет стоить времени. Даже если вы научите их всему, что им нужно знать, часто нет технической документации по коду проекта. Если у вашего нового сотрудника есть проблема, вы обязаны помочь. Конечно, вы можете написать документацию самостоятельно, но это стоит времени и усилий.
Использовать или не использовать, Frameworks? Это вопрос.
Исходя из вопросов, которые обсуждались до сих пор, когда вы должны использовать рамки? Вы должны принять во внимание несколько аспектов.
Давайте начнем с того, что, пожалуй, самое важное: время. Если ваши клиенты ставят вам сжатые сроки, не рекомендуется использовать фреймворки. Это ситуация, когда вы должны начать развиваться быстро и с уверенностью, что у вас есть прочная база. Если у вас есть опыт, фреймворки с их готовыми решениями идеально подходят для работы.
Еще один интересный случай — большие приложения. Если вы создаете что-то действительно большое, лучше всего использовать хороший фреймворк. У них есть все функции, которые могут вам понадобиться, и они предоставляют безопасный и производительный код из коробки. Писать все самостоятельно — все равно, что заново изобретать колесо для большинства функций, и это также отнимает много времени.
Если вы создаете сложные приложения без фреймворка, вы, вероятно, встретите все минусы JavaScript без фреймворка. Одним из них являются возможные ошибки. Если ваше приложение должно быть надежным, а вы не являетесь экспертом, фреймворки — хороший выбор. Даже если вы эксперт, проведение углубленных тестов сложного приложения может занять много времени. Если он у вас есть, и ваш клиент не возражает, продолжайте свой собственный код. Но обычно такого комфорта нет.
В некоторых случаях официальная документация довольно скудна, но если данная структура достаточно популярна, вы легко найдете ответы на свои вопросы. Для новичков разработка с использованием фреймворка кажется более простой, поскольку им не приходится иметь дело со структурой, которую они сами создают, и они могут просто «следовать правилам» фреймворка.
Наконец, если вы не одиноки и у вас большая команда, которая постоянно меняется, рамки — это находка. Если ваше приложение написано, например, с AngularJS, и вы нанимаете разработчика, который его знает, он / она предложит вам отличную поддержку. Если вы работаете с my-company-framework.js , все может быть намного сложнее.
Если вы не очень хорошо знаете JavaScript, написание кода самостоятельно может принести только вред. Ваш код может быть ошибочным, небезопасным и недостаточно эффективным. Но если вы знаете, что делаете, код, написанный для конкретного приложения, может работать лучше. Это может быть проще для расширения, и вы избежите загрузки тонны неиспользуемых функций. Так что, если у вас есть время и опыт, это может быть хорошим выбором, чтобы не использовать рамки.
Это еще более актуально для больших приложений, которые имеют множество индивидуальных функций. Тот факт, что ваше приложение предназначено для большого количества пользователей, не означает, что источник должен быть очень сложным. Если ваше приложение большое, но простое, использование ненужных функций массивных сред может вам дорого стоить. Большие приложения — это место, где вы можете поразить стены фреймворка и начать использовать неэффективные обходные пути. Если ваше приложение довольно специфично, предпочтительнее использовать другой подход. Фреймворки достаточно гибкие, но не могут предсказать все сценарии. Вы единственный человек, который знает, что ему нужно.
Иногда решение использовать фреймворк или нет зависит только от личных предпочтений. Если ваше приложение не очень сложное, вы можете установить собственное рабочее пространство. Всегда лучше создать определенное рабочее пространство для каждого проекта, но это не всегда возможно. Вы должны быть высококвалифицированными, чтобы сделать это.
Давайте встретимся посреди дороги
Теперь, когда я обсудил плюсы и минусы фреймворков, давайте поговорим о другой возможности. Допустим, у вас небольшой проект, вы не хотите использовать большие фреймворки, но у вас сжатые сроки. Чем ты занимаешься?
Вам не нужно закатывать рукава и работать 12 часов в день, чтобы встретить это. Когда вы думаете о фреймворке , вы, вероятно, думаете о большом наборе функций, но это не всегда так. Существует множество небольших и легких сред и библиотек для менее требовательных приложений. Иногда они могут быть лучшим выбором.
Существует множество минималистичных JavaScript-фреймворков, которые вы можете использовать. Например, вы можете дать шанс Сэмми, который будет сжат и разархивирован только на 16 КБ и 5,2 КБ. Sammy построен на системе плагинов и адаптеров и включает в себя только необходимый вам код. Также легко извлечь собственный код в повторно используемые плагины. Это отличный ресурс для небольших проектов.
В качестве альтернативы вы можете использовать супер миниатюрный Min.js , библиотеку JavaScript, полезную для выполнения простых запросов DOM и перехвата прослушивателей событий. Благодаря его jQuery-подобному стилю он очень интуитивно понятен и прост в использовании. Его цель — вернуть необработанный узел DOM, которым затем можно манипулировать, используя element.classListelement.innerHTML Ниже приведен небольшой пример того, как его использовать:
$('p:first-child a').on('click', function (event) {
event.preventDefault();
// do something else
});
Очевидно, это имеет некоторые ограничения. Например, вы не можете отключить события.
Вам нужна еще одна альтернатива? В этом случае я могу предложить вам Riot.js (1 кБ). Riot.js — это библиотека, в которой есть много инновационных идей, некоторые из которых взяты из React . Тем не менее, он пытается быть очень маленьким и более сжатым.
Давайте возьмем пользовательские теги для примера. Вы можете получить его с React, если вы используете Polymer. Это позволяет вам писать понятный человеку код, который затем преобразуется в JavaScript. В Riot.js вы можете иметь его без каких-либо внешних библиотек.
Вот пример с официального сайта, который показывает, как код выглядит до его преобразования:
<body>
<h1>Acme community</h1>
<forum-header/>
<forum-content>
<forum-threads/>
<forum-sidebar/>
</forum-content>
<forum-footer/>
<script>riot.mount('*', { api: forum_api })</script>
</body>
Это только одна из функций, которыми гордится фреймворк. Вы можете проверить веб-сайт, чтобы узнать больше об этом проекте .
Есть также Microjs , которые я просто обожаю. Это «микро-сайт для микро-фреймворков», который предоставляет вам набор миниатюрных и быстрых фреймворков и библиотек JavaScript. Каждый из них делает одно и делает это хорошо. Вы можете выбрать столько платформ, сколько вам нужно. Существует множество решений для шаблонизации, Ajax и HTML5. Microjs помогает вам избавиться от фреймворков, полных неиспользуемых функций, и имеет ряд других преимуществ. Предоставленные фреймворки и библиотеки действительно маленькие и простые. Редко даже найти файлы размером более 3-4Кб!
Возвращаясь к ранее упомянутому примеру двустороннего связывания без больших фреймворков, что, по вашему мнению, нам нужно сделать, чтобы использовать эту функцию в Microjs? Мы должны были бы посетить его веб-сайт и найти решение, готовое к интеграции. И угадайте, что? Это здесь! Одним из таких решений является микробиблиотека под названием двойной эмиттер , размер которой составляет всего 3,7 КБ.
Теперь, скажем, мы хотим простую систему шаблонов. Введите «шаблон» в поле поиска, и вы найдете длинный список, где вы можете выбрать все, что вы хотите. Вы также можете комбинировать одну микробиблиотеку со многими другими, создавая конкретное рабочее пространство для вашего конкретного проекта. Вам не нужно готовить его самостоятельно, и вам не нужно иметь дело с ненужными функциями.
Есть много возможностей для выбора, некоторые лучше, чем другие. Вы должны тщательно выбрать их и выбрать наиболее подходящий.
Наконец, я хочу упомянуть еще один замечательный проект под названием TodoMVC . Если вы растеряны и не знаете, что использовать в своем проекте, это инструмент для вас. Список хорошо сделанных JavaScript-фреймворков растет с каждым днем, и сложно проверить возможности каждого из них. TodoMVC делает всю работу за вас. Это проект, который предлагает то же приложение Todo, реализованное с использованием концепций MV * в большинстве популярных на сегодняшний день фреймворков JavaScript MV *.
Выводы
В заключение, вы должны использовать рамки или нет? Решение остается за вами. Прежде чем приступить к разработке, вы должны рассмотреть то, что вам действительно нужно, а затем оценить все плюсы и минусы каждого подхода.
Если вы выбираете фреймворк, то ищите тот, который наилучшим образом соответствует вашим потребностям. Если нет, ищите готовые решения, спрятанные в микро-фреймворках или микробиблиотеках. Если нет ничего хорошего для вас, и вы хотите развивать это самостоятельно. Там нет готового рецепта. Вы тот, кто знает ваши потребности и навыки. Есть только один совет: сосредоточьтесь на своих целях, и вы найдете правильное решение.
А что насчет тебя? Вы когда-нибудь пробовали одно из этих решений? Который из? Не стесняйтесь делиться своими комментариями в разделе ниже.