Как известно, у 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, но видел и что используются они одновременно). Поэтому тема показалась актуальной, разберем все по полочкам.

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

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