考えてみれば当たり前なんですが…
なぜ相性が悪いのか？
そもそもSSG (Static Site Generation)のモチベーションは、できる限りビルド時にリソースを読み込み、クライアントには内容が書き込まれたHTMLを返したい、というところにあります。
そのため多くのSSGフレームワークでは、ビルド時の処理を前提とした設計がなされています。
ところがTauriのようなアプリケーションでは、ビルド時にリソースを読み込むことは少なく、UIの大部分がクライアント側で決定されることがほとんどです。SSGフレームワークにおいて、ブラウザ上でリソースを読み込むということはあまり想定されていないため、場合によってはかなりしんどい実装になってしまうことがあり得ます。
Tauri + Vite + ⚪︎⚪︎ 構成が良さそう
ビルド時にリソースを読み込まず、大部分がクライアント側で決定されるということは、CSR (Client Side Rendering)が最も適していると言えます。
Tauriのガイドで紹介されていて、CSRを使うことができるフロントエンド構成として、Viteが挙げられます。
昨今、ReactやSvelteなどを使用する際はNext.jsやSvelteKitなどのSSR/SSGフレームワークをセットで使用することが多いため、あまりVite + ⚪︎⚪︎といった構成には馴染みがないかもしれません。
ViteとReactやSvelteなどを組み合わせることで、これらをCSRフレームワークとして使用することができます。
（この記事を書いている途中に Vite (Recommended) とあることに気がつきました…）
それでもビルド時にHTMLを生成したいんだっ！！
そんな時は、vite-plugin-handlebarsを使うとよいかもしれません。
HandlebarsとはHTMLのテンプレートエンジンで、比較的馴染みのある記法でテンプレートを記述することができます。
UIのうち動的な要素が部分的な場合は、このようなテンプレートエンジンを組み合わせることで、最適なパフォーマンスを得られるかもしれません。（未検証）
（記事とは関係ないですが、この考え方Astroっぽいですね。）