Представляю вам вольный перевод статьи «Front-end Frameworks: Custom vs. Ready-to-use Solutions», автором которой является Ivaylo Gerchev.

Дилемма «собственное решение против готового к использованию» довольно распространена в мире веб-разработки. Неважно, будем ли мы говорить про CSS, JavaScript, PHP или любой другой фреймворк, написанный на другом языке программирования, вопрос использования предварительно написанного кода за вас против вашего личного решения возникает очень часто. Это особенно важный вопрос для фронтенд фреймворков, потому что они несут прямую ответственность за внешний вид сайта.

Фреймворки, похожие на Bootstrap и Foundation изменили то, как люди строят свои сайты. Эти инструменты делают процесс разработки сайта намного проще, особенно для не-программистов, и позволяют создать полноценный сайт в минимально возможные сроки без особых усилий. Но такой «автоматический» подход построения сайта имеет серьёзные недостатки.

Таким образом возникает вопрос: Чем проще решение, тем лучше?

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

Преимущества готовых к использованию решений

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

  • Вам не нужно быть программистом. Необходимы лишь базовые знания HTML и CSS, которых в большинстве случаев достаточно, чтобы получить красивый и работающий сайт. Для вас всё уже сделано квалифицированными разработчиками.
  • Как упоминалось ранее, фреймворк серьезно сокращает время и силы, расходуемые в процессе строительства сайта..
  • Функция Plug-and-play (дословный перевод «включил и играй (работай)»). Нам нужно сделать только некоторую разметку, чтобы получить полностью функциональный кусок кода (хорошо приготовленный из HTML, CSS и JavaScript суп), при этом не беспокоясь о стилизации, динамическом поведении и так далее.
  • При использовании фреймворка, мы можем быть уверены в том, что у нас есть стабильный и хорошо протестированный код.
  • Мы получаем регулярные обновления с исправлениями ошибок и новыми функциями для фреймворка.
  • Благодаря популярности готовых к использованию фреймворков, вы можете рассчитывать на помощь сообщества в виде статей, учебных пособий (в рамках вводного процесса), базу дополнений и расширений (для построения сайтов).

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

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

Итак, простое решение — это хорошо, но...

Недостатки готовых решений

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

  • Хотя Plug-and-play функциональность великолепно звучит, прежде чем воспользоваться всеми прелестями фреймворка вы должны потратить своё время на то, чтобы узнать, как использовать его.
  • Если задуматься, то термин «готовые к использованию» подразумевает под собой «одно решение для всех», когда фреймворк пытается решить проблемы всех пользователей для каждой ситуации, может случиться так, что веб-разработчик столкнётся с огромным количеством ненужного ему кода.
  • Так как готовые решения сделаны для массового потребителя, вы можете быть почти уверены в том, что вам придётся что-то настраивать под себя для удовлетворения потребностей вашего проекта, что занимает дополнительное время.
  • Если не вносить никаких изменений в фреймворк то, ваш сайт будет выглядеть так же, как и все остальные, что может повредить имиджу вашего продукта или, по крайней мере, ничего не сделает для его улучшения.
  • Во многих случаях, фреймворки не могут покрыть все потребности веб-разработчика, что приводит к дополнительной интеграции сторонних компонентов (например, в виде раздутых плагинов JQuery и т.п.).
  • Практически, вы не имеете никакого контроля над кодом. При этом, если команда разработчиков решит удалить какой-то компонент фреймворка, то вы будете вынуждены признать это изменение. Иначе, если вы не хотите соглашаться с их мнением, придётся модифицировать фреймворк или использовать старую версию их продукта.

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

Получается, что «среднестатистическое» решение — это не разумное решение.

Преимущества собственных решений

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

  • Создание собственного решения позволит вам сэкономить время и силы в будущем, потому что он был построен под ваши потребности в долгосрочной перспективе.
  • Вам или вашей команде не нужно изучать, как использовать и настраивать его, потому что вы уже будете знать его до последней строки кода (хотя новым членам команды придётся изучить его).
  • Он оптимизирован для удовлетворения всех ваших потребностей. Таким образом гораздо проще добиться высокой производительности.
  • Вы включаете в него только то, что необходимо, и в том виде, как это нужно лично вам. Нет ненужных вам вещей — нет раздутого кода.
  • Вы имеете полный контроль над кодом и его реализацией и можете быть уверены в том, что необходимые вам функции и компоненты не будут удалены в следующей версии, конечно, если в этом нет нужды.
  • Полная модульность. Гибкость вашего решения зависит только от вас. Вы можете использовать только те части вашего фреймворка, которые вам нужны для конкретного проекта.
  • Унифицированная кодовая база. Вы можете свести к минимуму использование сторонних компонентов.
  • Уникальность вашего сайта гарантируется на 100%. По умолчанию, темы в большинстве фреймворков в какой-то степени однотипны, и вам придётся создавать свой стиль оформления. Однако, для вашего фреймворка можно создавать уникальные темы с самого начала разработки..
  • Несмотря на время, затраченное на разработку фреймворка и дальнейшего его обслуживания, сам процесс разработки может многому научить вас, и, таким образом, улучшить ваши навыки веб-разработчика.

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

Недостатки собственных решений

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

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

Третье решение

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

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

Является ли «изобретение колеса» реальной проблемой?

На форумах, в блогах и подобных ресурсах, одним из основных аргументов против собственных решений, является вопрос: Зачем изобретать велосипед?

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

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

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

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

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

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

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

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

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

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

  • Смогу ли я сделать это?
  • Достаточно ли у меня свободного/дополнительного времени?
  • Разумно ли это делать самому?

Примечание

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

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

Я надеюсь, что эта статья разрешила дилемму «собственное решение против готового к использованию», и отныне вы будете уверенно принимать правильное решение для себя.