Как известно, оливье быть, а раст лучший язык программирования. К сожалению, нанести вред проекту, людям, гретте тумберг легко - тупо не используя лучший язык программирования. Пожалуй, для тривиальной логики можно и без раста, или скажем, вы избрали путь html разработчика, хотя в последнем случае раст все равно найдет вас (в виде красной таблетки) в веб ассембли. Допустим, в проекте вокеры, темплейты, строгое "нет" реакту, манифесты, API для хранения данных в браузере, которое предоставляет доступ к виртуальной файловой системе, частной для источника страницы, и раст. Собрал для вас практики и ошибки, создавая проект, который с удовольствием использую вместо гугл шитс.

Allora:

1. Используя тип String в расте 60kb+ к продакшн билду -- юзайте плиз JsValue или JsString. Там много вопросов к размеру сборки, нижу будет еще инфа.

2. Семантика перемещения (move semantics) раста неприятно удивляет ошибкой "null pass to rust" в джаваскрипте. В js все обьекты передаются по ссылке (наследие явы), и не ожидаешь, что обьект будет не валиден после передачи в функцию веб ассембли.

3. Сериализация/десериализация обьектов в расте (serde json) 20kb+ к билду -- лучше без.

4. Без сериализации будут вопросы о сохранении, например, вектора строк -- что делать с разделителем и т.д.

5. К сожалению, нужно будет дебажить ошибки вида Uncaught Error: recursive use of an object detected which would lead to unsafe aliasing in rust -- разные ментальные модели раста и тайпскрипта всему виной.

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

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

8. Семантика перемещения (move semantics) очень хороша в расте, особенно это заметно в async/await примерах, где вам нужно уговорить компилятор.

9. Все знают, но хочется повторить: в расте прекрасное тестирование из коробки.

10. Для no_std (потому что хочется уменьшить размер билда) нужен внешний аллокатор (TalckWasm ок), но к сожалению, запрещено использовать HashMap и HashSet, но к счастью, прекрасно работают BTreeMap и BTreeSet. Итераторы хорошо работают в no_std.

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

Раст хорош для слоя данных, за отрисовку и эвенты используем тайпскрипт.

12. Можно без реакта, если не боимся разделения компонента и листенера. Cтоит отметить, что в реакте мы (обычно) платим за связку дополнительным состоянием (например, вообразите, пожалуйста, имплементацию списка песен и попап).

13. В html темплайтах используем соглашения об именовании - префикс для css классов совпадает (почти) с id темплайта.

14. Размер сборки тайпскрипта 10кб -- это когда без внешних зависимостей.

15. В ts классы с конструктором/деструктором (искуственным) сильно помогают для подписки/отписки листенеров. Да и для очистки прочих ресурсов тоже хороши.

16. Все в курсе, но на всякий случай -- веб может нативное приложение для ios и android, нужен manifest.json.

17. css можно на модули без внешних инструментов.

18. Желательно быстрая первичная отрисовка без wasm, из-за размера билда.

19. Это удобно, обернуть postMessage и onmessage для общения с вокером в промиз.

Для сервера статики скорее всего ваш знакомый разработчик посоветует питон либо ноду. Соглашаться не стоит быстро -- если выбор был бы между (корректно работающим) с++ сервером и нодой, многие выбрали бы c++. Раст лучше чем c++, то есть для статики выбираем rust (например, actix_web, хотя и их полно сейчас).

Деплоймент:

20. Используем vds машинку за 200-300 рублей в месяц.

21. Для доступа к файловой системе, к сожалению, нужен доступ по https -- как вариант, покупаем доменное имя у известного dns провайдера и мапим апишник vds сервера на ваше доменное имя.

22. Hастраиваем ротацию логов доступа к серверу и желательно минимальный firewall на вашей машинке.

Всякое:

23. Прямые и обратные операции держим вместе -- например, если хотим положить какие-либо параметры в GET урла, желательно иметь также функцию по извлечению параметров из урла.

24. Три фазы хорошего рендеринга (отрисовки): 1) медленный рендеринг, 2) рендеринг с анимацией, 3) отрисовка за два прохода - последняя фаза предполагает отрисовку из быстрого хранилища (например localStorage) и далее (те же данные) из медленого (например, origin private file system.

25. IOS (даже в хроме) только через вокеры для доступа к origin private file system.

26. Хорошая команда для проверки зависимостей cargo tree -e features.

В завершении об архитектуре проекта: 1) сервер статики, 2) wasm сборка - шарится между страничками, 3) для каждой странички отдельная сборка из файлов тайпскрипта (esbuild норм сборщик), 4) скрипты для версионирования статики - борьба с кешом, 5) ручка health check - сервер статики должен быть чуть-чуть умнее обычного, 6) makefile - все должно быть довольно прямолинейно.

Приблизительно 750 файлов пользователь открывает, заходя на главную страничку. Отрисовка на мобилках такого количества файлов происходит с небольшим лагом, поэтому нужно быстрое хранилище (например localStorage, который позволителен на 10Мb и переодически самоочищается :) и дублирующее ее медленное хранилище. Добавляя тонкости вокеров, и другие нюансы -- раст и, главное, компилятор раста -- прекрасный выбор от бесчисленных багов и глупых решений.

P.S.: размер билда (wasm) в итоге 96kb, после gzip 45kb