5.01. Инструменты и фреймворки

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Разработчику Архитектору

Инструменты и фреймворки

Архитектура крупных JavaScript-приложений

Модульность, загрузка кода и взаимодействие между компонентами
В больших приложениях (например, CRM, BPM, ERP) важно:
Разделять код на независимые модули.
Загружать их по мере необходимости.
Обеспечивать безопасное взаимодействие между модулями.
Поддерживать совместимость между разными версиями библиотек.

Что такое модули и библиотеки в JS-приложениях 
Отключение и подключение модулей, обязательность и необязательность
Зависимость и безопасное взаимодействие, совместимость
Системы модулей (AMD, CommonJS, ES Modules).

Системы модулей (AMD, CommonJS, ES Modules).

AMD (Asynchronous Module Definition)

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

define(['dependency1', 'dependency2'], function(dep1, dep2) {
        // Module logic using dep1 and dep2
        return {
            // Public API
        };
    });

AMD был популярен до появления ESM, особенно в enterprise-приложениях и фреймворках вроде Dojo Toolkit, Ext JS, старых версий Angular.

RequireJS — одна из самых известных реализаций AMD.

Позволяет:

• Динамически загружать модули.
• Управлять зависимостями.
• Оптимизировать сборку (через r.js).

Поддерживает загрузку не только JS, но и CSS, шаблонов.

// Загрузка модуля
require(['moduleA', 'moduleB'], function(A, B) {
    A.doSomething();
});

Хотя сегодня RequireJS уступает место Webpack, Vite и ES Modules, он всё ещё встречается в legacy-системах, особенно в корпоративных решениях (как Creatio/BPMSoft).

CommonJS

Используется в Node.js. Синхронная загрузка (require). Не подходит для браузера без сборщика

ES Modules (ESM)

Современный стандарт (import/export). Поддерживается браузерами и Node.js.

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

В контексте современных систем — таких как CRM, BPM, ERP или enterprise-платформ — приложения часто достигают сотен тысяч строк кода, охватывают множество бизнес-процессов и обслуживаются десятками инженеров. В таких условиях неструктурированный подход к организации кода приводит к техническому долгу, трудностям в тестировании, проблемам совместимости и снижению скорости разработки. Соответственно, в крупном приложении добавляются принципы:

• Модульность — разделение кода на автономные, переиспользуемые и тестируемые части.
• Ленивая загрузка (lazy loading) — загрузка кода по требованию, а не единовременно при старте приложения.
• Безопасное взаимодействие между компонентами — минимизация связности, контроль над интерфейсами.
• Управление зависимостями — явное декларирование и разрешение зависимостей между модулями.
• Поддержка версионной совместимости — возможность одновременной работы различных версий библиотек.

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

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

Преимущества модульного подхода:

• Уменьшение глобального загрязнения.
• Повторное использование кода.
• Легкость тестирования и замены реализаций.
• Возможность независимой разработки и развёртывания.

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

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

• Обязательными — необходимы для базовой работы системы.
• Необязательными (опциональными) — добавляют дополнительные возможности, но не влияют на корректность запуска.

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

Модули редко существуют изолированно. Чаще они зависят от других модулей или библиотек. Зависимость — это отношение, при котором один модуль использует функциональность другого.

Ключевые аспекты:

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

Последнее требует применения стратегий управления версиями (semver), механизмов изоляции (например, через sandbox) или использования шлюзов (adapters), преобразующих вызовы между разными версиями.

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

На сегодняшний день можно выделить три основные системы: AMD, CommonJS и ES Modules (ESM). Каждая из них решает задачу модульности в определённом окружении и с разными ограничениями.

AMD (Asynchronous Module Definition) — это спецификация, определяющая способ организации модулей с поддержкой асинхронной загрузки. Она была разработана с учётом особенностей браузерного окружения, где сетевая задержка при загрузке файлов является ключевым фактором производительности.

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

Две основные функции в AMD - define и require.

define(id?, dependencies, factory) — используется для определения модуля.

Здесь:

• id — необязательный идентификатор модуля.
• dependencies — массив строк, указывающих на другие модули, от которых зависит текущий.
• factory — функция-конструктор, которая будет вызвана после загрузки всех зависимостей. Аргументы функции соответствуют загруженным модулям в порядке объявления.

define(['dependency1', 'dependency2'], function(dep1, dep2) {
    // Логика модуля
    return {
        doSomething: function() {
            dep1.action();
            dep2.log('Module is ready');
        }
    };
});

require(dependencies, callback) — используется для загрузки и использования модулей в произвольном месте кода.

require(['moduleA', 'moduleB'], function(A, B) {
    A.doSomething();
    B.render();
});

Функция require гарантирует, что все перечисленные зависимости будут загружены до вызова колбэка.

AMD имеет особенности:

• Поддержка асинхронной загрузки — модули могут быть загружены по сети динамически.
• Гибкость в динамическом подключении — можно загружать модули «на лету», например, при переходе по маршруту.
• Поддержка не-JavaScript ресурсов — некоторые реализации AMD (например, RequireJS) позволяют загружать CSS, шаблоны, JSON и другие типы файлов через плагины.

AMD был особенно популярен в период до массового внедрения ES6 и ESM.

Он широко использовался в enterprise-фреймворках:

• Dojo Toolkit
• Ext JS
• Ранние версии AngularJS (через адаптеры)
• SAPUI5
• Creatio (ранее BPM'online) и BPMSoft.

RequireJS — одна из наиболее известных реализаций AMD. Она предоставляет динамическую загрузку модулей, управление графом зависимостей, оптимизацию сборки с помощью утилиты r.js, которая объединяет модули в единые файлы для production и поддержку конфигурации путей, алиасов и условной загрузки.

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

CommonJS — это инициатива сообщества, направленная на стандартизацию JavaScript вне браузера, в первую очередь для серверной среды.

CommonJS использует синхронную модель загрузки модулей через функцию require. Каждый файл представляет собой отдельный модуль с собственной областью видимости. Экспорт осуществляется через объект module.exports, импорт — через require.

Пример:

// math.js
function add(a, b) {
    return a + b;
}
module.exports = { add };

// app.js
const math = require('./math');
console.log(math.add(2, 3));

Особенности CommonJS:

• Синхронная загрузка — require блокирует выполнение до завершения загрузки и выполнения модуля.
• Подходит для Node.js, где файлы доступны локально на диске и задержки минимальны.
• Не поддерживается нативно в браузерах — требует сборщика (Webpack, Browserify и др.) для преобразования в браузерный формат.
• Прост в использовании, хорошо работает с файловой системой.

CommonJS имеет и ограничения, к примеру, он непригоден для браузера без инструментов сборки из-за синхронной природы, не поддерживает динамическую загрузку «из коробки» (хотя современные сборщики эмулируют её) и может приводить к большим bundle-файлам при отсутствии tree-shaking. CommonJS остаётся стандартом де-факто в Node.js, хотя начиная с Node.js 14+ активно развивается поддержка ESM.

ES Modules (ECMAScript Modules, ESM) — это официальный стандарт модульности, принятый в спецификацию ECMAScript (ES6, 2015). Он представляет собой декларативный подход к модульности с поддержкой как статического, так и динамического импорта. Синтаксис включает два основных варианта:

• import — для импорта сущностей.
• export — для экспорта.

// utils.js
export function validateEmail(email) {
    return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}

export const MAX_ATTEMPTS = 3;

// main.js
import { validateEmail, MAX_ATTEMPTS } from './utils.js';

if (validateEmail('user@example.com')) {
    console.log(`Attempts allowed: ${MAX_ATTEMPTS}`);
}

Также поддерживается дефолтный экспорт:

// logger.js
export default function log(message) {
    console.log('[LOG]', message);
}

// main.js
import logger from './logger.js';
logger('Hello world');

ESM поддерживает динамический импорт через import() — функцию, возвращающую Promise. Это позволяет загружать модули по требованию. Это ключевой механизм для ленивой загрузки в современных SPA:

button.addEventListener('click', async () => {
    const module = await import('./heavyComponent.js');
    module.render();
});

Какие же особенности есть у ESM?

• Статическая структура — анализ зависимостей возможен на этапе сборки (enables tree-shaking).
• Асинхронная загрузка — реализуется через import() и поддерживается браузерами.
• Нативная поддержка — в современных браузерах и Node.js (с флагом .mjs или "type": "module" в package.json).
• Однократная загрузка — модуль кэшируется; повторные импорты возвращают тот же экземпляр.
• Жёсткие правила относительных/абсолютных путей — в браузере требуется полное имя файла с расширением (например, ./utils.js, а не ./utils).

Преимущества перед предыдущими системами:

• Единый стандарт, поддерживаемый движками.
• Интеграция с современными инструментами (Vite, Webpack, Rollup).
• Поддержка tree-shaking, code splitting, HMR.
• Совместимость с TypeScript и JSX.

Переход с CommonJS на ESM в Node.js потребовал решения проблемы двойной поддержки. Для этого используются расширения .cjs/.mjs, поле "type": "module" в package.json и условные exports ("exports" в package.json).

Архитектура крупных JavaScript-приложений невозможна без чёткой системы модулей. Выбор между AMD, CommonJS и ES Modules определяется контекстом: целевой средой, требованиями к производительности, размером команды и историческим багажом проекта.

Если вам придётся работать с JS, то скорее всего не на ванильном, а на каком-то из вышеперечисленных вариантов. К примеру, это может быть разработка систем на платформе Creatio, которая как раз использует AMD.

Песочница (Sandbox) и шина сообщений

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

Что такое песочница? Это изолированная среда выполнения для модулей.

Модули не видят глобальных переменных и не могут напрямую вызывать друг друга, а взаимодействие происходит через центральную шину сообщений (event bus).

Как это работает?

// Модуль отправляет сообщение
sandbox.publish('user:login', { userId: 123 });

// Другой модуль подписывается
sandbox.subscribe('user:login', function(data) {
    console.log('Пользователь вошёл:', data.userId);
});

Преимущества:

• Изоляция: один модуль не может сломать другой.
• Гибкость: модули можно добавлять/удалять без переписывания кода.
• Безопасность: предотвращается загрязнение глобальной области.
• Поддержка микроприложений и плагинов.

Такой подход используется в:

1. Creatio / BPMSoft. Например, в Creatio можно представить, что:

   • Ядро предоставляет песочницу и шину сообщений.
   • Каждый модуль — это AMD-модуль, загружаемый по требованию.
   • Внешние библиотеки (Angular, Ext JS) подключаются как зависимости.

2. Ext JS + Sencha Cmd. Ext JS активно использовал RequireJS и AMD до перехода на современные сборщики. MVC/MVVM архитектура хорошо сочетается с шиной сообщений.

3. Backbone.js с Marionette

Angular, Vue, React не используют такой подход - там ES Modules.

Сегодня вместо AMD и песочниц используются:

• ES Modules + Dynamic import() — для динамической загрузки.
• Micro-Frontends — архитектура, где каждая часть приложения — независимое приложение.
• Module Federation (Webpack 5) — позволяет объединять модули из разных приложений.
• Web Workers / iframes — для настоящей изоляции.

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

Для решения этих проблем применяется подход, основанный на изоляции модулей и опосредованном взаимодействии через централизованные механизмы. Два ключевых элемента такого подхода — песочница (sandbox) и шина сообщений (event bus).

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

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

Основные характеристики песочницы:

• Изоляция: модуль не имеет прямого доступа к объектам других модулей.
• Ограниченный API: модуль может использовать только те методы, которые явно предоставлены песочницей.
• Единая точка входа/выхода: весь обмен данными проходит через строго определённые интерфейсы.
• Контекст исполнения: песочница может инжектировать зависимости, управлять жизненным циклом модуля и перехватывать ошибки.

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

При отсутствии прямых ссылок между модулями возникает необходимость в альтернативном способе обмена информацией. Этой функцией служит шина сообщений (message bus, event bus) — централизованный механизм маршрутизации событий.

В шине сообщений, модули не вызывают друг друга напрямую. Вместо этого они:

• Публикуют события — отправляют сообщение в шину с указанием типа события и полезной нагрузки.
• Подписываются на события — объявляют интерес к определённым типам сообщений и регистрируют обработчики.

// Модуль A: публикует событие
sandbox.publish('user:login', { userId: 123 });

// Модуль B: подписывается на событие
sandbox.subscribe('user:login', function(data) {
    console.log('Пользователь вошёл:', data.userId);
});

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

Типы событий:

• События домена — отражают бизнес-события (order:created, user:updated).
• События UI — связаны с интерфейсом (modal:open, form:submit).
• Системные события — управляют жизненным циклом (module:loaded, app:ready).

Причём эти события уже не относятся к DOM-событиям вроде кликов мыши, нет. Это полноценные действия в других модулях.

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

Одним из характерных примеров применения песочницы и шины сообщений является платформа Creatio (ранее BPM'online), ориентированная на enterprise-сегмент и построенная на основе AMD и собственной архитектуры модульности.

Архитектурные особенности:

• Ядро системы предоставляет экземпляр песочницы каждому загружаемому модулю.
• Все модули являются AMD-модулями, загружаемыми по требованию.
• Взаимодействие между модулями осуществляется исключительно через sandbox.publish() и sandbox.subscribe().
• Внешние библиотеки (например, Ext JS) подключаются как зависимости через AMD, но их использование контролируется через API песочницы.

Такой подход позволяет настраивать поведение CRM/BPM-системы без изменения ядра, разрабатывать модули независимыми командами и обеспечивать обратную совместимость между версиями.

Ранние версии фреймворка Ext JS активно использовали RequireJS и AMD для организации модульности. Архитектура MVC/MVVM, заложенная в Ext JS, хорошо сочетается с шиной сообщений: контроллеры могут обмениваться данными через глобальный event bus, минимизируя прямые связи между представлениями и моделями. Sencha Cmd — инструмент сборки — позволял управлять зависимостями, оптимизировать загрузку и создавать изолированные модули, что соответствовало принципам песочницы.

Фреймворк Backbone.js, хотя и не предусматривает шины сообщений «из коробки», допускает её реализацию через Backbone.Events. Библиотека Marionette расширяет этот подход, предоставляя EventAggregator — централизованный менеджер событий, выполняющий функции шины.

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

Хотя модель песочницы и шины сообщений остаётся актуальной в legacy-системах, в современных архитектурах она постепенно вытесняется более масштабируемыми и стандартизированными решениями. С появлением нативной поддержки ES Modules и динамического импорта (import()), необходимость в AMD и внешних системах загрузки отпала. Теперь модули могут загружаться по требованию без дополнительных библиотек:

button.addEventListener('click', async () => {
    const { renderChart } = await import('./charts.js');
    renderChart(data);
});

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

Архитектура микрофронтендов предполагает, что каждая часть приложения — это самостоятельное приложение со своей технологической стеком, CI/CD и командой. Взаимодействие между ними может происходить через Custom Events, Shared libraries, State managers или ту же шину сообщений, но на уровне окна (window.postMessage).

Module Federation — механизм, позволяющий объединять модули из разных сборок Webpack в единую runtime-среду. Он даёт возможность импортировать модули «на лету» из удалённой сборки, совместно использовать библиотеки, строить распределённые приложения без централизованной сборки. Module Federation можно рассматривать как эволюцию идеи песочницы: модули остаются независимыми, но получают контролируемый доступ к функциональности друг друга.

Для достижения настоящей изоляции, когда модуль не может повлиять на глобальное состояние, используются:

• Web Workers — выполнение кода в отдельном потоке без доступа к DOM.
• iframes — изоляция на уровне документа, с собственным window, document, localStorage.

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

Общее о фреймворках и транслируемых языках

Прочие транслируемые языки, подобные TypeScript - CoffeeScript, Flow, Dart, Brython.

Ещё есть ActionScript – язык для Flash-приложений. Сейчас его уже редко встретить из-за того, что устарел. Использовался для анимаций, игр, веб-приложений.

Фреймворки JavaScript.

Фронтенд:

Фреймворк	Описание
React	Библиотека для UI. Создана Facebook (Meta), работает с компонентами — маленькими частями интерфейса. Не навязывает архитектуру, но требует больше самостоятельности. Часто используется с ReactDOM, React Router, Redux, Next.js react.dev metanit.com/web/react cheatsheets.zip/react
Vue	Прогрессивный фреймворк. Легко внедряется в существующий проект, весьма простой и понятный для новичков. Используется с Vue Router, Vuex, Nuxt.js vuejs.org metanit.com/web/vue cheatsheets.zip/vue
Angular	Фреймворк от Google. Написан на TypeScript, имеет чёткую структуру: компоненты, сервисы, директивы, модули. angular.dev metanit.com/web/angular2
Svelte	Компилируется в чистый JavaScript, не использует виртуальный DOM. Логика, разметка и стили объединены в одном файле компонента. svelte.dev
Ext JS	Extended JavaScript (Sencha Ext JS), включает виджеты, графики, древовидные структуры и меню для создания сложных интерфейсов с поддержкой MVC-шаблона с разделением логики приложения, данных и представлений. www.sencha.com/products/extjs metanit.com/web/extjs

Фронтенд-фреймворки помогают создавать динамические интерфейсы и управлять состоянием приложения.

Бэкенд (Node.js):

Официальный сайт Node.js - https://nodejs.org/

Фреймворк	Описание
Express	Минималистичный фреймворк expressjs.com
NestJS	Фреймворк с TypeScript nestjs.com
Fastify	Альтернатива Express (высокая производительность) fastify.dev

Фреймворк — это не IDE (типа VSCode), а набор готовых решений и структура, которые помогают разрабатывать приложения быстрее, проще и с лучшими практиками.

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

Работа с фреймворком подразумевает:

1. Импорт модулей (к примеру, import React from 'react';).
2. Использование специфичных конструкций, к примеру

// React
function App() {
  return <h1>Привет, React!</h1>;
}

// Vue
export default {
  template: `<h1>Привет, Vue!</h1>`
}

// NestJS
@Controller('cats')
class CatsController {}

3. Следование определённой структуре проекта. Например, в Angular или NestJS у нас будут папки components, services, modules и так далее.
4. Использование CLI (интерфейс командной строки) - большинство фреймворков предоставляют CLI-инструменты:

	- ng new my-app — Angular
	- create-react-app my-app — React
	- nest new my-project — NestJS
	- npm create vue@latest — Vue

Эти команды создают уже подготовленную структуру проекта с нужными зависимостями и конфигами.

Среди фреймворков можно также выделить Electron (хотя это скорее среда разработки) с открытым исходным кодом, который позволяет создавать десктоп-приложения с использованием веб-технологий HTML, CSS и JavaScript. Он основан на Node.js и движке Chromium. Приложения на Electron можно запускать на Windows, macOS, Linux, можно работать с файловой системой, сетью, процессами (благодаря Node.js).

На Electron работают Visual Studio Code, Slack, Discord, Postman, Atom, Trello Desktop, GitHub Desktop - то есть, среда довольно функциональная и позволяет формировать GUI. У Electron есть и альтернативы вроде Tauri (для Rust), NW.js, Flutter Desktop (Dart), React Native.

Минимальное приложение на таком движке имеет package.json, main.js, index.html.

jQuery

jQuery — это популярная JavaScript-библиотека с открытым исходным кодом, которая упрощает работу с DOM (Document Object Model), обработку событий, анимацию и взаимодействие с сервером через AJAX. Она была создана в 2006 году Джоном Резигом и с тех пор стала одной из самых используемых библиотек на стороне клиента.

jQuery позволяет легко находить элементы на странице и манипулировать ими:

// Пример: изменить текст всех параграфов
$('p').text('Новый текст');

Легко добавлять обработчики событий:

// Пример: обработка клика по кнопке
$('#myButton').click(function() {
    alert('Кнопка нажата!');
});

Упрощает выполнение асинхронных запросов к серверу:

$.ajax({
    url: 'https://api.example.com/data', 
    success: function(response) {
        console.log('Данные получены:', response);
    }
});

Встроенные методы для анимации:

// Скрыть элемент с анимацией
$('#box').fadeOut(1000);

// Показать элемент
$('#box').fadeIn(500);

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

Официальный сайт - https://jquery.com/

Чит-лист - https://cheatsheets.zip/jquery