create-svelte

Everything you need to build a Svelte project, powered by create-svelte.

Creating a project

If you're seeing this, you've probably already done this step. Congrats!

# create a new project in the current directory
npm create svelte@latest

# create a new project in my-app
npm create svelte@latest my-app

Developing

Once you've created a project and installed dependencies with npm install (or pnpm install or yarn), start a development server:

npm run dev

# or start the server and open the app in a new browser tab
npm run dev -- --open

Building

To create a production version of your app:

npm run build

You can preview the production build with npm run preview.

To deploy your app, you may need to install an adapter for your target environment.

Deploying

First, build your app with npm run build. This will create the production server in the output directory specified in the adapter options, defaulting to build.

You will need the output directory, the project's package.json, and the production dependencies in node_modules to run the application. Production dependencies can be generated by copying the package.json and package-lock.json and then running npm ci --omit dev (you can skip this step if your app doesn't have any dependencies). You can then start your app with this command:

node build

Development dependencies will be bundled into your app usin Rollup. To control whether a given package is bundled or externalised, place it in devDependencies or dependencies respectively in your package.json.

Environment variables

In dev and preview, SvelteKit will read environment variables from your .env file (or .env.local, or .env.[mode], as determined by Vite.)

In production, .env files are not automatically loaded. To do so, install dotenv in your project...

npm install dotenv

...and invoke it before running the built app:

-mode build
+node -r dotenv/config build

PORT and HOST

By default, the server will accept connections on 0.0.0.0 using port 3000. These can be customised with the PORT and HOST environment variables:

HOST=127.0.0.1 PORT=4000 node build

ORIGIN, PROTOCOL_HEADER and HOST_HEADER

HTTP doesn't give SvelteKit a reliable way to know the URL that is currently being requested. The simplest way to tell SvelteKit where the app is being served is to set the ORIGIN environment variable:

ORIGIN=https://my.site node build

# or e.g. for local previewing and testing
ORIGIN=http://localhost:3000 node build

With this, a request for the /stuff pathname will correctly resolve to https://my.site/stuff. Alternatively, you can specify headers that tell SvelteKit about the request protocol and host, from which it can construct the origin URL:

PROTOCOL_HEADER=x-forwarded-proto HOST_HEADER=x-forwarded-host node build

x-forwarded-proto and x-forwarded-host are de facto standard headers that forward the original protocol and host if you're using a reverse proxy (think load balancers and CDNs). You should only set these variables if your server is behind a trusted reverse proxy; otherwise, it'd be possible for clients to spoof these headers.

If adapter-node can't correctly determine the URL of your deployment, you may experience this error when using form actions:

Cross-site POST form submissions are forbidden

ADDRESS_HEADER and XFF_DEPTH

The RequestEvent object passed to hooks and endpoints includes an event.getClientAddress() function that returns the client's IP address. By default this is the connecting remoteAddress. If your server is behind one or more proxies (such as a load balancer), this value will contain the innermost proxy's IP address rather than the client's, so we need to specify an ADDRESS_HEADER to read the address from:

ADDRESS_HEADER=True-Client-IP node build

Headers can easily be spoofed. As with PROTOCOL_HEADER and HOST_HEADER, you should know what you're doing before setting these.

If the ADDRESS_HEADER is X-Forwarded-For, the header value will contain a comma-separated list of IP addresses. The XFF_DEPTH environment variable should specify how many trusted proxies sit in front of your server. E.g. if there are three trusted proxies, proxy 3 will forward the addresses of the original connection and the first two proxies:

<client address>, <proxy 1 address>, <proxy 2 address>

Some guides will tell you to read the left-most address, but this leaves you vulnerable to spoofing:

<spoofed address>, <client address>, <proxy 1 address>, <proxy 2 address>

We instead read from the right, accounting for the number of trusted proxies. In this case, we would use XFF_DEPTH=3.

If you need to read the left-most address instead (and don't care about spoofing) — for example, to offer a geolocation service, where it's more important for the IP address to be real than trusted, you can do so by inspecting the x-forwarded-for header within your app.

BODY_SIZE_LIMIT

The maximum request body size to accept in bytes including while streaming. Defaults to 512kb. You can disable this option with a value of 0 and implement a custom check in handle if you need something more advanced.

Static site generation

Build and deply: Adapters - https://kit.svelte.dev/docs/adapters

Build and deply: Static site generation - https://kit.svelte.dev/docs/adapter-static

Build and deply: Single-page apps - https://kit.svelte.dev/docs/single-page-apps

Build and deply: Page options - https://kit.svelte.dev/docs/page-options

Cloudflare, Node servers

Build and deply: Cloudflare Pages - https://kit.svelte.dev/docs/adapter-cloudflare

Build and deply: Cloudflare Workers - https://kit.svelte.dev/docs/adapter-cloudflare-workers

Build and deply: Node servers - https://kit.svelte.dev/docs/adapter-node

The way of how to build docker image and run.

[~]$ docker build -t <image-name:tag> .
[~]$ docker run -dp 80:80 <image-name:tag>
[~]$ docker stop <container-id>
[~]$ docker rm <container-id>
[~]$ docker rmi <image-name:tag>

and with docker compose

[~]$ docker compose -p <my-project-name> up -d       # -p, --project-name
[~]$ docker compose down -v

Refs:

The choice of CSS and SCSS framework depends on your specific requirements and preferences. Each framework you mentioned—Bootstrap, Tailwind CSS, and Skeleton—has its own strengths and characteristics. Here's a brief overview of each framework to help you make an informed decision:

Bootstrap: Bootstrap is a popular and widely used CSS framework that provides a comprehensive set of pre-styled components and utilities. It offers a rich collection of responsive design elements, such as grids, typography, forms, buttons, and navigation. Bootstrap has a consistent and well-documented API, making it relatively easy to get started. However, Bootstrap's extensive styling may result in larger CSS files and a more opinionated design.

Tailwind CSS: Tailwind CSS takes a different approach compared to Bootstrap. It provides a utility-first CSS framework, offering a large set of utility classes that you can directly apply to your HTML elements to style them. Tailwind CSS allows for more flexibility and customization, as you can easily compose and customize utility classes to achieve the desired design. However, it may require a bit more effort to learn and work with compared to Bootstrap.

Skeleton: Skeleton is a lightweight CSS framework that aims to provide a minimal set of styles for common web development needs. It provides a responsive grid system, basic styling for typography and buttons, and a few other components. Skeleton is designed to be lightweight and unobtrusive, making it a good choice if you prefer a simpler and less opinionated framework. However, it may lack some of the advanced features and components provided by Bootstrap or Tailwind CSS. Ultimately, the best framework for your project depends on factors such as your project requirements, design preferences, learning curve, and the specific features and components offered by each framework. It can be helpful to explore the documentation and examples of each framework to see which one aligns best with your needs. Additionally, you can consider factors such as community support, available plugins or extensions, and the overall ecosystem around the framework.

Pros & Cons : SvelteKit prerendering and server-side rendering

Disabling prerendering in SvelteKit (or any framework that supports it) has both pros and cons. Let's discuss these:

1. Server load:

Pros: There is less load on your server during the build process because it doesn't have to generate the static HTML content for each page.

Cons: Your server could face more load when serving requests because each request now has to be dynamically rendered on-demand.

2. Performance:

Pros: There can be more dynamic interactivity, as the content isn't static and can be updated on every page load.

Cons: The performance can be less optimal, particularly for first-page loads, because the entire application needs to be downloaded, parsed, and executed before the user sees anything. With prerendering, the browser can start showing content as soon as the HTML is received.

3. SEO (Search Engine Optimization):

Pros: No specific advantage.

Cons: Disabling prerendering could have a negative effect on your site's SEO. Web crawlers from search engines prefer static HTML content, and some might not execute JavaScript at all.

4. Offline support:

Pros: No specific advantage.

Cons: If you're using a Service Worker to cache your site for offline use, having prerendered pages makes it more effective, as static HTML files can be easily cached for offline access.

Overall:

it depends on the nature of your application and your specific needs. For content-heavy, SEO-sensitive sites, prerendering is generally a good idea. For highly dynamic applications, turning off prerendering might be appropriate, but you'll likely want to pair that with server-side rendering (SSR) to maintain performance and SEO benefits.