Разница между библиотеками JavaScript и фреймворками

Umar Hansa

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

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

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

Зачем изучать библиотеки и фреймворки?

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

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

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

Примеры библиотек и фреймворков

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

• В случае библиотеки код вашего приложения вызывает код библиотеки.
• В случае с платформой код вашего приложения вызывается framework .

Библиотека

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

Посмотрите на этот пример библиотеки lodash :

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

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

1. Оператор import импортирует библиотеку lodash в программу JavaScript.
2. Вызывается метод capitalize() .
3. Методу передается один аргумент.
4. Возвращаемое значение фиксируется в переменной.

Рамки

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

В этом примере показан простой фреймворк без библиотеки, в котором используется популярный фреймворк JavaScript Vue :

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

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

• Код фреймворка включает в себя множество методов и абстрагирует их в свой собственный API.
• Разработчики не имеют полного контроля над тем, как и когда происходят операции. Например, то, как и когда Vue записывает на страницу строку 'Hello, world' абстрагируется от вас.
• Создание экземпляра класса Vue имеет некоторые побочные эффекты , которые часто встречаются при использовании фреймворков, тогда как библиотека может предлагать чистые функции .
• Фреймворк предписывает определенную систему шаблонов HTML, а не использует вашу собственную.
• Если вы прочитаете дальше документацию по фреймворку Vue или документацию по большинству других фреймворков, вы увидите, как фреймворки предписывают архитектурные шаблоны, которые вы можете использовать. Фреймворки JavaScript снимают с вас некоторую когнитивную нагрузку, потому что вам не нужно разбираться в этом самостоятельно.

Когда использовать библиотеку, а не фреймворк

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

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

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

Возможность замены

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

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

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

Рассмотрим этот пример:

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

В предыдущем примере используется сторонний пакет @package/set-color в трёх отдельных файлах. Если вы работаете над этим кодом и вам необходимо заменить сторонний пакет, вам необходимо обновить код в трех местах.

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

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

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

Простота использования

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

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

Платформы могут смягчить эти проблемы с помощью общих передовых практик, таких как:

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

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

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

Производительность

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

Дерево трясется

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

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

Когда вы импортируете сторонний код в свой исходный код, вы обычно объединяете код в один или несколько выходных файлов. Например, файлы header.js , footer.js sidebar.js объединяются в файл output.js , который является выходным файлом, который вы загружаете в свое веб-приложение.

Чтобы лучше понять дрожание дерева, рассмотрим следующие примеры кода:

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

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

Наивный процесс сборки может экспортировать код с таким выводом:

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

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

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

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

console.log(7+10);

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

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

Обновления программного обеспечения

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

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

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

Трудоустройство

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

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

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

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

Заключение

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

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