Я не OpenSource разработчик, но за пару десятков лет написал под сотню enterprise-level библиотек, которые остаются в рабочем контуре, дорабатываются под каждый проект и адаптируются к новым технологиям. Большого смысла выходить в OSS не было, кроме как для упрощения обучения коллег и единого места хранения документации.

Но и желание помогать другим и делиться выстраданными подходами, экспертизой и конкретным кодом мне не чуждо - сегодня поможешь ты, завтра - тебе. Через полгода подготовки и адаптации к OpenSource (сам использую и дорабатываю около 8 лет) в свет выходит одна из библиотек моего рабочего контура - Reactive Route.

Так как я работаю с проектами на разных стеках, стараюсь писать код максимально framework-agnostic - независимыми слоями, которые можно заменить или переписать, не трогая остальной код проекта. А к фреймворкам и библиотекам для работы с состоянием они подключаются с помощью легковесных адаптеров, сохраняя синтаксис работы. Конкретно для Reactive Route выложил набор готовых адаптеров в комбинациях, которые сейчас чаще всего использую:

• React + MobX / Observable

• Preact (no compat) + MobX / Observable

• Solid.js + нативная реактивность / MobX / Observable

• Vue + нативная реактивность

В одном npm-пакете - строгая TS-типизация, SSR / MPA / no-JS / Widget режимы и тщательно протестированная отказоустойчивость. В статье не буду пересказывать документацию на русском и английском, а поговорю скорее про общие принципы качества, использование ИИ в разработке и почему многие библиотеки раздуваются, не успев даже стабилизировать ядро.

Как известно, у Solid довольно скудная экосистема, поэтому для сложных проектов я беру React+MobX. Однако недавно подвернулся небольшой mobile-only проект, в котором разве что маскированные инпуты и кастомные селекты, которых для Solid предостаточно. При этом требования к размеру выходных файлов и перфомансу были высокие.

Очевидным решением посчитал взять Solid, заодно и сравнить его по всем параметрам (размер, перфоманс, возможности реактивности, удобство настройки) в реальном проекте. Никаких синтетических тестов с рендерингом больших таблиц и хранением в сторе нескольких мегабайт данных не будет, зато приведу замеры из реального приложения. Бонусом — репозиторий с универсальной архитектурой для Solid+Preact+React, где замена фреймворка (набора стейт‑менеджер + рендеринг UI) производится одной строчкой кода.

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

При загрузке сайта на сервер ложится множество задач, которые необходимо выполнять быстро и стабильно. Но ответственность за часть из них (например, обработку запросов на получение файлов, их пересылку клиенту и компрессию передаваемых данных) можно переложить на специализировые файловые хранилища. Они, как правило, имеют несколько территориальных зон и отдают клиенту файлы от наиболее близкого сервера (так, время загрузки ресурсов из физически удаленных от расположения основного сервера мест значительно сократится). Эти преимущества использования CDN — разгрузка сервера, сокращение времени доставки контента, а также сокращение трафика, передаваемого основным сервером (который обычно дороже), привели к довольно широкому использованию подобного подхода. Сегодня разберемся, как работать с Amazon S3-совместимыми CDN и настраивать передачу сжатых файлов.

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

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

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

• эти части собираются параллельно (в разных процессах)
• после пересборки серверной части перезапускается сервер, исходя из новых файлов
• после пересборки фронтовой части обновляется текущая страница в браузере
• изоморфные файлы вызывают обе пересборки, а неизоморфные — только соответствующую
• необходимые параметры (порт watch-сервера, https-режим) настраиваются через env-переменные

Коллеги настраивали лишь последовательную сборку этих частей при изменении любых файлов, что приводило к обязательному перезапуску сервера и нескольким перезагрузкам страницы (т.к. для этого использовалась либо middleware, отслеживающая запуск сервера, либо watch-сервер webpack, но видел и что используются они одновременно). Поэтому тема показалась актуальной, разберем все по полочкам.

Приветствую, хабровчане!

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