san-smith

Миграция с Flutter Web на Jaspr: наш опыт

2026-07-01T00:00:00+00:00

-- Открывай dart.dev! -- Обычная Димина напористость сегодня была приправлена доброй горстью нетерпеливости. -- Открыл? Теперь листай вниз! Что ты видишь в правом нижнем углу?
-- Ссылки всякие: на Github там, Twitter и т.п. -- в растерянности я пытался угадать, на что именно нужно обратить внимание.
Кажется, Дима по ту сторону звонка схватился за голову.
-- Видишь баннер "Built with Jaspr"?!
Я молча кивнул и кликнул по баннеру.

Уже несколько лет мы занимаемся развитием клиентского приложения на Flutter: начинали с мобильных платформ, когда веб и десктоп вышли в бету -- портировали его и на эти платформы. Последние два года PWA крутится в проде и в некоторых регионах является самой популярной платформой для нашего приложения.

Недавно мы попробовали мигрировать наше приложение с Flutter Web на Jaspr -- под катом расскажем о том, почему мы это сделали, с какими трудностями столкнулись и какие выводы сделали.

Что за Jaspr такой?

Jaspr — это современный веб-фреймворк с открытым исходным кодом, написанный на языке Dart и предназначенный для создания быстрых, производительных веб-сайтов и веб-приложений.

Главная идея Jaspr заключается в том, чтобы перенести компонентный подход и реактивную модель разработки из Flutter в нативный веб. В отличие от классического Flutter Web, который рендерит интерфейс на Canvas, Jaspr генерирует стандартный HTML и CSS, как это делают React, Vue или Angular.

Фреймворк поддерживает рендеринг на стороне сервера (SSR), генерацию статических сайтов (SSG) и классические одностраничные приложения (SPA).

Очень рекомендую посмотреть сайт проекта, там наглядно показано, чем Jaspr похож на Flutter, а в чём они отличаются.

Что не так с Flutter Web?

Для нас главная ахиллесова пята приложений на Flutter Web -- долгий холодный старт. Дело в том, что PWA, написанное на Flutter Web, должно загрузить canvaskit.wasm (несколько МБ) прежде, чем сможет нарисовать первый кадр. При хорошем интернете это не проблема, но в регионах, где нестабильный 3G -- это максимум, на который можно рассчитывать, становится больно. Первый запуск занимает несколько секунд, при плохом раскладе -- несколько десятков.

Угнать за 6 секунд

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

Аналитика показала, что пользователь не готов столько ждать -- если загрузка длилась более 6 секунд, то мы теряем потенциального клиента (напомню, речь о первом старте приложения).

Ещё одно неудобство для конечных пользователей -- приложение ведёт себя не как "обычный" сайт: нельзя воспользоваться поиском по странице, не работает выделение текста (без дополнительных приседаний со стороны разработчиков) и т.п. Особенно это становится заметно в десктопном варианте, где пользовательский опыт существенно отличается от мобильного.

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

Jaspr: Proof of Concept

Основное наше клиентское приложение имеет внушительную (по меркам Flutter проектов) кодовую базу и включает в себя работу с SignalR с кастомными протоколами, нетривиальную логику подписок на события и т.д. Объём передаваемых по сокетам данных может измеряться мегабайтами и вся эта красота должна оперативно обновлять ряд экранов в рантайме.

Для проверки концепции я выбрал один из самых нагруженных экранов, для которого как раз и требовалась корректная работа с SignalR -- благо модульная структура нашего приложения позволяла.

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

Вынести в чисто дартовые пакеты общий код (работа с сетью, бизнес-логика и т.п.);
Перевести "старые" Flutter модули на использование этих дартовых пакетов;
Реализовать Jaspr версии "старых" модулей и собрать Jaspr приложение.

Немного о структуре проекта

На самом деле у нас не одно приложение, а несколько. И собираются они из нескольких десятков пакетов -- такой подход позволяет, с одной стороны, изолировать код, а с другой -- использовать его повторно. Наши пакеты, за редким исключением имеют одинаковую структуру:
my_package/
├── lib/
│   ├── src/
│   │   ├── api/          # работа с сетью, DTO
│   │   ├── domain/       # бизнес-логика -- репозитории, сервисы
│   │   ├── models/       # доменные модели данных
│   │   └── presentation/ # экраны, виджеты, утилиты для представления
│   └── my_package.dart
└── pubspec.yaml
api, domain и models, как правило, не требуют зависимости от Flutter SDK. Их можно безболезненно вынести в отдельный Dart пакет, мы договорились к таким пакетам добавлять суффикс shared.

Вечером я расчехлил Cursor и взялся за работу. Довольно быстро появились первые инсайты:

Наш код имел гораздо большую связанность, чем я предполагал;
Зависимость на Flutter SDK имели даже те пакеты, которым, казалось бы, никакой Flutter не нужен;
Web платформа имеет ряд своих особенностей (ладно, это я знал и раньше, но никогда не сталкивался в таких масштабах);
Я совершенно не разбираюсь в современной веб вёрстке.

Стало очевидно, что требуемый объём работ сильно больше, чем я ожидал первоначально. Для proof of concept пришлось сузить вводные: пока плюём на работоспособность Flutter версии, заменяем моками или упрощёнными реализациями ряд компонентов. Оставляем только основной сценарий: инициализация -> подключение к SignalR -> подписка на события -> отрисовка данных на экране с real time обновлениями.

Спустя несколько часов и полностью выжженные лимиты 20-долларовой подписки Cursor, мой прототип был готов. Визуально экран был очень далёк от flutter оригинала, линтер ругался как ненормальный на полученный код, тесты были сломаны, а diff включал в себя больше тысячи изменённых файлов -- Bitbucket был просто не в состоянии показать их все.

Но этот прототип работал. И работал хорошо: за вычетом внешнего вида, экран вёл себя ровно так, как и требовалось.

И как же быстро он загружался! После Flutter PWA это был как глоток свежего воздуха -- холодный старт занимал 1-1,5 секунды, а после включения экспериментальной компиляции в WASM так и вовсе измерялся в миллисекундах.

Да, конечно, прототип был сильно меньше оригинального Flutter приложения, но он показал очень хороший потенциал.

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

Jaspr: MVP

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

К этим вводным мы добавили свои:

пишем максимально приближенный к Flutter реализации код, чтобы уменьшить сложность перехода флаттеристов;
не используем условные импорты (у Jaspr не может быть io платформ);
стили компонентов описываем в отдельных CSS/SCSS файлах, не вмешивая сырые строки со стилями в dart коде.

Про стили

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

Поэтому нам пришлось портировать некоторые используемые пакеты на Jaspr: например, с опорой на пакет elementary мы запилили свой jaspr_elementary. Также потребовалось создать несколько локальных утилит, вроде генератора CSS стилей с watch режимом.

Про генерацию стилей

Допустим мы хотим создать компонент-контейнер ListGroup. Создаём файл стилей list_group.scss:

.list-group {
  display: flex;
  flex-direction: column;
  align-items: stretch;
  width: 100%;
  box-sizing: border-box;
  border-radius: var(--radius-m, 16px);
  background-color: var(--component-base-card-background);
  overflow: hidden;

  & > :not(:last-child) {
    border-bottom: 1px solid var(--component-divider-low);
  }
}

Выходные псевдоклассы будут иметь вид:

._72db67ef_list_group__list-group {
  display: flex;
  flex-direction: column;
  align-items: stretch;
  width: 100%;
  box-sizing: border-box;
  border-radius: var(--radius-m, 16px);
  background-color: var(--component-base-card-background);
  overflow: hidden;
}
._72db67ef_list_group__list-group > :not(:last-child) {
  border-bottom: 1px solid var(--component-divider-low);
}

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

Помимо выходных *.css генерируется ещё файл *.styles.dart с константами псевдоклассов:

abstract class ListGroupStyles {
  static const listGroup = '_72db67ef_list_group__list-group';
}

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

Теперь можно собрать всё вместе и использовать в Jaspr компоненте:

import 'package:jaspr/dom.dart';
import 'package:jaspr/jaspr.dart';

import 'list_group.styles.dart';

class ListGroup extends StatelessComponent {
  final List<Component> children;

  const ListGroup({
    super.key,
    required this.children,
  });

  @override
  Component build(BuildContext context) => div(
    children,
    classes: ListGroupStyles.listGroup,
  );
}

И остался последний элемент системы: watch процесс, который отслеживает изменения в *.scss файлах, вызывает для них инкрементальную компиляцию и генерацию новых *.css и *.styles.dart файлов. А затем копирует выходные .css файлы в каталог web: jaspr serve подхватит изменение веб-ассетов и обновит страницу.

Благодаря этому инструменту вёрстка компонентов стала почти такой же удобной, как и во Flutter.

В целом план реализации MVP практически совпадал с оным для прототипа:

Выносим общий код в Dart пакеты;
Мигрируем на них Flutter приложение;
Реализуем Jaspr версию приложения.

Только теперь без срезанных углов. Мы составили примерную диаграмму Ганта и, засучив рукава, взялись за работу.

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

И да -- оказывается, мы очень недурно проектируем и пишем Dart код! Большая часть написанного нами без сучка, без задоринки было готово работать с Jaspr. Пользуясь случаем, передаю ребятам привет -- вы очень крутые разработчики!

Затем мы приступили к портированию экранов. И опять же, значительная часть логики UI (которая в Flutter версии у нас хранилась в WidgetModel) прямо кусками переносилась в ComponentModel компонентов Jaspr -- тут хорошо сыграло решение с портированием Elementary.

Кстати, хозяйке на заметку: если Cursor сдобрить несколькими специфичными для Jaspr правилами и скиллами, то он очень неплохо готовит Jaspr компоненты на основе референса Flutter виджетов. Это сильно сократило время реализации.

И если к концу первого месяца даже у разработчиков были сомнения, что мы уложимся в дедлайн, то к концу второго месяца стало очевидно -- MVP будет готов. Возможно с некоторыми отличиями от макетов, но в функциональном смысле готов на 100%.

Результаты и выводы

Результат полностью оправдал наши ожидания: несмотря на то, что MVP был сильно больше прототипа, холодный старт сохранился на уровне 1-1,5 секунд (без компиляции в WASM).

Есть только миг

Чуть больше секунды на холодный старт до первого запроса к API. При тех же условиях версия на Flutter Web давала 6 секунд.

Бонусом мы неплохо отрефакторили код, а ряд идей, появившихся в процессе работы над Jaspr версией, были портированы и во Flutter приложение.

Мы сознательно упростили себе жизнь и использовали client mode, но Jaspr умеет и в SSR. А значит потенциально можно добиться ещё более лучших результатов.

Почему не SSR?

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

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

Несколько выводов, которые мы сделали по результатам этого эксперимента:

Чистая архитектура и модульность -- это реально очень важно! Не срезайте углы, потом может стать больно;
ИИ-инструменты хорошо помогают тем, кто их настраивает под проект. У остальных -- жрёт токены;
Jaspr -- действительно неплохая альтернатива Flutter Web для ряда сценариев;
Если вы работаете с вебом, вам не помешает иметь веб-разработчика в команде.

В целом Jaspr очень крутой проект, который позволяет Flutter разработчикам создавать веб-приложения с использованием имеющегося опыта. Но нужно трезво подходить к выбору технологий -- Jaspr (как и Flutter Web) хорошо подходит, если у вас есть сильная Dart команда и вы планируете переиспользовать большую часть кода.

Как мы WASM в PWA на Flutter прикручивали

2023-07-20T00:00:00+00:00

— Парни, у нас PWA тормозит! — в голосе Димы чувствовались нотки интриги.

Вообще-то мы разрабатываем на Flutter кроссплатформенное приложение для мобильных устройств, но коль уж фреймворк позволяет, на сдачу запустили и веб-версию. Поначалу с PWA мы отхватили немало проблем, но со временем большую часть из них победили. Только вот производительность (из песни слов не выкинешь) так и осталась ахиллесовой пятой приложения — даже на достаточно мощных устройствах нет-нет, да проскакивали микрофризы.

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

Вдоволь насладившись нашими удивлёнными взорами, Дима продолжил:

— Нет, вы не поняли. У нас приложение очень тормозит — слово "очень" он произнёс с акцентом на "о", ещё и протянув его пару секунд, чтобы подчеркнуть, насколько всё плохо. — Пользователи жалуются, что после авторизации может зависнуть на несколько секунд, иногда до десяти.

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

Дима подождал, когда схлынут самые жаркие споры и уточнил:

— Что думаете делать?

— А что тут думать, профилировать надо — высказал витавшую в воздухе мысль Саша.

Профилируем

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

Дело это нехитрое: запускаем веб версию приложения в режиме профилирования, открываем инструменты разработчика в браузере, переходим на вкладку "Perfomance" и в нужном месте включаем запись. После прохождения интересующего сценария в приложении останется остановить запись и подождать, когда Chrome подготовит данные.

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

Выглядела эта функция примерно так:

void _onPressed() {
  setState(() => _inProgress = true);

  // Вызов функции, которая долго вычисляется
  _result = fib(_value);

  setState(() => _inProgress = false);
}

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

Хорошо, что во Flutter есть волшебная функция compute! С её помощью можно вынести долгие вычисления в отдельный изолят, а когда вычисления будут завершены — положить их в нужное место. Понятно дело, что магия в этом мире работает плохо и получить искомое значение быстрее не получится, но хотя бы можно не блокировать основной поток. В этом случае пользователь вместо унылого застывшего экрана будет видеть экран с весёлым и задорным лоадером.

Саша уже умел пользоваться функцией compute, поэтому приступил к переписыванию кода.

Используем compute

Функция compute принимает два аргумента: вычисляемую функцию и её аргумент, а возвращает объект Future. С помощью метода then этого объекта мы можем присвоить нужное значение нашим переменным, когда вычисления будут закончены.

После переработки наш метод принял следующий вид:

void _onPressed() {
  setState(() => _inProgress = true);

  // Вызов функции, которая долго вычисляется
  compute((n) => fib(n), _value).then((value) {
    _result = value;
    setState(() => _inProgress = false);
  });
}

Получилось неплохо! — подумал довольный собой Саша, после того как запустил приложение на десктопе (обычно при разработке он запускал приложение на своём горячо любимом линуксе — так было быстрее). А чего бы ему не быть довольным? — кнопки нажимаются, лоадеры задорно крутятся и в нужный момент меняются на задуманные виджеты. Никаких тебе фризов.

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

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

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

All Dart apps can use async-await, Future, and Stream for non-blocking, interleaved computations. The Dart web platform, however, does not support isolates.

Перефразируя классиков, можно сказать, что товарищ compute в вебе нам совсем не товарищ.

Как оказалось, мы были не единственными, кто столкнулся с проблемой производительности при работе с данной библиотекой: в репозитории обнаружился issue двухгодичной давности, в котором обсуждалась эта проблема. Авторы библиотеки честно сказали, что для веба ничего сделать нельзя, разве что переписать её на WASM.

Мысль о реализации нужной функциональности для веба на технологии WebAssembly показалась интересной, ведь это стильно-модно-молодёжно, да и команда Flutter/Dart недавно рассказывала, что работает над этой технологией.

Прикручиваем WASM

Беглый поиск, однако, показал, что для Dart эта технология пока не готова к продакшену: поддерживают её только последние версии Chrome и Firefox, а Safari не поддерживает вовсе (и похоже не собирается).

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

Шаг первый: собираем wasm модуль

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

Создадим новый Rust проект:

cargo new --lib fib_wasm

Теперь нужно добавить в файл Cargo.toml новую зависимость:

[dependencies]
wasm-bindgen = "0.2"

Именно библиотека wasm-bindgen возьмёт на себя всю работу по подготовке Rust кода в wasm: для этого используется атрибут #[wasm_bindgen]:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn fib(n: u32) -> u32 {
    if n < 2 {
        n
    } else {
        fib(n - 2) + fib(n - 1)
    }
}

Чтобы собрать проект в wasm, нужно выполнить команду:

wasm-pack build --target web

После этого в каталоге с проектом появится папка pkg, в которой нас интересуют файлы <project_name>.js и <project_name>_bg.wasm.

Осталось придумать, как научить PWA использовать получившийся wasm файл.

Шаг второй: прикручиваем wasm к html

Для начала давайте положим полученные на предыдущем шаге файлы куда-нибудь поближе к index.html (можно просто в каталог web) и добавим в этот файл следующие строки:

  <script type="module" defer="">
    import init, { fib } from "./fib_wasm.js";
    init().then(() => {
      window.fib = (n) => fib(n)
    });
  </script>

Здесь мы добавили к объекту window нашу функцию, чтобы иметь возможность достучаться до неё из js кода.

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

В нашем случае это будут файлы fib.dart:

/// Сторонняя функция, которая долго вычисляется
int fib(int n) => switch (n) {
      < 2 => n,
      _ => fib(n - 2) + fib(n - 1),
    };

И fib_web.dart:

// ignore: avoid_web_libraries_in_flutter
import 'dart:js';

/// Сторонняя функция, которая долго вычисляется
int fib(int n) {
  return context.callMethod('fib', [n]);
}

Здесь мы обращаемся к той самой функции, которую добавили к объекту window.

Осталось внести изменения в наш исходный проект:

import 'fib.dart' if (dart.library.html) 'fib_web.dart';

Теперь можно и посмотреть, насколько быстрее стал наш код:

Ну что же, неплохо! В данном случае вместо 6 секунд результат был получен за 0,945 секунды. В зависимости от особенностей вычисляемой функции, результаты могут отличаться в большую или меньшую сторону: например, в одной нашей задаче время изменилось с 1,5-8 секунд до 0,05-0,09 секунды (sic!).

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

Заключение

Flutter — хорошая технология, которая действительно позволяет создавать крутые кроссплатформенные приложения. Но как и у любой технологии, у неё есть ограничения (особенно на не мобильных платформах). Однако технологии не стоят на месте и иногда, если ваше приложение споткнулось, ему могут помочь коллеги по цеху. Такие как Rust и WebAssembly.

Исходники проекта можно посмотреть на GitHub.

P.S. Все события вымышлены, любые совпадения с реальными людьми случайны. За время написания статьи ни одно мороженое не пострадало.