Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add new project types page #13444

Open
wants to merge 11 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 63 additions & 0 deletions documentation/docs/10-getting-started/25-project-types.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
---
title: Project types
---

SvelteKit offers configurable rendering, which allows you to build and deploy your project in several different ways. You can build all of the below types of applications and more with SvelteKit. Rendering settings are not mutually exclusive and you may choose the optimal manner with which to render different parts of your application.

If you don't have a particular way you'd like to build your application in mind, don't worry! The way your application is built, deployed, and rendered is controlled by which adapter you've chosen and a small amount of configuration and these can always be changed later.

The project structure and routing will be the same regardless of the project type that you choose. If you are building an application with no backend or where the backend is running in a difference service, you can simply skip over and ignore the parts of the docs talking about `server` files.

## Default: hybrid-rendered app

By default, when a user visits a site, SvelteKit will render the first page with server-side rendering and subsequent pages with client-side rendering. Using SSR for the initial render improves SEO and perceived performance of the initial page load. Client-side rendering then takes over and updates the page without having to rerender common components, which is typically faster and eliminates a flash when navigating between pages.

## Static site generator (SSG)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It bothers me that the format of these headers is different...

Should it be:

  • Default: Hybrid rendering
  • Static site generation (SSG)
  • Single-page app (SPA)
    ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even that doesn't feel quite right, struggling with how to align them

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean that the format is different? Like you think they all need to end in "app"? The only one that feels a bit different from the rest to me is "Backend in another language", but I'm not sure how else to write that and think it's worth keeping given how many people want to do that and run into it


You can use SvelteKit as a static site generator (SSG) that fully prerenders your site with [`adapter-static`](adapter-static).

You may also use [the prerender option](page-options#prerender) to prerender only some pages and then choose a different adapter with which to dynamically server-render other pages.

## Single-page app (SPA)

You can [build single-page apps (SPAs)](single-page-apps) with SvelteKit. As with all types of SvelteKit applications, you can write your backend in SvelteKit or [another language](#backend-in-another-language).

## Multi-page app (MPA)

Traditional applications that render each page view on the server — such as those written in languages other than JavaScript — are often referred to as multi-page apps. In SvelteKit you can remove all JavaScript on a page with [`csr = false`](page-options#csr), which will render subsequent links on the server, or you can use [`data-sveltekit-reload`](link-options#data-sveltekit-reload) to render specific links on the server.

## Backend in another language

If your backend is written in another language such as Go, Java, PHP, Ruby, Rust, or .Net then there are a couple of ways that you can deploy your application. The most recommended way would be to deploy your SvelteKit frontend separately from your backend utilizing `adapter-node` or a serverless adapter. Some users prefer not to have a separate process to manage and decide to deploy their application as a [single-page app (SPA)](single-page-apps) served by their backend server, but note that single-page apps have worse SEO and performance characteristics.

Also see [the FAQ about how to make calls to a separate backend](faq#How-do-I-use-X-with-SvelteKit-How-do-I-use-a-different-backend-API-server).

## Serverless app

SvelteKit apps are simple to run on serverless platforms. [The default zero config adapter](adapter-auto) will automatically run your app on a number of supported platforms. You can use [`adapter-vercel`](adapter-vercel), [`adapter-netlify`](adapter-netlify), or [`adapter-cloudflare`](adapter-cloudflare) to provide platform-specific configuration. And [community adapters](https://sveltesociety.dev/packages?category=sveltekit-adapters) allow you to deploy your application to almost any serverless environment.

## Your own server (VPS)

You can deploy to your own server using [`adapter-node`](adapter-node).

## Container (Docker, etc.)

You can use [`adapter-node`](adapter-node) to run a SvelteKit app within a container.

## Mobile app

You can turn a [SvelteKit SPA](https://kit.svelte.dev/docs/single-page-apps) into a mobile app with [Tauri](https://v2.tauri.app/start/frontend/sveltekit/) or [Capacitor](https://capacitorjs.com/solution/svelte). Mobile features like the camera, geolocation, and push notifications are available via plugins for both platforms.

These mobile development platforms work by starting a local web server and then serving your application like a static host on your phone. You may find [`bundleStrategy: 'single'`](configuration#output) to be a helpful option to limit the number of requests made. E.g. at the time of writing, the Capacitor local server uses HTTP/1, which limits the number of concurrent connections.

## Desktop app

You can turn a [SvelteKit SPA](https://kit.svelte.dev/docs/single-page-apps) into a desktop app with [Tauri](https://v2.tauri.app/start/frontend/sveltekit/), [Wails](https://wails.io/docs/guides/sveltekit), or [Electron](https://www.electronjs.org/).

## Browser extension

You can build browser extensions using either [`adapter-static`](adapter-static) or [community adapters](https://sveltesociety.dev/packages?category=sveltekit-adapters) specifically tailored towards browser extensions.

## Embedded device

Because of its efficient rendering, Svelte can be run on low power devices. Embedded devices like microcontrollers and TVs may limit the number of concurrent connections. In order to reduce the number of concurrent requests, you may find [`bundleStrategy: 'single'`](configuration#output) to be a helpful option in this deployment configuration.
19 changes: 1 addition & 18 deletions documentation/docs/60-appendix/10-faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,24 +8,7 @@ Please see [the Svelte FAQ](../svelte/faq) and [`vite-plugin-svelte` FAQ](https:

## What can I make with SvelteKit?

SvelteKit can be used to create most kinds of applications. Out of the box, SvelteKit supports many features including:

- Dynamic page content with [load](load) functions and [API routes](routing#server).
- SEO-friendly dynamic content with [server-side rendering (SSR)](glossary#SSR).
- User-friendly progressively-enhanced interactive pages with SSR and [Form Actions](form-actions).
- Static pages with [prerendering](page-options#prerender).

SvelteKit can also be deployed to a wide spectrum of hosted architectures via [adapters](adapters). In cases where SSR is used (or server-side logic is added without prerendering), those functions will be adapted to the target backend. Some examples include:

- Self-hosted dynamic web applications with a [Node.js backend](adapter-node).
- Serverless web applications with backend loaders and APIs deployed as remote functions. See [zero-config deployments](adapter-auto) for popular deployment options.
- [Static pre-rendered sites](adapter-static) such as a blog or multi-page site hosted on a CDN or static host. Statically-generated sites are shipped without a backend.
- [Single-page Applications (SPAs)](single-page-apps) with client-side routing and rendering for API-driven dynamic content. SPAs are shipped without a backend and are not server-rendered. This option is commonly chosen when bundling SvelteKit with an app written in PHP, .Net, Java, C, Golang, Rust, etc.
- A mix of the above; some routes can be static, and some routes can use backend functions to fetch dynamic information. This can be configured with [page options](page-options) that includes the option to opt out of SSR.

In order to support SSR, a JS backend — such as Node.js or Deno-based server, serverless function, or edge function — is required.

It is also possible to write custom adapters or leverage community adapters to deploy SvelteKit to more platforms such as specialized server environments, browser extensions, or native applications. See [integrations](./integrations) for more examples and integrations.
See [the documentation regarding project types](project-types) for more details.

## How do I include details from package.json in my application?

Expand Down
Loading