I spend a considerable portion of my day copying and pasting things. Code snippets, URLs, notes, random text I find online. Like many people, I copy something, then immediately lose what I had copied before forever. This frustration kept happening all the time, so I decided to fix this.

So I started building!

The Problem I Was Trying to Solve

Every Mac user knows this pain. You copy something important, then copy something else, and the first thing is gone forever and it will be time consuming to get it back.

I tried other clipboard managers, but they either seem too complicated or too simple. Some had dozens of features I never used. Others looked like they were built in 2005. I wanted something that looks simple and not-disturbing while being packed with useful features under the scenes.

What ClipBolt Does

ClipBolt saves everything you copy automatically. When you need something back, you press a keyboard shortcut of your choice and see your clipboard history directly. Click what you want, it will paste directly, and the app will auto disappear.

But I added a few things that make it more useful:

• Smart Organization: Instead of just showing a long list, ClipBolt groups similar items together by using AI auto-tagging.
• AI Features: Sometimes you copy text that’s too long or complicated. ClipBolt can make it shorter or rewrite it in simpler words. It can also read text from images you copy using OCR. Translate text you copied. Describe images or visuals you don’t totally get. And all of those are un-disturbing, they are only there when you need them.
• Search Everything: Type a few letters and find what you’re looking for instantly, even if you copied it days ago.

Why I Chose Mac Only

Mac is my OS of choice, and I know well what Mac users expect. They care about design and simplicity. They want apps that don’t get in the way. Instead of trying to build for everyone, I focused on building something that feels natural on macOS.

The Technical Side

Building ClipBolt taught me a lot about macOS development. The hardest part was making it fast. When you press the keyboard shortcut, the app needs to appear instantly. No waiting, no loading screens.

One thing I needed to figure out is handling different types of content. Text is easy, but images, and formatted content needed more effort.

The feedback I got

The early feedback has been encouraging. They like that it’s simplicity and clean interface. One said they like how it doesn’t feel overwhelming but have everything they needed. Other liked the extra features backed-in.

A few developers mentioned they love how it handles code snippets. It keeps formatting and makes it easy to find old code they copied.

Where It’s Going

Right now, I’m working on publishing ClipBolt so it enters the Beta phase. I’m working with early users to fix bugs and add features they actually want.

If you’re interested, you can join the waitlist to get notified when it’s ready. I would strongly encourage joining the waitlist because I will know someone else care about it. Early subscribers will get lifetime free access to ClipBolt, even when it turns into a paid product.

Sometimes the best products come from solving your own problems. That’s what ClipBolt is for me.

Thanks for reading

In this part of the series, we will deploy a static version of our SvelteKit app to AWS S3 and serve it via AWS CloudFront. We will use SST for this purpose, which is a tool that significantly simplifies the deployment process for us. Let’s get started

What is SST

SST is a tool built around AWS services that aims to simplify the process of building and deploying web applications. This tool has been receiving a lot of attention lately, as developers have always been looking for ways to deploy their apps to AWS quickly and avoid the hassle of working with the AWS console.

One great thing about SST is the wide compatibility it offers, allowing to deploy a variety of services including APIs, serverless apps, and even static websites.

Before proceeding, make sure you have aws-cli installed and that you have logged in to your AWS account with a region of your choice, follow This guide on the AWS docs to set it up.

Using SST to deploy our static SvelteKit app

Let’s begin by checking out the static branch of our example app, that we built in Part 2 of the series.

cd deployed-sveltekit-app
git checkout static

Make sure you have your npm dependencies installed:

pnpm install

And let’s build the project to generate a build directory, which we will deploy later on:

pnpm build

Now create an SST project within the app root directory:

pnpx create-sst@latest

When you run this command, it will prompt you with the following:

You are in a Svelte project so SST will be setup in drop-in mode. Continue? (Y/n):

This will setup an SST project within our SvelteKit app, agree by pressing the key Y.

Once you execute the command, you will notice that it makes some changes to your project files. Let’s examine the file sst.config.ts in the root directory:

import type { SSTConfig } from 'sst';
import { SvelteKitSite } from 'sst/constructs';

export default {
	config(_input) {
		return {
			name: 'deployed-sveltekit-app',
			region: 'us-east-1'
		};
	},
	stacks(app) {
		app.stack(function Site({ stack }) {
			const site = new SvelteKitSite(stack, 'site');
			stack.addOutputs({
				url: site.url
			});
		});
	}
} satisfies SSTConfig;

This file contains the code which will instruct SST to deploy your app to AWS, and being Typesafe is a blessing for developers like us!

The domain ssr/constructs has contains a set of functions that execute templates to be deployed using AWS CloudFormation. When we ran the command, SST automatically detected that we are on a SvelteKit project and it imported the SvelteKitSite construct, this function is too useful for deploying full-stack SvelteKit applications, but we are building a static website, so we have a few things that we need to change.

Instead of using SvelteKitSite, let’s replace the import with StaticSite and specify the path to our built static site directory ./build. I have also replaced the app region (The region doesn’t matter that much for these apps, the CloudFront and S3 distributions will not use an AWS region, only CloudFormation will):

import type { SSTConfig } from 'sst';
import { StaticSite } from 'sst/constructs';

export default {
	config(_input) {
		return {
			name: 'deployed-sveltekit-app',
			region: 'us-east-2'
		};
	},
	stacks(app) {
		app.stack(function Site({ stack }) {
			const site = new StaticSite(stack, 'site', {
				path: './build'
			});
			stack.addOutputs({
				url: site.url
			});
		});
	}
} satisfies SSTConfig;

Another thing we need to do is to reset the changes made in svelte.config.js, at the time of writing this blog post, the changes made by SST do not work well with SvelteKit 2, also; we need the adapter-static, not the sst adapter:

git checkout svelte.config.js

Before committing deployment, we need to run the dev command at least once to init our SSR project:

pnpm dev

You will be prompted with this question to enter a name for your personal stage. A stage is an SST environment that allows you to dictate certain configs for dev, prod…etc. enter the name you would like to use and proceed.

When the command completes running, it will then run your dev server. Let’s test it to see that everything works as expected:

Great! Now that’s all what we have to do, kill the dev server or open a new terminal, and let’s deploy!

pnpm sst deploy --stage prod

Note that we have specified the prod stage for the deployment environment. SST will automatically create an S3 bucket and a CloudFront distribution, and those will be part of a new AWS CloudFormation stack. It organizes your project greatly that allows you to change or remove it with ease.

After the command finishes, you can find your app URL displayed in the console, resembling https://<id>.cloudfront.net. Head to that link and you will see your app deployed and working as you would like to!

If you head to your AWS console, you see SST has created some new stacks for us, what’s relevant here is the prod-deployed-sveltekit-app-Site which contains the S3 bucket and CloudFront distribution for our app.

We made the following changes here in the static-s3 branch, which is based on the static branch.

Adding custom domain to our SST App

With SST, we can set up a custom domain name for our app easily, whether it was inside or outside our AWS account.

We can do this by modifying sst.config.ts, adding customDomain property to the StaticSite configuration.

import type { SSTConfig } from 'sst';
import { StaticSite } from 'sst/constructs';

export default {
	config(_input) {
		return {
			name: 'deployed-sveltekit-app',
			region: 'eu-west-1'
		};
	},
	stacks(app) {
		app.stack(function Site({ stack }) {
			const site = new StaticSite(stack, 'site', {
				path: './build',
				customDomain: 'deployed-sveltekit-app.com'
			});
			stack.addOutputs({
				url: site.url
			});
		});
	}
} satisfies SSTConfig;

If we pass this property alone, it will assume that we have created a new AWS Route53 hosted zone and purchased the domain name already.

Now if we run the deployment command again, it will modify our app accordingly.

pnpm sst deploy --stage prod

I’m not going to purchase that domain, so I’ll leave you here .

For further details on specifying external domains, see SST StaticSite Documentation.

That was a short post with great accomplishments! Thanks to SST for simplifying the process for us.

Useful Links:

• Mastering SvelteKit Deployment Part 1: Getting Started
• Mastering SvelteKit Deployment Part 2: Adapters, What Are They?
• Example App GitHub repo

In part 3, we deployed our SvelteKit app to Vercel. We have gotten into details that were abstracted from us to gain more knowledge. In this part, we will explore the worldwide popular Cloudflare platform. We will dive deep at a lower level, and it will be an enjoyable experience. Let’s get started!

What is Cloudflare

Cloudflare is an edge-powered distributed network that aims to serve secure and more performant web applications. It won the dignity in the web world as one of the biggest networks, serving millions of requests every second.

One of the well-known services offered by this platform is Cloudflare Workers, A Serverless solution that allows for deploying web applications across the edge, bringing them closer to the user for a significant improvement in loading speeds and availability. Its successor - Cloudflare Pages offers substantial support for static and dynamic web applications by integrating with different Cloudflare services in an automated way as needed.

In this blog post, we will deploy our app to CloudFlare Pages and empower it to offer ISR support which will allow us to experience the lower level Cloudflare Workers service. In the end we will deploy a pure static version of our website to CloudFlare Pages. Prepare your coffee, and bear with me

Cloudflare Edge Network

Cloudflare has hundreds of Data Centers on the world for serving web applications (services) deployed to their platform using the Serverless architecture, and by running every service on every data center, any user vising you website will receive a response from the closest location, which significantly reduces the latency and make your web app experience feel faster. We know this as the Cloudflare Edge Network and it’s one of the biggest reasons to deploy your web app to Cloudflare.

Cloudflare Workers

When you heard the word Serverless, your thought may be that it will be slow, that’s because we have always been told that the Serverless architecture spans up containers that take seconds to load on the first visit, known as “cold starts”. Cloudflare Workers solved this problem using their Isolates technology. In short, Isolates are lightweight nodes running over the edge using V8 engine, being tiny and efficient minimizes the cold starts down to 5 milliseconds or fewer (It’s technically zero, see the notes below).

In Part 3 we have mentioned Vercel’s Edge Runtime feature, they are doing the same thing as Cloudflare Isolates technology but with different branding.

Cloudflare has even gotten this to the next level by starting up the isolate as soon as the TLS handshake process starts its execution. By doing this, they were able to minimize the startup time down to 0 milliseconds! For more details, see this article on Cloudflare blog.

Cloudflare CDN

It’s likely that your website has static assets such as images, videos, markdown files…etc. For SvelteKit, you would often add your static assets to the static directory. Accessing those files from your server URL is easy to do. For example, we could access our favicon using [APP_URL]/favicon.ico.

Those files are in your server, nowhere else. Now imagine a lot of users requesting those static assets from your server. This is a lot of traffic that can exhaust the server and increase latency. In addition, your server exists in one location, the more the distance between your user and the server, the greater the latency, thus your website will feel slower. Let’s say, for example, we have a server in Frankfurt and a user visiting it from Japan. We don’t want this huge trip to load our assets. What’s the solution?

Use a Cloud Delivery Platform - CDN! It’s a layer between your server and the users. A CDN will distribute your static assets all over the globe, and some CDNs will also cache your assets for you. Cloudflare CDN is one of those services, which is identified as a CDN Cache - It performs content distribution & Caching, minimizing loading time and speeding up your assets delivery.

Deploying to Cloudflare pages

Pages is the fastest way to deploy your web app to Cloudflare. It offers an automated Git integration that connects to your repo with auto-deployment and previews URL support. The great thing about this service is that it auto-configures everything you need for you on your behalf, you will get your app deployed to Cloudflare’s Edge Network, it will also cache and distribute your static assets on Cloudflare CDN.

Pages support both static websites and dynamic apps, and the latter is done by an automated integration with Cloudflare Workers. This section will use adapter-cloudflare, which adapts your SvelteKit app to Cloudflare Functions API . This adapter is suitable for the whole dynamic version of our example app. We will cover the static version in a later part of this article.

If you have already forked the example app repo, checkout the cloudflare branch

Let’s begin by installing the adapter:

pnpm i  -D  @sveltejs/adapter-cloudflare

Then update svelte.config.js:

import adapter from '@sveltejs/adapter-cloudflare';
import { vitePreprocess } from '@sveltejs/kit/vite';

/** @type {import('@sveltejs/kit').Config} */

const config = {
	preprocess: vitePreprocess(),
	kit: {
		adapter: adapter()
	}
};

export default config;

Let’s have some fun and explore the build output of this adapter:

pnpm build

Expand the content of the .svelte-kit/cloudflare directory. And you will notice a file tree similar to the following:

.svelte-kit/cloudflare

├── 404.html
├── _app
│ ├──  immutable
│ │  ├──  assets
│ │  │  └──  *.css
│ │  ├──  chunks
│ │  │  └──  *.js
│ │  ├──  entry
│ │  │  └──  *.js
│ │  └──  nodes
│ │  └──  *.js
│ └──  version.json
├── _headers
├── _routes.json
├── _worker.js
├── _worker.js.map
├── favicon.png
├── ssg
│ └──  __data.json
└── ssg.html

• The _app/immutable directory contains your compiled Vite output. Your browser will cache those for you because of the specified cache header by Vite. Don’t worry, the files are fingerprinted for you!

• assets contain your static assets served by Vite. This differs from files inside the static directory (which SvelteKit doesn’t expose a Cache-Control header for).

• chunks contain your compiled Svelte components separated into chunks.

• nodes handle the server-side rendering of your app. It imports the files from the chunks directory to render in the server.

• entry has the files that start up your web app, as the name shows, the entry point of your app, which imports files from assets and nodes and chunks to get your app running on both client and server-side.

• The headers file contains headers for the _app directory. It exposes a Cache-Control of 31536000 seconds or 1 year to be cached locally in the browser. Note that with Cloudflare, we have both browser and CDN caching. The CDN is distributed over Cloudflare’s edge network, so you get your app’s maximum network performance boost.

• The _routes.json and _worker.* are Cloudflare-specific files following the (Cloudflare functions routing API) which are all part of Cloudflare workers API, that’s right! With dynamic applications like our app, Cloudflare Pages will integrate with Cloudflare Workers offering SSR support.

• The rest of the files are our static assets and static data. We have explained those in Part 2 of the series.

Now, let’s see that working in action and deploy our app to Cloudflare. Sign up to Cloudflare, verify your email, and head to the Dashboard. In the sidebar navigation, choose Workers & Pages. click the Pages tab and click on Connect to Git, and choose our example app repo. Once Cloudflare redirects you back, you need to enter the project name, select cloudflare branch,  select SvelteKit for the framework preset, and set the build command to pnpm build.

We also need to add the Environment Variables for our app, copy them from the .env file in our example app repo, then finally click Save and Deploy

And we get our app deployed

We see our example web app is working well. The ISR page, however, wasn’t working as expected, it behaves completely as an SSR page. That’s because, unlike Vercel, the Cloudflare adapter does not offer ISR support out of the box, and the page specific config option will be ignored.

Adding ISR support to CloudFlare adapter

In Part 3 of the series, we explored the Incremental Static Generation and how well Vercel supports it. CloudFlare, however, doesn’t support this option out of the box, but it turned out that we could easily achieve it.

What is ISR?

ISR (or Incremental Static Regeneration) allows your deployed web page to be static with the ability to regenerate it in an interval of your choice.

Let’s give an example with and without ISR:

say you have a blog page that fetches your content from a headless CMS. You want your blog loaded as fast as possible, so deploying it as a static page is your best option for maximum performance.

Without ISR

You add the export const prerender = true to your page. This way, it will be generated at build time, but that’s the end. Even if you update your content, the load function will never rerun unless you redeploy your app, so your website will be outdated.

With ISR

With ISR, instead of pre-rendering your page at built time, you generate the static page on demand as soon as it’s visited. The first visit to your webpage will use SSR, and the result of the load function will be globally saved for a specified interval. Once the interval has expired, it will automatically regenerate on the next visit.

Don’t mislead ISR with browser Caching headers. Those will cache the page on the user’s browser for a specified amount of time upon the first visit. ISR caches them globally for all users for a specified period.

Unlike pure static websites, ISR requires a server in order to work. So you must not prerender the web page where you intend to use ISR on.

How to achieve ISR on Cloudflare

At the time of writing this post, there is no adapter that offers ISR support for SvelteKit, so we are going to write our own on the same project!

We can use Cloudflare KV. key value store to cache ISR pages on our example app. The great thing about KV is that you can store everything you need on it, including page content! And we can specify an expiration date for each key/value pair, which we will set to be the same as the ISR page expiration property.

You can see the result of our work in this section in the cloudflare-isr branch, which we are going to deploy at the end of the section.

Let’s begin by removing the cloudflare adapter:

pnpm remove @sveltejs/adapter-cloudflare

Next, create a directory inside the root of the project. Let’s call it cloudflare. We are going to have 2 files in this directory:

• index.js: Iterates through your SvelteKit’s routes and build an output file for each, respecting the configs passed to the adapter. In addition, this file outputs a manifest file containing deployment variables/configs for Cloudflare to read.

• files/worker.js: Cloudflare specific file for our deployed app, as the name hints, it follows Cloudflare Workers Runtime APIs, which is internally used by Cloudflare Pages under the scenes.

mkdir cloudflare

Code in this section are originally taken from the official Cloudflare Adapter sub-repo of SvelteKit GitHub repository.

cd cloudflare
touch index.js
mkdir files
touch files/worker.js

Paste this code on the file index.js:

import { writeFileSync } from 'node:fs';
import * as path from 'node:path';
import { fileURLToPath } from 'node:url';
import * as esbuild from 'esbuild';

/** @type {import('./index.js').default} */

export default function (defaults = {}) {
	return {
		name: '@sveltejs/adapter-cloudflare',
		async adapt(builder) {
			const files = fileURLToPath(new URL('./files', import.meta.url).href);

			const dest = builder.getBuildDirectory('cloudflare');
			const tmp = builder.getBuildDirectory('cloudflare-tmp');
			builder.rimraf(dest);
			builder.rimraf(tmp);
			builder.mkdirp(tmp); // generate 404.html first which can then be overridden by prerendering, if the user defined such a page
			await builder.generateFallback(path.join(dest, '404.html'));
			const dest_dir = `${dest}${builder.config.kit.paths.base}`;
			const written_files = builder.writeClient(dest_dir);
			builder.writePrerendered(dest_dir);
			const relativePath = path.posix.relative(tmp, builder.getServerDirectory());

			const isr = [];
			for (const route of builder.routes) {
				const config = { ...defaults, ...route.config }; // Add pages with isr config to the isr array, to be exported later.

				if (config.isr) {
					isr.push({
						pathname: route.id,
						expiration: config.isr.expiration
					});
				}
			}

			writeFileSync(
				`${tmp}/manifest.js`,
				`export const manifest = ${builder.generateManifest({ relativePath })};\n\n` +
					`export const prerendered = new Set(${JSON.stringify(builder.prerendered.paths)});\n` +
					`export const isr = ${JSON.stringify(isr)};\n`
			);

			writeFileSync(
				`${dest}/_routes.json`,
				JSON.stringify(get_routes_json(builder, written_files, defaults.routes ?? {}), null, '\t')
			);

			writeFileSync(`${dest}/_headers`, generate_headers(builder.getAppPath()), { flag: 'a' });
			builder.copy(`${files}/worker.js`, `${tmp}/_worker.js`, {
				replace: {
					SERVER: `${relativePath}/index.js`,
					MANIFEST: './manifest.js'
				}
			});

			await esbuild.build({
				platform: 'browser',
				conditions: ['worker', 'browser'],
				sourcemap: 'linked',
				target: 'es2022',
				entryPoints: [`${tmp}/_worker.js`],
				outfile: `${dest}/_worker.js`,
				allowOverwrite: true,
				format: 'esm',
				bundle: true,
				loader: {
					'.wasm': 'copy'
				},
				external: ['cloudflare:*']
			});
		}
	};
}

/**
 * @param {import('@sveltejs/kit').Builder} builder
 * @param {string[]} assets
 * @param {import('./index.js').AdapterOptions['routes']} routes
 * @returns {import('./index.js').RoutesJSONSpec}
 */

function get_routes_json(builder, assets, { include = ['/*'], exclude = ['<all>'] }) {
	if (!Array.isArray(include) || !Array.isArray(exclude)) {
		throw new Error('routes.include and routes.exclude must be arrays');
	}

	if (include.length === 0) {
		throw new Error('routes.include must contain at least one route');
	}

	if (include.length > 100) {
		throw new Error('routes.include must contain 100 or fewer routes');
	}

	exclude = exclude

		.flatMap((rule) => (rule === '<all>' ? ['<build>', '<files>', '<prerendered>'] : rule))

		.flatMap((rule) => {
			if (rule === '<build>') {
				return `/${builder.getAppPath()}/*`;
			}

			if (rule === '<files>') {
				return assets
					.filter(
						(file) =>
							!(
								file.startsWith(`${builder.config.kit.appDir}/`) ||
								file === '_headers' ||
								file === '_redirects'
							)
					)
					.map((file) => `/${file}`);
			}

			if (rule === '<prerendered>') {
				const prerendered = [];

				for (const path of builder.prerendered.paths) {
					if (!builder.prerendered.redirects.has(path)) {
						prerendered.push(path);
					}
				}

				return prerendered;
			}

			return rule;
		});

	const excess = include.length + exclude.length - 100;

	if (excess > 0) {
		const message = `Function includes/excludes exceeds _routes.json limits (see https://developers.cloudflare.com/pages/platform/functions/routing/#limits). Dropping ${excess} exclude rules — this will cause unnecessary function invocations.`;

		builder.log.warn(message);
		exclude.length -= excess;
	}

	return {
		version: 1,
		description: 'Generated by @sveltejs/adapter-cloudflare',
		include,
		exclude
	};
}

/** @param {string} app_dir */

function generate_headers(app_dir) {
	return `

# === START AUTOGENERATED SVELTE IMMUTABLE HEADERS ===
/${app_dir}/*
  X-Robots-Tag: noindex
 Cache-Control: no-cache
/${app_dir}/immutable/*
  ! Cache-Control
 Cache-Control: public, immutable, max-age=31536000
# === END AUTOGENERATED SVELTE IMMUTABLE HEADERS ===
`.trimEnd();
}

This file builds and does the initial setup for our app using esbuild (which is used by vite internally). In this snippet, we also iterate through the app routes and save each isr page in the isr array, along with it’s expiration value. We export those values we obtained to the manifest file, which can be then imported using the MANIFEST alias.

The cloudflare specific work is done within files/workers.js, open that file in your code editor and paste this content:

import { Server } from 'SERVER';
import { manifest, prerendered, isr } from 'MANIFEST';
import * as Cache from 'worktop/cfw.cache';

const server = new Server(manifest);
const worker = {
	async fetch(req, env, context) {
		await server.init({ env }); // Initialize server with the environment
		// Check cache unless "no-cache" is requested

		if (req.headers.get('cache-control') !== 'no-cache') {
			const res = await Cache.lookup(req);

			if (res) return res;
		} // Get pathname from the request URL

		const { pathname: rawPathname } = new URL(req.url);

		const pathname = decodeURIComponent(rawPathname) || rawPathname;

		const key = `key_${pathname}`; // Attempt to serve from KV cache

		try {
			const cachedResponse = await env.kv.get(key);

			if (cachedResponse) {
				const cachedHeaders = new Headers({
					'Content-Type': 'text/html',

					'CF-Cache-Status': 'HIT'
				});

				return new Response(cachedResponse, { headers: cachedHeaders });
			}
		} catch (err) {
			// Skip if page is not in cache (we'll render and return the response below)
		} // Determine if the request is for a static asset or prerendered page

		const strippedPathname = pathname.replace(//$/, '');

		const isStaticAsset =
			manifest.assets.has(strippedPathname) ||
			manifest.assets.has(`${strippedPathname}/index.html`);

		const location = pathname.endsWith('/') ? strippedPathname : `${pathname}/`; // Serve assets, prerendered pages, or process dynamic requests

		let res;

		if (isStaticAsset || prerendered.has(pathname)) {
			res = await env.ASSETS.fetch(req);
		} else if (location && prerendered.has(location)) {
			res = new Response('', { status: 308, headers: { location } });
		} else {
			res = await server.respond(req, {
				platform: { env, context, caches, cf: req.cf },

				getClientAddress: () => req.headers.get('cf-connecting-ip')
			}); // If it's an isr page, Store in KV cache if the response is successful

			const isrPage = isr.find((page) => page.pathname === pathname || page.pathname === location);

			if (isrPage && res.ok) {
				const bodyText = await res.clone().text();

				await env.kv.put(key, bodyText, { expirationTtl: isrPage.expiration });
			}
		} // Utilize Cache API for eligible responses

		if (res.status < 400) {
			const cacheControl = res.headers.get('cache-control');

			if (cacheControl) {
				return Cache.save(req, res, context);
			}
		}

		return res;
	}
};

export default worker;

As explained, we store each ISR page inside Workers KV store and set the relevant expirationTtl value. You can access the Workers KV store using the env.kv variable.

In the Cloudflare interface, we are going to use our previously deployed app switching the branch to cloudflare-isr. To set the branch, go to the project page > Settings > Builds & Deployments >

Configure Production Deployments.

You need a KV name-space bound to your project environment, to create one, go to Workers & Pages, KV, and create your name-space, then head to your project page > Settings > Functions > KV name-space bindings, and select the name-space for both Production & Preview deployments, last, redeploy your app for the changes to take effect.

And finally, we got our ISR page working!

A downside of this approach is that our page will still behave like an SSR page in case of SPA, you can work around that by using a hard link for ISR page or disabling csr, though, I don’t see any need of that, ISR pages are usually done to increase speed and minimize traffic, but if your user have already loaded your website that won’t be needed most times and it won’t make that increased traffic you would worry about.

Deploy as a pure static website

Cloudflare Pages also offer support for a fully static website. If your website is purely static, you can use adapter-static and get your website deployed with no backend code execution. Note that in this case your website isn’t any different from any static asset, so it will automatically get distributed to Cloudflare CDN while being cached to your users.

Start by checking out the static branch, installing node dependencies and executing the build script:

git checkout static
pnpm install
pnpm build

adapter-static will generate a build directory generated for you, we explained the file architecture for this directory in Part 2 of the series.

Now all you have to do is push this code and deploy it using Cloudflare pages like we did in the previous part, except that we are going explicitly set the output directory to build and we will get our static website deployed

In closing

It was a long blog post. I hope you have enjoyed reading it as much as I’ve been enjoying writing this, in the next part we are going to deploy a pure static version of our website to AWS S3. See you then!

Useful Links:

• Mastering SvelteKit Deployment Part 1: Getting Started
• Mastering SvelteKit Deployment Part 2: Adapters, What Are They?
• Mastering SvelteKit Deployment Part 3: Deploying to Vercel
• Example App GitHub repo

In part 2 of the series, we demonstrated the concept of SvelteKit’s Adapters and experimented with adapter-node annd adapter-static.

From this part onwards, we will begin deploying our app to different platforms, with each step we will explain how the target platform works and what inputs it expects to get our app deployed.

For this blog post, our target deployment platform will be Vercel, known for its simplicity, customizability, and top-notch DevEx. We will start by explaining their deployment pipeline, serverless nature, supported runtimes, and static apps. Then, we will dive into using adapter-vercel and explain how it works behind the scenes. Finally, we will explore how to deploy our example app differently. Although this blog post may be longer than usual, I will try to simplify it as much as possible

What Is Vercel?

Vercel is a cloud-based platform that lets developers build and deploy their apps. They are known as the “Frontend Cloud”, meaning that, while they are a cloud-based product, they aim to simplify the process of building and shipping web applications for frontend developers, including a variety of features like hosting, storage, databases, caching, analytics, AI, and more.

They are also known as part of the open-source community. They own and fund frameworks like Next.js and SvelteKit. However, SvelteKit offers broader platform support and compatibility and isn’t taught to Vercel.

How Vercel Works?

Vercel platform is based upon the serverless architecture, empowered by AWS Lambda functions with Amazon Linux 2 runtime. Being serverless means you cannot run long background tasks or HTTP streaming* unless using an add-on like inngest.

*Although Vercel doesn’t natively support HTTP streaming, their team built a custom solution that makes this feature possible, which is done by triggering a bridged socket connection. It’s used by frameworks like Next.js and SvelteKit for their streaming support.

Continuous Integration with Git

Vercel recommends deploying to their platform via Git for additional features like Continuous Integration, previewing deployments before merging to the main branch, and live feedback. In this part of the series, we will set up automatic deployment with vercel and vercel-edge branches and set up a preview URL for each.

Vercel’s Supported Runtimes

When deploying your app on Vercel, it uses serverless functions. The runtime for these functions is supported in two different options.

• Serverless Runtime: This is the default and usual runtime. It fully supports different runtimes like Node.js, Go, Python, Ruby, etc. However, it’s slower due to its cold starts and may even be expensive in some cases.

• Edge Runtime: With this option, your functions will run faster with minimal cold starts, as it runs with lightweight resources and uses Web API Standards. Edge functions are deployed through Vercel’s Edge Network, which allows significantly faster response times as content becomes closer to users.

  It’s important to keep in mind that the Edge Runtime has some differences compared to Node.js. For example, it doesn’t support Node’s filesystem module.

For a more detailed comparison, check out Vercel’s Runtime Comparison article.

Content Caching

One thing that Vercel does so well is its caching system. Here’s an overview of its top features related to this topic:

• For static files, Vercel will automatically cache them on their CDN using Vercel’s Edge Network. This will be automatically applied to files under static directory, as well as your Vite’s compiled fingerprinted static assets.
• Vercel was the first platform to add Incremental Static Regeneration support, which allows regenerating static/prerendered pages based on time intervals.
• For pages with static and dynamic data, Vercel has a built-in granular cache known as Vercel Data Cache, though, at the time of writing, this feature is only available for Next.js (It does this by wrapping the global fetch function).

Note that caching for fiels under static directory is done by only using CDN caching, as the time of writing this blog post, SvelteKit does not expost cache control headers for those files, you will only get a boost from serving those files over Vercel’s Edge Network, but the browsers won’t cache them for you.

Page-Specific Adapter Configs

Before taking another look at our example app, let me mention that SvelteKit supports exporting page-specific configs, which are adapter-specific. For example, if we want to enable Incremental Static Regeneration for one of our static pages, in page.server.ts or page.ts, we can export a config object:

export config = {
	isr: {
		expiration: 15 // regenerate every 15 seconds
	}
}

This way, our static page will be rebuilt every 60 seconds. Note that page-specific configs are not supported for all adapters. It’s currently supported by adapter-vercel, which we will use in this part of the series.

A Closer Look at our Example App

To allow us to experiment with different features offered by multiple platforms, We have 5 pages with different rendering and caching strategies:

• /ssr: Displays a list of comments. This page is server-side rendered and allows posting new comments, which triggers a form server-action.
• /ssr-streaming: Another server-rendered page, but the content here is streamed using SvelteKit’s streaming feature. Comments here are delayed for 2 seconds. While loading, a UI loading skeleton is displayed.
• /ssg: This page exports prerender = true. The comments displayed on this page are generated at build time, so posting them on the SSR page won’t be displayed here.
• /isr: An SSG page that uses incremental static regeneration. It exports the isr config with an expiration interval of 15 seconds. As explained in the previous section, this awesome feature allows updating our static page so that newly posted comments are reflected in our static page.
• /cache-headers: A minimal page that displays the current time. What we are experimenting with here is the cache headers. This page exports a Cache-Control header with a max-age of 10 seconds. Unlike ISR, the page is cached within the browser, not our deployment platform.

Note: As mentioned in Part 1, we store and post our data to Supabase. The env file is shared in the GitHub repo, so you don’t have to worry about setting up your own. However, please remember to manually add them to the target platform when your app is deployed, as SvelteKit does not include them in your output.

Deploying our app to Vercel

In this section, we will set up automatic deployment using vercel and vercel-edge branches and set up a preview URL for each.

SvelteKit’s Vercel Adapter

To get your app deployed to Vercel, you must follow their file structure convention - Vercel’s build output API; However, @sveltejs/adapter-vercel package does this automatically for you.

We are going to use the adapter in our example app:

pnpm install @sveltejs/adapter-vercel

Modifying svelte.config.js to use the adapter:

import adapter from '@sveltejs/adapter-vercel';
import { vitePreprocess } from '@sveltejs/kit/vite';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: vitePreprocess(),

	kit: {
		adapter: adapter()
	}
};

export default config;

And finally, building our app while having the adapter configured:

pnpm build

Expand the content of the .vercel/output directory. You will see a file structure tree similar to the following:

├── config.json
├── functions
│   └── fn.func
│       ├── node_modules
│       │   ├── @supabase
│       │   ├── @sveltejs
│       └── package.json
└── static
    ├── _app
    │   ├── immutable
    ├── favicon.png
    ├── ssg
    │   └── __data.json
    ├── isr
    │   └── __data.json
    ├── isr.html
    └── ssg.html

This filesystem follows Vercel’s build output API, so deploying our app to Vercel will work naturally and as expected. Let’s have some highlights from the last tree snippet:

• The file config.json is the core of our deployed app. It has the following properties:
  • version: The versions of the build output API being used. By the time of writing this blog post, it is using version 3.
  • routes: A set of regex patterns and destinations for every route defined in our SvelteKit app. Routes could have a source and destination and contain the returned status code, headers, etc.
    • Note that the "/_app/immutable/.+ source, exports a cache control header of 31536000 seconds (1 year). We will explain this within the current section.
    • Note the /.*" source, which points at every route in our app. They all yield to a destination of /fn/, our serverless function. We will explain this here, too.
  • functions: The place where our serverless functions are stored. Note that the Vercel adapters has mapped all of our routes to one function. This lets us gain some advantages:
    • Reduce cold starts: When our app uses one serverless function, the cold starts will be drastically reduced, and the chance of it being warmed up will increase.
    • Reduce costs: More serverless functions mean more costs. Combining multiple endpoints within one is more cost-effective.
    • Better performance: The startup penalty is only paid once for all routes in our application.
  • static: The place where our static assets and statically generated data are stored:
    • _app/immutable: Contains static files that will likely never change. It has a set of compiled JavaScript and CSS files, that’s why they are cached for 1 year, but they are fingerprinted so that when you update those without worrying about caching.
  • files with ssg and isr contain the data and HTML templates for your statically generated pages.

Connecting our example app to GitHub

It’s highly recommended to deploy our app using Git. Vercel supports deployments using GitHub, Gitlab, and Bitbucket. In this blog post, we will use GitHub.

Using VSCode, you could do this with a few keystrokes: press ⌘+Shift+p (Mac) or Ctrl+Shift+p (Linux/Windows) and select Publish to GitHub.

Node Serverless runtime

We haven’t set any runtime options in our example app. In such case, Vercel will use the Serverless runtime by default. Let’s head over to Vercel and get our app deployed!

If you don’t have a Vercel account, create one. Adding a new project could be done by connecting your GitHub repo to Vercel. The rest will be automated for you!

Don’t forget to add the environment variables before deploying your app. All ends you need are included in the .env within the repo.

Note that the code for this section exists in the vercel branch. Please fork the example app repo and set it as your main branch before deployment. This is a limitation from Vercel. It will deploy your app initially using the main branch.

And finally, we get our app deployed!

Edge Network

In earlier sections of this blog post, we have explained what Vercel’s Edge Runtime is. Now let’s experiment with and and deploy our example app to the edge!

If you have already forked the example app repo, checkout the vercel-edge branch and set it as your main branch.

We are using the runtime: 'edge' option, which is completely supported by the Vercel adapter:

import adapter from '@sveltejs/adapter-vercel';
import { vitePreprocess } from '@sveltejs/kit/vite';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: vitePreprocess(),

	kit: {
		adapter: adapter({ runtime: 'edge' })
	}
};

export default config;

The isr page is not compatible with the edge runtime, so we will overwrite that behavior in a page specific config:

import { fetchComments } from "$lib/server/utils";
import type { PageServerLoad } from "./$types";

export const load: PageServerLoad = async () => {
	const comments = await fetchComments(fetch);

	return {
		comments
	}
};

export const config = {
	isr: {
		expiration: 15 // regenerate every 15 seconds
	},
	runtime: 'nodejs20.x' // Overwrite edge runtime
};

Note: Some well-known node modules are not supported in the edge-runtime are unsupported. For example, we cannot access the file system using the fs module like in Node. But this is not a problem with our app since we don’t use it. We use supabase as our database which have great support for the edge runtime.

Note that the code for this section exists in the vercel-edge branch.

Deployment Notes

• As you see, the ssr and ssr-streaming are the most dynamic, whenever they are visited, they will have the most updated content.
• The ssg page is the least dynamic, the data you see displayed present in an HTML file obtained at build time.
• The isr are well supported by SvelteKit. this page has the good parts of the two worlds, it is regenerated based on an interval of 15 seconds, but you are likely to add longer intervals in real world apps.
• As expected, the cahced-headers page is updated each 10 seconds, which is the effect of the cache control header, but this behavior is browser specific since it’s cached there to prevent the request from the first place, if you visit the page on another browser for the first time, you will get new fresh content.

Other options

Along with the mentioned runtime and isr options, adapter-vercel supports other options. Here are some to name a few:

• split: This option is set to false by default. If enabled, your SvelteKit loaders, actions, and API routes will be split across different serverless functions, but I wouldn’t recommend this unless there’s a specific thing you want to do.
• external: This option only applies to edge routes. It allows setting a list of optional dependencies which are not compatible with the edge runtime (Node-specific modules).
• There are other options like memory and maxDuration that you can pass, but it’s unlikely that you will need them. For more info, check out SvelteKit’s docs

You have reached the end of this blog post. Thank you so much for reading! Next, we will pick another platform. We will deploy our SvelteKit app to CloudFlare. See you!

Useful Links:

• Mastering SvelteKit Deployment Part 1: Getting Started
• Mastering SvelteKit Deployment Part 2: Adapters, What Are They?
• Mastering SvelteKit Deployment Part 4: Deploying to CloudFlare (Comin soon!)
• Example App GitHub repo

In Part 1, we have set up our example SvelteKit app, which we will deploy to multiple platforms throughout the series. Now, we will explore the concept of Adapters, their purpose, and how they internally work behind the scenes.

Building our SvelteKit App

To grasp the concept behind Adapters, we first need to study the output of compiling SvelteKit apps:

	cd deployed-sveltekit-app
	pnpm build

Running the Vite build command will output a .svelte-kit directory in the root of our project, which contains the following subdirectories:

	├── generated
	├── output
	└── types

Our focus is the output directory, but let’s give a quick summary for each:

• The gnerated directory is the first step in the build process, it has a fingerprinted hash for each build, and maps to our project to be used for generating the build output, it’s also used for watching changes for hot module replacements.
• Server type declaration files are stored in the types directory, which also outputs a JSON file which contains route-to-file mappings.
• We can say that the output directory is made from the penultimate step during the build process, it’s a set of JavaScript, HTML, and CSS files which is what every Svelte app is compiled to. It has both server code and client code, and contains a manifest file that export regex patterns for our app routes.

You can preview the build using the command pnpm preview or vite preview, but this command is not useful for deploying to deployment platforms, as they tend to be different from each other, they have different envs, runtimes, features, options, and many other differences that step in our way of deploying our SvelteKit app 🚶🏻

What Are Adapters?

We live in a world where we have a lot of different deployment platforms, in forms of serverful, serverless, static, and others. Deploying an app that works on a specific platform requires processing our output to follow their vendor-specific rules, which is a time consuming task. Adapters are available for us to automate all of this hard work, they add a build step for adapting our output to a target platform of choice.

Adapters are not taught to SvelteKit, other frameworks like Nuxt and Astro have technically the same concept that works in a similar pattern.

There are a lot of adapters available as ready-to-use packages, some examples are adapter-node, adapter-static, adapter-vercel, etc. You can even build your own if you don’t find what you are looking for.

The default Auto Adapter

SvelteKit comes out of the box with an adapter called adaptera-auto that determine which adapter to use by checking platform-specific environment variables, it installs and runs the one which it detects. Here’s a code snippet taken from SvelteKit’s GitHub repo:

export const adapters = [
	{
		name: 'Vercel',
		test: () => !!process.env.VERCEL,
		module: '@sveltejs/adapter-vercel',
		version: '2'
	},
	{
		name: 'Cloudflare Pages',
		test: () => !!process.env.CF_PAGES,
		module: '@sveltejs/adapter-cloudflare',
		version: '2'
	},
	{
		name: 'Netlify',
		test: () => !!process.env.NETLIFY,
		module: '@sveltejs/adapter-netlify',
		version: '2'
	},
	{
		name: 'Azure Static Web Apps',
		test: () => process.env.GITHUB_ACTION_REPOSITORY === 'Azure/static-web-apps-deploy',
		module: 'svelte-adapter-azure-swa',
		version: '0.13'
	},
	{
		name: 'AWS via SST',
		test: () => !!process.env.SST,
		module: 'svelte-kit-sst',
		version: '2'
	}
];

As noted, the adapter installs the detected target module. It doesn’t support all platforms and is too much abstracted, it even makes the build slower because it updates the packages lock-file outside of our repo, for those reasons, it’s highly recommended to use a specific adapter in the first place.

Exploring the Node Adapter

Let’s have an experiment with adapter-node and see the output it generates, we will explain deploying SvelteKit apps to node servers in a future part of the series. For now, our focus is to explain how Adapters work.

Let’s begin by installing the adapter to our example app:

pnpm install -D @sveltejs/adapter-vercel

If you haven’t already, open the example app in your favorite text editor:

code-insiders .

And let’s move to svelte.config.js and use the new adapter there:

import adapter from '@sveltejs/adapter-node'; # We have only changed this line
import { vitePreprocess } from '@sveltejs/kit/vite';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	// for more information about preprocessors
	preprocess: vitePreprocess(),

	kit: {
		adapter: adapter()
	}
};

export default config;

Let’s build our app again:

pnpm build

The command will output a .svelte-kit directory similar to the one before, but this time it’s going to feed it with the node adapter and generate a new build directory that contains our node app.

There are a set of options we can pass to the node adapter, we are going to explain those in a later part of the series, for now we will use the defaults that work well for us.

You can expand the build directory to explore it’s content, you won’t see any sign of Svelte there, it’s a Fullstack Node.js application that’s deployable out of the box! you can even run it:

➜ export ORIGIN=http://localhost:3000

➜ node build #runs buid/index.js

Listening on 0.0.0.0:3000

Why pass the ORIGIN env? Our app needs a way to know the base URL for server actions to work, otherwise we are going to get a 403 Forbidden response after each form submission.

Head over to http://localhost:3000 and you will see our app sitting there!

As you see, the app is dynamic! Having a node server allowed us to use awesome features like SSR and Streaming. In addition to that, with the power of SvelteKit we had the ability to add some static pages to the website!

Getting into Adapter-Static

Now we will move a step further and explain pure SSG outputs, which is generated by using adapter-static, our app will turn into a complete static website, which means it won’t have server code anymore, and all what you get will be HTML, CSS, and JavaScipt files. Taking this approach allows you to deploy your app to services specifically designed for static content, like Static Hosting Providers or Static-Only CDNs. This can significantly reduce your costs if you don’t require a server for your website.

Before we begin, I would like to quote some text with you, taken from the SvelteKit’s docs

The basic rule is this: for a page to be prerenderable, any two users hitting it directly must get the same content from the server.

We will follow this good rule in this section, the pages we will have are purely static without dynamic behavior, so we will get rid of any dynamic pages here, this is what adapter-static is meant for, pure static websites!

Let’s start with installing the adapter:

pnpm install @sveltejs/adapter-static

And as usual, modify svelte.config.js to use the newly installed adapter:

import adapter from '@sveltejs/adapter-static';
import { vitePreprocess } from '@sveltejs/kit/vite';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: vitePreprocess(),

	kit: {
		adapter: adapter()
	}
};

export default config;

Before building the app, there are few things we need to do:

• Go to +layout.server.ts and enable pre-rendering for your whole app

  import { fetchAvatar } from '$lib/utils';
  import type { ServerLoad } from '@sveltejs/kit';
  
  export const prerender = false;
  
  export const load: ServerLoad = async ({ fetch, cookies }) => {
  	const avatar = cookies.get('avatar') || (await fetchAvatar(fetch));
  
  	cookies.set('avatar', avatar);
  
  	return {
  		avatar
  	};
  };

• In order for the website to be purely static, runtime server code needs to be removed, in our case, we remove all API handlers and server actions. So we will remove the api/avatar, ssr, ssr-streaming routes.

• Remove the on:click handler on the AvatarButton component as it fetches from a removed route.

  <script lang="ts">
  	import { avatar } from './stores';
  	import { fetchAvatar } from './utils';
  
  	export let setAvatar = (value: string) => {
  		$avatar = value;
  	};
  
  	const generateAvatar = async () => {
  		const avatar = await fetchAvatar();
  		setAvatar(avatar);
  	};
  </script>
  
  <button on:click={generateAvatar}>
  	<img src={$avatar} alt="avatar" width={48} height={48} />
  </button>
  
  <style>
  		...
  </style>

• Lastly, we remove any links pointing to a removed routes, in such case, we remove links to ssr and ssr-streaming pages in +layout.svelte:

  <script lang="ts">
  	import type { PageData } from './$types';
  	import HeaderLink from '$lib/HeaderLink.svelte';
  	import AvatarButton from '$lib/AvatarButton.svelte';
  	import { avatar } from '$lib/stores';
  
  	export let data: PageData;
  
  	$avatar = data.avatar;
  </script>
  
  <svelte:head>
  	<title>Deployed SvelteKit app</title>
  	<meta name="description" content="Example app for Mastering SvelteKit deployment series" />
  </svelte:head>
  
  <header class="flex items-center justify-between p-4 bg-gray-100">
  	<nav>
  		<HeaderLink href="/">Home</HeaderLink>
  		<HeaderLink href="/ssr">SSR</HeaderLink>
  		<HeaderLink href="/ssg">SSG</HeaderLink>
  		<HeaderLink href="/ssr-streaming">Streaming</HeaderLink>
  		<HeaderLink href="/ssg">ISR</HeaderLink>
  		<HeaderLink href="/cache-headers">Cache Headers</HeaderLink>
  	</nav>
  
  	<AvatarButton />
  </header>
  
  <main>
  	{#key data}
  		<slot />
  	{/key}
  </main>
  
  <style>
  	...
  </style>

And we finally get to build our app:

	pnpm build

If you expand the content of the `build` directory, you will get a filesystem tree similar to the following:

	├── __data.json
	├── _app
	│ ├── immutable
	│ │ ├── assets
	│ │ │ ├── [..].css
	│ │ ├── chunks
	│ │ │ ├── [..].js
	│ │ ├── entry
	│ │ │ ├── [..].js
	│ │ └── nodes
	│ │ ├── [..].js
	├── cache-headers
	│ └── __data.json
	├── cache-headers.html
	├── favicon.png
	├── index.html
	├── ssg
	│ └── __data.json
	└── ssg.html

As you see, our whole app turned into a set of HTML, CSS, JavaScript, and few JSON files storing already fetched data. You can explore the content of each directory, no trace of a single Nodejs function!

But that’s too much, right? let’s talk details and dive into each directory:

• _app/immutable: Contains static files that are likely to never change, it has a set of compiled JavaScript and CSS files, that’s why they are cached for 1 year, but they are fingerprinted so that when you update those without worrying about caching.
• ssg: For each route in our app, we have a generated HTML file and data JSON. For the root route /, we have the index.html and data.json, and for each other route, we will have them as [route_name].html and `[route_name]/data.json`. Those JSON files are simply the data generated by each route load function (here we only have the SSG page). It’s the static data being generated once at build time.
• We will also have our static assets in the same directory, for example, the favicon or any other static file you have, but those won’t be fingerprinted, and currently, SvelteKit does not cache them for you.

Now you can run the build/index.html, or better, fire up a simple HTTP server from the build directory, and it will work just like any static website!

Note that the ISR page may remain as an SSR page, as of writing this blog post, only Vercel supports this feature.

I hope you grasped this foundational blog post. If not, feel free to read it again or simply move forward! See you in the next one which covers deploying our app to Vercel.

Useful Links:

• Mastering SvelteKit Deployment Part 1: Getting Started
• Mastering SvelteKit Deployment Part 3: Deploying to Vercel
• Example App GitHub repo

One of the great parts of SvelteKit is how it supports different platforms in terms of deployment. It’s built with Zero restrictions, and you can deploy it almost everywhere.

Throughout this series, we will dive into various cloud-hosting services and explore our options. One exciting part about this journey is the vast knowledge you will gain about deployment platforms and what makes them different.

Outline

We will break down the series into the following parts:

• Part 1: Getting Started
• Part 2: Adapters, What are they?
• Part 3: Deploying to Vercel
• Part 4: Deploying to Cloudflare
• Part 5: Deploying to AWS S3
• More to come, feel free to reach out for suggestions 🙂

When you decide to read a blog post on this series, I highly recommend applying what you learn. Doing so is the only way to learn and gain experience. You are free to skip parts as you see fit, but it would be best if you read Part 1 and Part 2

The Example app

We will use a sample app throughout this series, showcasing different features of SvelteKit. We will go through SSR, streaming, server actions, prerendering, ISR, Pure SSG, API handlers, and more. This app allows users to view and post comments and change their avatar image.

Go ahead and clone the GitHub repo, which contains the example app we’re going to deploy:

git clone

code deployed-sveltekit-app # Or use your favorite editor

We will be using Supabase for data storage. Setting up a supabase instance is pretty straightforward, but no worries! I made one for you. The public key is included within the repo 👀 - Remember it’s restricted. Feel free to set up your own for more freedom.

You will find that the file structure for the example app looks similar to the following:

.
├── src
│   ├── app.d.ts
│   ├── app.html
│   ├── index.test.ts
│   ├── lib
│   │   ...
│   └── routes
│       ├── +layout.server.ts
│       ├── +layout.svelte
│       ├── +page.svelte
│       ├── api
│       │   └── avatar
│       │       └── +server.ts
│       ├── cache-headers
│       │   ├── +page.server.ts
│       │   └── +page.svelte
│       ├── ssg
│       │   ├── +page.server.ts
│       │   └── +page.svelte
│       ├── isr
│       │   ├── +page.server.ts
│       │   └── +page.svelte
│       ├── ssr
│       │   ├── +page.server.ts
│       │   └── +page.svelte
│       └── ssr-streaming
│           ├── +page.server.ts
│           └── +page.svelte
├── static
│   └── favicon.png
├── svelte.config.js
├── tests
│   └── test.ts
├── tsconfig.json
├── vite.config.ts

Let’s break down our example app into the following parts:

• +layout.svelte: The root layout has a navigation bar and the current page’s content. The navbar has a button to change the user avatar to a random one by firing an AJAX request to the /api/avatar endpoint.
• +layout.server.ts: Contains a server load function that serves the root layout. It also fetches an initial user avatar, which is saved to a cookie — Note that the cookie on the load function won’t work for pre-rendered pages since the page is determined at build time.
• ssr:
  • +page.svelte: This page displays a list of comments that are server-side rendered. It also has a feature for the users to post new comments, which is done by a form server action.
  • +page.server.ts: Contains the server action for posting new user comments. For our example app, those are saved to Supabase.
• ssr-streaming:
  • +page.svelte: Same as the SSR page, The only difference is that it’s charged up with Streaming supprt. It will delay fetching unnecessary data to enhance the experience. Here we delay fetching comments by 2 seconds to simulate this behavior.
  • +page.server.ts: Similar to the SSR server load, the difference is that we make comments nested inside the object and omit the await, which allows us to stream the promise from the server.
• ssg:
  • +page.svelte: This page displays the same comments, but this time they are statically generated once at build time, it’s not dynamic data anymore, and this page doesn’t allow adding new comments.
  • +page.ts: Exports a prerender = true option to enable static generation for this page.
• ssg-sr:
  • +page.svelte: Same as SSG page, but here it’s charged up with Incremental Static Regeneration. It will keep running the load function to update comments at a specific fixed interval.
  • +page.ts: Exports a config object with the isr option, the expiration is set to 15 seconds. In real websites you would probably make it larger than this interval.
• cache-headers:
  • +page.svelte: A simple page that shows the current time in “HH:mm:ss” format. What’s interesting here is that this page is served with a cache header.
  • +page.server.ts: Exports the current time with a Cache-Control header of max-age=10, which means that the time will be cached for 10 seconds.
• /api/avatar: A GET request handler that generates a random avatar. It first generates a set of colors using the Node crypto API, then use those to return an imageSrc that points to the boringAvatars API.

As you see, we have integrated many features to experiment with. Note that not every feature will work on every platform, especially the server functions, which are not supported by static-only deployment platforms. We will dig deeper into this in the next parts.

As we explore different deployment options, the example app may be modified. Each modified version will be in a separate branch based on the original example app, which is in the main branch.

That’s all for the first part. In Part 2, we will explain the concepts of adapters like never before! exciting things ahead! See you in the next one.

A few days ago, SvelteKit version 1.24.0 dropped with the new onNavigate lifecycle function, to support the Web View Transitions API, which is a modern CSS-friendly way to handle page transitions.

This blog post will cover the basics of setting up an example, which I published on this GitHub repo.

We will be creating a Pokemon dashboard app with a minimalist design, the app will have two pages. The first page shows the user info with a Pokemon image, and the second page allows editing the user info and the Pokemon ID, which is used for retrieving the image. Moving between pages will show scale-in-out transition effect. Let’s get started!

Create a new SvelteKit app using pnpm, or whatever package manager you prefer.

pnpm create svelte@latest page-transitions

This will create a new directory in your file system, let’s go there and install the packages we need:

cd page-transitions
pnpm install
pnpm install -D unocss @iconify-json/mdi

code . # Open the project using your favorite text editor

UnoCSS is an Atomic CSS library similar to TailwindCSS, but much easier to set up. It includes ready-to-go presets that we can directly use.

Let’s head into vite.config.ts and add UnoCSS plugin:

import { sveltekit } from '@sveltejs/kit/vite';
import UnoCSS from 'unocss/vite';
import { defineConfig } from 'vite';

export default defineConfig({
	plugins: [sveltekit(), UnoCSS()]
});

Create a uno.config.ts file in the root directory:

import { defineConfig, presetUno, presetIcons, presetWebFonts } from 'unocss';

export default defineConfig({
	presets: [
		presetUno(),
		presetIcons({
			collections: {
				mdi: () => import('@iconify-json/mdi/icons.json').then((i) => i.default)
			}
		}),
		presetWebFonts({
			provider: 'google',
			fonts: {
				sans: {
					name: 'Roboto',
					weights: [400, 500]
				}
			}
		})
	]
});

UnoCSS is powered using presets, we are using the following official presets which are included in the main package:

• presetUno: Allows us to use TailwindCSS classes in our project, this preset is also compatible with windiCSS classes.
• presetIcons: This preset is an awesome simple way to add icons using CSS classes, we will be using @iconify-json/mdi package for material design icons, only the icons we use will be added to our output bundle, nothing more
• presetWebFonts: For adding web fonts into our project. We will be using Roboto google font.

We have created our project and set it up, let’s move to the page transitions implementation.

Create a parent layout file in your route directory: routes/+layout.svelte and add the following code:

<script lang="ts">
	import 'virtual:uno.css';

	import { onNavigate } from '$app/navigation';
	import HeaderItem from '$lib/HeaderItem.svelte';

	onNavigate(() => {
		// check browser compatibility
		if (!document.startViewTransition) return;

		return new Promise((fulfil) => {
			/* This will take a screenshot of the whole page, and freeze
					until the animation promise resolves */
			document.startViewTransition(() => new Promise(fulfil));
		});
	});
</script>

<div class="h-screen flex flex-col font-sans font-medium text-white">
	<header>
		<nav class="flex justify-center gap-4 bg-sky p-2.5">
			<HeaderItem href="/">
				<i class="i-mdi-view-dashboard w-6 h-6" />
				<span>Dashboard</span>
			</HeaderItem>
			<HeaderItem href="/edit">
				<i class="i-mdi-account w-6 h-6" />
				<span>Edit Profile</span>
			</HeaderItem>
		</nav>
	</header>

	<div class="flex flex-col flex-grow min-h-0 content">
		<slot />
	</div>
</div>

<style>
	/* For animating the inner content only, without the nav-bar,
     we assign a unique transition name */
	.content {
		view-transition-name: content;
	}

	/* Set transition origin for old and new snapshots of the inner page */
	:root::view-transition-old(content),
	:root::view-transition-new(content) {
		transform-origin: center;
	}

	/* Animate the old snapshot out */
	:root::view-transition-old(content) {
		animation: 1s ease-in-out both scale-out-slide-left;
	}

	/* Animate the new snapshot in */
	:root::view-transition-new(content) {
		animation: 1s ease-in-out both slide-left-scale-in 0.5s;
	}

	/* Define the animations */
	@keyframes scale-out-slide-left {
		0% {
			transform: scale(1) translateX(0);
		}

		50% {
			transform: scale(0.8) translateX(0);
		}

		100% {
			transform: scale(0.8) translateX(-150vw);
		}
	}

	@keyframes slide-left-scale-in {
		0% {
			transform: scale(0.8) translateX(150vw);
		}

		50% {
			transform: scale(0.8) translateX(0);
		}

		100% {
			transform: scale(1) translateX(0);
		}
	}
</style>

This parent layout is the place where page transitions happens:

1. We begin by importing virtual:uno.css, this file is available after build time, which will serve as our Atomic CSS file for the styling to take effect.
2. The onNavigate lifecycle function is the core part, it’s the place where all the magic happens, we first check browser compatibility. The document.startViewTransition is an asynchronous function that fires a callback as soon as the animation is done playing. It animates the page by taking a screenshot of the current page, and a live snapshot of the next page, the following CSS selectors will be valid for customizing the animation:

::view-transition-old(root) /* old page snapshot */
::view-transition-new(root) /* next page live snapshot */

Those CSS selectors applies to the whole page, but it doesn’t stop here, you can assign unique view transition names for elements of your choice! We will explain that in just a moment.

3. The markup we have is straightforward, we have a header element that have links to the two pages we have, and each page is wrapped in a div element with a class name of content.

4. Let’s explain what’s inside the style tag. In our example, the header element doesn’t change between pages, we want to animate the inner page only, we accomplish this by assigning a unique ID for the div element, using the view-transition-name CSS property.

   Which, in turn, takes snapshots of that inner page, the following CSS selectors will be available for us:

   ::view-transition-old(content) /* old page snapshot */
   ::view-transition-new(content) /* next page live snapshot */

We use those for specifying our own CSS animation, the old page will scale out and slide left, the new page will slide left and scale in.

Let’s show the code for the missing elements, I will only give the file name with the code snippet. No need to explain those as they are beyond the point of this blog post.

• routes/+layout.server.ts:

  import type { LayoutServerLoad } from './$types';
  
  const defaultData = {
  	name: 'Hash Ketchum', // Ash Ketchum's cousin, he's a developer
  	email: 'hash@catchemcode.com',
  	pokemonId: 7
  };
  
  export const load = (async ({ cookies }) => {
  	const name = cookies.get('name') || defaultData.name;
  	const email = cookies.get('email') || defaultData.email;
  	const pokemonId = cookies.get('pokemonId') || defaultData.pokemonId.toString();
  
  	cookies.set('name', name);
  	cookies.set('email', email);
  	cookies.set('pokemonId', pokemonId);
  
  	const paddedPokemonId = pokemonId.padStart(3, '0');
  	const pokemonAssetsUrl = 'https://assets.pokemon.com/assets/cms2/img/pokedex/detail';
  	const pokemonImageSrc = `${pokemonAssetsUrl}/${paddedPokemonId}.png`;
  
  	return {
  		pokemonImageSrc,
  		name,
  		email,
  		pokemonId
  	};
  }) satisfies LayoutServerLoad;

• routes/+page.svelte:

  <script lang="ts">
  	import type { PageData } from './$types';
  
  	export let data: PageData;
  </script>
  
  <main class="flex-grow min-h-0 bg-indigo-400">
  	<div class="mx-auto py-12 text-center">
  		<h1 class="text-4x">Welcome, {data.name}!</h1>
  		<div class="flex flex-col items-center gap-8">
  			<h2>Your Pokeomon</h2>
  			<div
  				class="flex items-center justify-center bg-gray-100 ring-5 ring-pink-400 p-3 rounded-full"
  			>
  				<img src={data.pokemonImageSrc} alt="Avatar" class="w-64 h-64 rounded-full" />
  			</div>
  			<div>
  				<h2>Your email</h2>
  				<p class="text-normal underline">{data.email}</p>
  			</div>
  		</div>
  	</div>
  </main>

• routes/edit/+page.svelte:

  <script lang="ts">
  	import { enhance } from '$app/forms';
  	import TextField from '$lib/TextField.svelte';
  	import type { PageData } from './$types.js';
  
  	export let form;
  	export let data: PageData;
  </script>
  
  <main class="flex-grow min-h-0 bg-violet-500">
  	<div class="mx-auto py-12 text-center">
  		<h1 class="text-4x">Edit Profile Info</h1>
  		<div class="flex flex-col items-center gap-8">
  			<form method="POST" use:enhance class="text-center w-[90vw] lg:w-[50vw] xl:w-[33vw]">
  				{#if form?.message}
  					<p>{form.message}</p>
  				{/if}
  
  				<h2>User Info</h2>
  				<div class="flex flex-col gap-6">
  					<TextField name="name" type="text" placeholder="Name" value={form?.name ?? data.name} />
  					<TextField
  						name="email"
  						type="email"
  						placeholder="Email"
  						value={form?.email ?? data.email}
  					/>
  					<TextField
  						name="pokemonId"
  						type="number"
  						placeholder="Pokemon Id"
  						value={form?.pokemonId ?? data.pokemonId}
  					/>
  					<button
  						class="mt-2 cursor-pointer bg-pink-400 hover:brightness-110 transition-all p-3 border-0 rounded-xl text-lg text-white"
  					>
  						Save
  					</button>
  				</div>
  			</form>
  		</div>
  	</div>
  </main>

• routes/edit/+page.server.ts:

  import { fail } from '@sveltejs/kit';
  
  import type { Actions } from './$types';
  
  export const actions = {
  	default: async ({ request, cookies }) => {
  		const data = await request.formData();
  
  		const name = data.get('name') as string | null;
  		const email = data.get('email') as string | null;
  		const pokemonId = data.get('pokemonId') as string | null;
  
  		if (!name || !email || !pokemonId) {
  			return fail(400, {
  				message: 'Please fill out all fields',
  				name,
  				email,
  				pokemonId
  			});
  		}
  
  		cookies.set('name', name);
  		cookies.set('email', email);
  		cookies.set('pokemonId', pokemonId);
  
  		return {
  			message: 'Your profile has been updated!',
  			name,
  			email,
  			pokemonId
  		};
  	}
  } satisfies Actions;

• lib/HeaderItem.svelte:

  <script lang="ts">
  	import { page } from '$app/stores';
  
  	export let href: string;
  
  	$: isActive = $page.url.pathname === href;
  </script>
  
  <a
  	class="flex items-center gap-2 text-xl color-white hover:bg-cyan-100/20 p-2.5 rounded-xl {isActive &&
  		'bg-cyan-100/40'}"
  	{href}
  >
  	<slot />
  </a>

  lib/TextField.svelte:

  <script lang="ts">
  	export let type: string;
  	export let value: string;
  	export let name: string;
  	export let placeholder: string;
  </script>
  
  <input
  	class="p-3 rounded-xl drop-shadow outline-none border-none ring-3 ring-transparent focus:ring-pink-400 focus:border-pink-400 transition-all text-lg"
  	{name}
  	{type}
  	{placeholder}
  	{value}
  />

Now we have implemented a page transition without the hassale of using a third-party library or complex state management! This is the power of the new web transition API, and it’s awesome to see frameworks like SvelteKit and Astro adapting to it so quickly. Can’t wait to see more browserss supporting it ( Firefox, I’m looking at you ).

I hope you enjoyed this blog post, and see you in the next one!

In this blog post, I will provide you with a better way to embed tweets in your SvelteKit app, The tweet will be generated statically on the server. Without any additional scripts or iframe elements, and without sacrificing performance or having layout shifts anymore.

In the last month, Vercel announced the new react-tweet package for rendering statically generated tweets in your Next.js app. In the pages directory, it works by requesting the Twitter syndication API server-side before the page load. For React Server Components, the tweet is fetched and rendered server-side in the relevant component.

I thought making a SvelteKit version would be cool! And I wanted to use the same on my blog, hence, I made the sveltekit-tweet package.

Let’s dive into the implementation details to get it running on your website. We will begin with the most basic example, then we will head into adding tweets to your markdown files.

Begin by installing the `sveltekit-tweet`` package via pnpm - or npm/yarn, depending on your flavor of choice.

pnpm add sveltekit-tweet@latest

And in +page.server.ts, we import the getTweet function from sveltekit-tweet/server

import type { PageServerLoad } from './$types';
import { getTweet } from 'sveltekit-tweet/server';

export const load = (async () => {
	const tweetId = '1694201062717034868'; // You'll find it in the tweet URL
	const tweet = await getTweet(tweetId);

	return { tweet };
}) satisfies PageServerLoad;

The tweetId could be directly extracted from the URL you want to embed, and the getTweet function will fetch the tweet info using Twitter’s / X’s API. This function is a server-only function, it won’t be imported into your client-side script (which is a good thing).

The last step is to render what you get in your +page.svelte component:

<script lang="ts">
	import { Tweet } from 'sveltekit-tweet';
	import type { PageData } from './$types';

	export let data: PageData;

	const tweet = data.tweet;
</script>

<Tweet {tweet} />

Looks good, right? Now let’s head into embedding tweets in your markdown files, which is the cooler and more usable option. If you use a tool like mdsvex, you can add tweets to your articles this way:

> A quoted text followed by a tweet:

<div data-tweet="1694201062717034868" />

The only requirement is to use the renderTweets function, in +page.server.ts we have the following:

export const load: PageServerLoad = async ({ params }) => {
	try {
		// Import the markdown file
		const post = await import(`../blog/posts/${params.slug}.md`);

		// Render markdown file into HTML
		let content = render(post.default).body;

		// This will render all tags with data-tweet=”…” to statically generated tweets
		content = await renderTweets(content, fetchedTweets);

		return {
			content,
			meta: post.metadata,
			slug: params.slug
		};
	} catch (e) {
		throw error(404, `Could not find ${params.slug}`);
	}
};

The renderTweets function will transform all tags with data-tweet attribute be rendered using @html expression:

<script>
	export let data;
</script>

<article class="...">
	<main class="...">{@html data.content}</main>
</article>

A quoted text followed by a tweet:

And that’s it! Now you can embed without having to worry anymore, and without any headache or poor performance metrics.

Svelte is a compact Frontend framework and UI definition language for crafting user interfaces for the web. It was created by Rich Harris in 2016, and it was increasing in popularity since then, especially in the last few years when developers have begun noticing React’s drawbacks. It even got its own rockstar meta-framework: SvelteKit, the Svelte counterpart to React’s Next.js. And now both are endorsed by the same company, Vercel.

Svelte’s meta-framework, SvelteKit, reached its stable 1.0 release last year, and it offers a set of powerful features like mixed rendering patterns, nested layouts, server actions, and progressive enhancements, along with other useful features that contribute to a better user experience. According to Rich Harris - the creator of Svelte and SvelteKit, the team will now direct their attention to Svelte itself. So too, this article will focus on the impact and potential of Svelte in the web industry.

Since the beginning of the web era, it became well known to folks that, to build a website, they use the three couples HTML, CSS, and JavaScript. Even people who want to dive into the web world start their journey by learning those technologies, which is an excellent starting point. However, building highly interactive and visually appealing interfaces by only using those base technologies is challenging and often difficult to maintain. Developer teams have always been hardworking to simplify the web, which leads to the adoption of JQuery, and, subsequently, the most-popular library for building user interfaces - React.

The general paradigm is that JavaScript is event-driven. It reacts to events like user interaction, network calls, timers, and more. While UI is state-driven, it reflects the current state of the application or user interactions, This inconsistency led to unnecessary complexities, which is why the primary focus of React is to make JacaScript more state-driven. This is what has made it the most popular Frontend UI library, React changed how we build applications for the web, in a good way. ****

The internal concept behind React is to abstract the DOM away for the users and use a Virtual DOM to detect changes in the UI, detect changes in the component state and update the UI accordingly, but this also leads to other drawbacks, having a virtual DOM is another layer of complexity, it often leads to unnecessary renders, and having tools like useMemo and useCallback is also an additional concern, adding complexity and leading to buggy UI, and those were invented to address the problem of unnecessary renders, which is React’s problem, not us.

When Svelte came out, its primary goal was to show developers that we achieve the same with less complexity, and without additional costs like having the VirtualDom. Svelte is also event-driven, but unlike React, it works by augmenting HTML with JavaScript using DSLs - or magic!

Svelte adds a compile step so that we are only deploying HTML, CSS, and JavaScript in the end, which is a big advantage over React. The end result of deploying a Svelte app is that the website is mereley as the browser expects, without any unnecessary work and overhead.

The state-driven nature of Svelte is accomplished by making state assignments Reactive. Updates in the state reflect updates in the UI in the exact place where it’s needed, without any unnecessary work. The ultimate result is a front-end framework that has two impressive qualities: high performance and simplicity.

That seems it’s exactly what the web was intended to be, and it is. Svelte is a versatile choice for building modern websites, but it’s a bit late - React has become the go-to option and the frontend choice to lead the web, it already established itself being the go-to choice for most web apps. React now leads the game having it’s own large community and the trust of many prominent companies to use it in their production web applications.

Here is a tweet from @steventey which has a subset of what React is used for:

So if you are learning web development and you want to pick your first UI library, or you are looking to start a new web app business, picking React is a great safe option, especially with modern meta frameworks like Next.js and Remix.

Otherwise, if you are just starting with the web or are building your own personal website, I highly recommend picking Svelte, it’s closer to HTML and is much simpler and enjoyable to use for this kind of project. I had a great experience using SvelteKit for building my personal website.

If you have an existing project using React or other tools, don’t feel behind the track, your framework is fine and there is no need to switch for most cases. A good reason to learn or use technologies like Svelte is for experimenting or obtaining new perspectives, and if you find that it was a great handy experience, don’t be afraid to pick it for larger projects, in the end, Vercel bets on Svelte the same way as it bets on React.

When I begin my journey as a Frontend developer, I heard a piece of advice from my Senior developer that always stuck in my head.

Coding the design and implementing it is the easiest part. The real key point that makes you a better developer is your problem-solving skills.

As time goes on, I am starting to understand the importance of this legendary advice. We often see those high-tier developers and their impressive solutions. Without their exceptional problem-solving abilities, we would not have access to the powerful technologies we use daily.

Those type of people who have solid problem-solving skills often master the Engineering mindset. They start by defining the problem, they look for a solution that works, and keep improving with better and more efficient solutions.

On the other hand, there are many people who don’t have that engineering mindset, they are more picky about the technologies they use. When a new tool is released, they get hyped about it and often label their previous tools as ‘outdated’. They also tend to abandon or redo their side projects using the same excuse.

The latter type of individuals often lack that Engineering mindset. They are more like frameworkers who prioritize new technologies over practicality. They are more modern-like developers, but tend to lack consistency in their lives. While they may perform amazingly at first because of the excitement with the new tools, they often lose interest and start looking for the next big thing.

The fact: Neither of those two is better than the other

Based on my tone, you may have noticed that I tend towards engineering thinking as the best or the smore practical approach. That’s true, but actually it depends.

In the last two decades, we have seen a lot of companies almost dying because of their legacy systems, it doesn’t matter if their staff is great engineers or problem solvers, if they remain outdated, it’s over.

Let’s take a look at Yahoo! for example, it had one of the most known websites of the internet era, but its staff struggled a lot to keep themselves up to date with the rapidly evolving technologies. They clearly failed on realizing the power that new solutions could bring to their search engine. On the other hand, Google saw the real power of modern tech, they have built powerful cloud servers, and web applications, and even integrated the power of AI & Machine Learning into their search engine.

We see a lot of engineers dropping their journey because they weren’t up to date, the same way as we see frameworkers dropping their journey because lack of problem-solving skills, what’s the solution? Find a middle ground!

How to be a more creative and modern engineer?

If you are from the first type, and you find yourself way behind those hyped frameworkers that you daily see on social media platforms, here is a list of tips you can follow:

1. Stay Updated: Keep up with new technologies and frameworks.
2. Be Adaptable: Learn different tools that can simplify your tasks.
3. Practical Learning: Try out new frameworks via hands-on projects.
4. Don’t Reinvent: Avoid building from scratch when a solution already exists.

How to improve your engineering thinking?

If you find yourself closer to the frameworker mindset, here is a list of tips that you can work on to improve your engineering thinking:

1. Understand Fundamentals: Learn the core engineering principles.
2. Problem-Solving: Focus on developing your problem-solving skills.
3. Look Under the Hood: Learn how frameworks work internally.
4. Versatility: Don’t rely solely on a single framework; diversify your toolkit.

Final thoughts

Being a better developer is not being that hard-core engineer, nor being that die-hard frameworker with the “tool of the next era” nonsense.

It’s becoming a Tech-Balancer, who knows when to go old-school style and when to ride the waves of the latest tech!

So go ahead, and make some magic happen 🙂