Experience With Tauri + SvelteKit

[lorenzolewis]

Recently there's been a lot of conversation around using SvelteKit and Tauri together. We want to know:

• 💪 What's worked for you?
• 🤕What's not quite worked as expected?
• 🤔Have there been any learning curves or tough points along the way?

Let us know your feedback!

[lorenzolewis]

A few thoughts from looking through the steps we have in the guides: https://tauri.app/v1/guides/getting-started/setup/sveltekit

SvelteKit and Tauri can work well together, but getting them setup can involve a few manual steps:

1. Add and setup @sveltejs/adapter-static
2. Add a root +layout.ts file with the following to enable disable SSR and enable pre-rendering:

export const prerender = true
export const ssr = false

These aren't necessarily difficult steps, but knowing the difference between SPA, SSG, SSR and what you can/can't do between each can make it tough to get started as a beginner

[lorenzolewis]

Thanks for giving your thoughts @austenc!

A things we could do to help would be to explain the pros/cons, features you gain/lose (in the context of Tauri) and recommended setup for:

1. Svelte vs. SvelteKit
2. SSR vs. SPA

For those who would like to know the why behind those options we could do some work in the docs to explain them. Or if someone just wants to zoom through and get a Svelte app up and running they could just follow the recommendations.

[austenc]

Of course @lorenzolewis, wish I could be more helpful! Likely too much of a Tauri and SvelteKit noob to give much more input, though.

I don't think those explanations are mandatory in the docs by any means. Was definitely zooming through myself 👍
That being said, it would be really neat to learn the pros/cons and see the differences explained by the folks who understand it well!

[jamauro]

For those who would like to know the why behind those options we could do some work in the docs to explain them.

Would love to understand more of the why behind SSG vs the other options

[sameoldlab]

I think the main reason in Tauri for SvelteKit, rather than Svelte is routing. I'm using Svelte with a lot of if blocks to render everything. SvelteKit, with SSR disabled, seems like it would be more straightforward for most people and picking a compatible routing library also requires users to know about SSR and SPAs.

Maybe something in docs that breaks down scenarios where SvelteKit becomes useful could help. Or linking to SvelteKit docs and what you get with Svelte (adding nuance that links work differently outside the browser, which can be very unexpected using Tauri the first time).

[KameiKojirou]

SvelteKit is the default recommended by the Svelte Dev team. All the documentation on their end points that direction as well. I believe the small manual edits and be mostly in line with the default build is the least resistant path in my opinion. Even 'svelte@latest' currently builds SvelteKit and points at its documentation instead of regular Svelte.

[astral4]

I've made one static website with SvelteKit and figured the knowledge would transfer over to Tauri. For the most part, that was true, but there are some bumps I've encountered.

One thing that confused me at the beginning was Content Security Policy configuration. SvelteKit lets you do this via svelte.config.js (SvelteKit docs), but Tauri also has a CSP configuration in tauri.conf.json (Tauri docs). I ended up configuring the CSP with SvelteKit and not touching the Tauri settings. I'm also not sure how SvelteKit interacts with Tauri when it comes to injecting nonces/hashes; apparently both do this. It hasn't caused issues yet, so I haven't looked into it.

On to the config itself:

// svelte.config.js

import adapter from '@sveltejs/adapter-static';
import preprocess from 'svelte-preprocess';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: preprocess(),
	kit: {
		adapter: adapter(),
		csp: {
			mode: 'hash',
			directives: {
				'default-src': ['none'],
				'img-src': ['self'],
				'script-src': ['self'],
				'style-src': ['self', 'unsafe-inline'],
			}
		}
	}
};

export default config;

I use a restrictive-by-default CSP. (unsafe-inline is there because Svelte uses inline styles for transitions.) This configuration worked fine for my previous SvelteKit website... but for my Tauri app, Vite's HMR broke! For a while, I was running npm run tauri dev every time I changed a file. Eventually, I fixed the issue by setting a connect-src directive like so:

        'style-src': ['self', 'unsafe-inline'],
+       // Vite uses WebSockets for HMR, so WebSocket connections to localhost:5173 are whitelisted during development
+       'connect-src': process.env.TAURI_DEBUG === 'true' ? ['ws://localhost:5173'] : undefined

I didn't realize that browsers and Tauri handled WebSocket connections differently.

This last point is not necessarily specific to SvelteKit and is more of a Vite thing, but I think it's worth mentioning. I encountered a bug in my app where certain images would not show in release builds, but were visible in debug builds. I think the cause goes like this: by default, Vite inlines images smaller than 4KiB as base64 during release builds (Vite docs). Then, Tauri does something with the CSP that blocks these assets.

Mode	Browser webpage	Tauri webview
Debug	✅	✅
Release	✅	❌

I resolved this issue by disabling asset inlining in the Vite config file (vite.config.ts) like so:

build: {
        // The Windows webview (WebView2) is supposed to update itself automatically, so it's safe to target the latest 3 versions (i.e. Blink 108).
	// The macOS webview (WebKit) only updates with new OS versions, so the build target is more conservative; the earliest Safari version for macOS Big Sur is 14 (i.e. WebKit 610.2.11).
	// The Linux webview (WebKitGTK) is based on WebKit, so the target is the same as macOS.
	// Reference: https://discord.com/channels/616186924390023171/1082055425907753063
	target: process.env.TAURI_PLATFORM == 'windows' ? 'edge108' : ['es2021', 'safari14'],
+	// By default, Vite inlines assets smaller than 4 KiB as base64 (see https://vitejs.dev/config/build-options.html#build-assetsinlinelimit).
+	// These assets are blocked by the CSP in production builds, so inlining is explicitly disabled.
+	assetsInlineLimit: 0
},

I would say that my experience with Tauri and SvelteKit has been positive. For the most part, it *just works*. There are just some small things to be aware of.

[acurrieclark]

If you have a single route (not single page) application, I would suggest that the most straightforward option would be to use Svelte by itself.

If you need routing, SvelteKit seems like the obvious choice. There are 3rd party routers available (and have been for a long time) but SPA mode is supported in SvelteKit with very few configuration changes.

As it is supported by Svelte itself, it makes sense to me to go with SvelteKit in this case. That is what I have done for my current Tauri project.

[lorenzolewis]

Thanks for all of the insights! @FabianLars @probablykasper and I have been doing some research into this. Putting our notes so far below:

Recommended Setup (SPA)

Starting out with SPA mode by using adapter-static and setting index.html as the fallback (this is important to make it go into SPA mode).

Advanced Setup (SSG with prerendering)

Once you know your way around SvelteKit you can start enabling prerendering to improve First Contentful/Meaningful Paint metrics. This can be applied per route or globally if set in the root +layout.js file.

Considerations

• Recommend not using server routes (+server.js, +page.server.js, +layout.server.js files)
  • More information about prerendering for server routes: https://kit.svelte.dev/docs/page-options#prerender-prerendering-server-routes
  • Always test it in tauri build to make sure it works at runtime
• If using [slug] routing be sure to read https://kit.svelte.dev/docs/page-options#prerender-when-not-to-prerender to understand the limitations
• CSP: We're still exploring this. Currently we're recommending to use either the frontend's CSP or Tauri's. We're researching into if they cause conflicts with each other. @astral4 feel free to join in and add your insight here if you'd like!

[Cobular]

I've used Sveltekit for ~10 projects and used it with Tauri for 2 or 3, I think it works pretty well! The pair is currently my favorite way to make any desktop application and I can't wait for the rest of mobile support to be ready so I can stop making PWAs for my mobile needs!

Sveltekit has first class support for ssg as others have mentioned, however it is not quite as great an experience as the other modes, especially when it comes to form submission and the like. Most benefits of SSR over SSG really do go away significantly when in an application context like this, the bundle is served off disk and so the loading time is negligable, plus the application itself routinely takes 10 or more times longer to start up than the page takes to load, so this is not the end of the world. However, the UX would still be a good 20% better if we had SSR in Tauri!

I believe the next best step forward would be a Sveltekit adapter for Tauri - one that gives Tauri first class support running the SSR code in the core process or something and serving the rendered files in such a way that developers can keep the full Sveltekit feature suite with no compromises.

Sveltekit and Tauri already share a number of goals with regard to performance and bundle size, and I'd love it if they worked together even better!

[dummdidumm]

If you're using SvelteKit's form actions (e.g. having a +page.server.js with a export const actions = .. in it) then you need a server runtime which can execute that JavaScript. AFAIK that's not something that Tauri offers, which is why you can't use this feature. IMO this is not a drawback of using SvelteKit but rather a general limitation - you can use the other features of SvelteKit just fine. In the context of form interactions it means you'd have to resort to other backend interaction solutions (intercepting the form post request, sending a JSON request to your API and work with the result).

[Cobular]

+1 to what @dummdidumm just said - I believe that's correct? On that note, an adapter that moves these form action handlers, or maybe the whole concept of serverside JS, into Tauri commands might be really cool! It might also be too much of a special platform feature to add for just one framework, but with some hacking it might just work since the server files have a very limited set of valid exports.

I do think the adapter-static thing would be great, and it would be even better if we could get into the adapter-auto list! Iirc, that won't auto switch to static if it's in an unknown environment so we might need explicit support. Regardless, either or both of these would be great!

Regarding other features, there's not a ton else that I can think of right now that's missing. Pretty sure load functions can work on either environment and they're the main other data loading system. Anything that could be done with the sveltekit API capabilities really just shouldn't be done that way in a Tauri environment and should be either a real API or a rust command.

I'm really slammed with work for the rest of the week but I'll dig through some of my projects and see if there's anything else I can see that would be hard to implement this weekend, there might be something I'm missing!

[ghost]

@lorenzolewis sorry for barging in into the conversation but I think I have a case where SSG is not an option -- SvelteKit apps with API enpoints. A specific case I've stumbled upon is authenticating users via Google OAuth. I have endpoints that are called from the client side, do the necessary operation (e.g., authenticate the user) and return the result back to the client. Requests like these cannot be sent from the client side.

I might be missing something here so please let me know if I'm wrong about this!

[FabianLars]

Nah you're not missing anything. API routes only work in SSR mode and therefore probablyyy will never (officially) work in Tauri. Thanks for the feedback btw!!

[ghost]

@FabianLars I see... That's a bummer but thanks for the response anyway! I think I'll re-implement the backend logic in Rust and invoke it from the frontend. Time to learn Rust I guess!

[austenc]

Chiming in here about something that doesn't work.

Using SvelteKit and have a store that is using Tauri's fs module to persist some data to a json file. I wanted to make this data globally available via a Load Function in the layout.ts file, but it doesn't work as you'd expect. Gives a window is not defined error. Assuming this is because the SSR render features are turned off?

If I use a load function that doesn't use the tauri fs module it works fine.

Happy to expand or provide code, but it's one limitation of SvelteKit + Tauri I ran into today and wanted to share in case it's helpful. Thank you!

[probablykasper]

You'll need to disable SSR. window is not defined means the code is running in Node.js, where there's no window

[austenc]

I have export const ssr = false in the src/routes/layout.ts file, shouldn't that disable it?
Normal stores work fine, but creating a custom store that uses things like exists, and writeFile doesn't seem to.

The custom store works in components, just not a layout-level Svelte load function for some reason. An example of the modules I tried to use:

import { exists, createDir, writeFile, BaseDirectory, readTextFile } from '@tauri-apps/api/fs'

If this is something that should work (the load functions, specifically) I am happy to make an example repo so that folks who know more than me can take a look at a reproduction. It's certainly possible I'm doing something wrong!

Thank you!

[probablykasper]

You forgot a + in the filename, it should be +layout.ts

[Merovex]

My experience in two words: Thank You! Deep and heartfelt. This scratches an itch I've had for decades.

Mind if I share my success story to date?

I was a developer when I was young, and the world was new. I stuck to web development because GUI was a PITA in Perl or other languages, and I've never been one for systems languages. There have been a few things I wanted to GUI (side projects), but Electron was bloated, and with rusty developer skills learning React or Vue was a non-starter. I did not have time to learn Rust in depth. But I knew Tauri + SvelteKit (T+SK) had promise. I tried with T+SK a while back, but it's hard to pour knowledge into a rock.

I write / publish SciFi (side gig), and I enjoy journaling my progress (word counts, mood). My editor keeps the daily wordcount history for me, so I've had scripts that updated my merged journal and created a contribution map (like GHs). Other authors have asked me for my app, but I couldn't get it into their hands.

Enter T+SK, attempt two (electric boogaloo). I used GPT 4 to bridge my knowledge gap. It taught me how to properly configure the Menu, message between the two layers, and debug functions I wrote in Rust. The Dev version ran fine. I ran into problems with the Prod mode (404 error). I went back to the S+TK Getting Started. Well documented, even for a guy like me who hates RTFM. I found my problem (I had ./ instead of ../). I have fallen in love with SvelteKit, and am falling in love with Rust. Now for me to go through my laundry list.

I could have benefited from some better code examples. GPT4 was current enough to get me close enough, so I could get the rest of the way there:

• Menu creation, with Accelerators (I don't think I found this in the documentation, I had to go to source code).
• How to use the application title on the menu (in Windows), still don't know how.
• The message process b/w Tauri + Svelte (how a menu selection can trigger routing to a new page).

[bjmc]

Trying to follow the quickstart guide here and I've completed all the steps (perhaps incorrectly?) but cargo tauri dev gives this error:

$ cargo tauri dev
     Running BeforeDevCommand (`yarn run dev`)
yarn run v1.22.5
error Couldn't find a package.json file in "/home/bjmc/Sandbox/mytauriproject"
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
       Error The "beforeDevCommand" terminated with a non-zero status code

I'm guessing it's because yarn create svelte has created the sveltekit project in a subdirectory, rather than in the project root. My folder structure looks like:

./svelte/
./src-tauri/

I'm sure this is a simple glitch with an easy fix, but this is my first experience with Tauri and it's disappointing that the steps in the docs don't appear to produce a working Hello World app in my case.

[ghostdevv]

You'll need to run the tauri init command inside the folder create-svelte generates (from this I assume it's your svelte folder)

[FabianLars]

^this and also both npm install commands should happen in that svelte dir

[bjmc]

Thanks @ghostdevv and @FabianLars - that makes perfect sense. I'm not sure how to best concisely capture this in the docs (maybe just an instruction to cd into the freshly-created project folder?), but it would help to clarify that the intended result is a root directory containing a Svelte project, and then the src-tauri/ folder lives inside that.

[FabianLars]

I'm not sure either, that's why there's nothing 😂 Some guides actually have a cd instruction but it's so easy to miss it barely makes a difference as far as i can tell.

[Stijn-B]

I made a reusable template back when I was looking into this as well https://github.com/auros-one/tauri-sveltekit

Got to the same conclusions as @lorenzolewis' #6423 (comment) except I didn't come in contact with CSP as I use it for a 100% local / offline app.

Happy to collab on a PR if there's anything missing from the tauri-sveltekit template for your usecase

[fev4]

Hi there! We're building a PWA with SvelteKit and have been looking into Tauri as possible future step to be able to improve our distribution.

I had a couple of questions that maybe someone in the community can help us with. But first, some context, our app is meant to run offline and heavily depends on service workers and indexeddb (via Dexie.js). The service worker will always start from the app root, which is located in /app. We also plan to have a bunch of marketing pages that don't really matter for the potential desktop or mobile apps, like the home page or the /blog.

In this sense, the questions we have are:

• Is it possible to select only the /app route and everything underneath as the target to be compiled as either desktop and/or mobile apps?
• Can we continue to use our service worker and indexeddb or do we need to handle this differently moving forward if we wanna use Tauri?

Any help or comment is greatly appreciated!

[probablykasper]

Determining what files are necessary for /app isn't possible for Tauri, so it comes down to SvelteKit:

• If you prerender /blog, you could try using entries . I can't find any better way to conditionally render routes
• It you want /app to be serves as the root, that can be done using reroute
• There might be a way to have a separate SvelteKit project for /app and embed that in your app
• Building multiple permutations of bundle sveltejs/kit#9407 could be helpful if that got implemented

You can use service workers with tauri-plugin-localhost, but the ideal way is usually to store data locally instead.