Svelte Vs Sveltekit

Given that Svelte and Sveltekit go together hand-in-hand, the point of opposing one against the other is almost moot.

There is however, something to be said about the differences between the two and when it’s appropriate to whip either of them out.

The one-line summary for this entire article could be:

Use Svelte for single-page front-end apps, and use Sveltekit for multi-page full-stack apps.

And frankly, that’s about as complex as this all needs to be.

But for the cerebral beings out there that need more clarity than that, this post will dive deeper into this distinction. We’ll discuss the cases for and against each of the options, and in which circumstances it is best to opt for either one.

Skip to FAQ’s

What Is Svelte

Let’s quickly set the stage and understand what Svelte is, so that we can make educated contrasts later on.

Svelte, put simply, is a type of file (.svelte) which is superset of HTML. These files are called Svelte “Components”.

Svelte Components take HTML, CSS and Javascript, and provide a new intuitive syntax for building applications. The syntax consists of these 3 optional parts, which have scoping within the whole component.

<script>
  // logic goes here
</script>

<!-- markup (zero or more items) goes here -->

<style>
  /* styles go here */
</style>

It may look innocent, but the Svelte component does a lot of heavy lifting internally to improve the developer experience over using vanilla Javascript. It offers additional features, such as:

• Components props,
• Reactive variable assignments,
• Reactive variable statements - where if some variable relies upon another to be determined, they update synchronously, and
• Variable Stores - such as global variables which are accessible anywhere within the app.

Maintaining these sorts of features in vanilla Javascript is awfully painful, so using Svelte allows the developer to focus on the business logic of the application, rather than jumping through the intricacies of Javascript to make everything work as you’d hope.

Svelte The Compiler

Given that Svelte is a compiled syntax, it must go through a build process to work in a browser.

Whilst we create the Svelte components with the simplified syntax, what happens under the hood is that these .svelte files are compiled to vanilla Javascript, and what you experience in the browser is the compiled output.

In essence, the output of Svelte could be replicated in pure Javascript, but you’re going to take a whole lot longer writing the code!

Sveltekit and meta-frameworks

Given that we now know the simple concept and mission of Svelte, we can look at its counterpart meta-framework: Sveltekit.

If you’ve ever programmed any reasonably sized application using a Javascript framework (e.g. react, vue, solid, qwik etc), then you’ve likely already been introduced to meta-frameworks - knowingly or not.

A meta-framework is a bundled collection of tools built on top of a web-based programming framework to provide utilities that exist in most applications.

These include (but are not limited to):

• Servers (and thus, server functions)
• Routing/Navigation
• SEO features
• Middleware
• Rendering configurations, etc.

Most frameworks don’t provide these tools out of the box, so you have the option to either manually integrate these sorts of features on top, or use an opinionated meta-framework, such as Sveltekit.

Do You Need A Meta-Framework To Build An App?

Technically, no. You could introduce these utilities individually to your pure Svelte project manually. You’ve been warned that it’s an absolutely time-consuming and verbose process to connect all of the moving parts and have them work in harmony - but it is possible.

And if you want the niceties of things like private database access and file-based routing, you’ll need to configure a tool like Vite to build from your root directory.

A Movement Towards Meta-Frameworks

With front-end developers recently incorporating more back-end activities into their workflow, meta-frameworks have exploded in popularity over the last 3 years.

This is true so much so that the Svelte Docs default to installing a Sveltekit app when creating a new Svelte application. Only to show an alternative method below it to install Svelte without Sveltekit.

This is also true in the React Docs, suggesting NextJS as the default way to create React apps.

Until 2023, it was rare for frameworks to suggest a meta-framework as a default when creating new apps. Nowadays, almost all popular frameworks have an official complementary meta-framework and also suggest using it as the default.

Head-to-Head Comparison

Performance

In Sveltekit, most of the heavy lifting is done on the server, whereas with plain Svelte, there is no server, so it only the users browser.

Unless you specifically tell it not to do so, Sveltekit will render your pages HTML on a server, before sending it to the client for it to be hydrated. This is called Server-Side-Rendering (SSR).

Svelte, on the other hand only uses Client-Side Rendering, which requires the client download and execute the Javascript before the page can be rendered.

So, which is faster then?

In most cases, Sveltekit will be faster than Svelte due to its prerendering capabilities.

This is further promoted by the fact that Sveltekit server load functions with asynchronous data retrieval can be passed to the client as a promise, and later resolved on the client. This means that the server doesn’t have to wait for the data to be returned before it can render the page and send it to the client.

This is a common issue people have with other meta-framework SSR solutions, which Sveltekit solves. Developers have opted into data-fetching from the client to get around this, by serving the page first, and then showing a loading spinner as the data comes back to the client.

Bundle size

The bundle size for both Svelte and Sveltekit are remarkably small.

Since Sveltekit it a superset of Svelte, it obviously has a larger bundle than plain Svelte. But with that comes a bunch of extra functionality and build tools loaded into it.

However, when discussing the point of bundle size, the only thing that matters is what is being sent to the client.

With Sveltekit, since most of the work is done on the server, the download size required of the client to receive a “Hello World” page is almost identical to pure Svelte.

The bundle size itself for Svelte is just 1.6kB (gzipped), which is what is being shipped to the browser.

In 2024 where rich content like images/videos and 3D rendering are commonplace, payloads under 10KB is considered dust. So to get going with Svelte, there’s extremely little overhead added to the user.

What Can Sveltekit Do That Svelte Can’t

Sveltekit can do everything that pure Svelte can. But pure Svelte can’t do a lot of what Sveltekit can do.

This list could go on forever, but we’ll list the main issues that Sveltekit solves over Svelte.

Remember, technically most of this is possible with Svelte, however it’s mostly unreasonable to implement the following without Sveltekit.

• Authentication,
• Building an API,
• Running Server Functions
• Access Control and Permission Based Routing
• Dynamic Routing (wildcard page names)
• Running a Content Management System
• Running a decently sized blog
• Creating automations
• Running an email service
• Having an SEO optimized website

Use Cases and When to Choose Which

As a general rule, if you’re looking to create a full-stack application, you should opt into Sveltekit. In fact, given that Sveltekit is a superset of Svelte, you’re almost always better off utilizing Sveltekit, with a few exceptions.

Best scenarios for adopting SvelteKit

As mentioned, Sveltekit is almost always better to use than Svelte. So let’s be more specific about this. If any of the following features or properties is required of your project, you’re best selecting to build with Sveltekit:

• Maintaining an API
  • Sveltekit allows you to create endpoints within the same repository. This is beneficial for having relative paths between pages and API endpoints, or even if you want to add libraries such as TRPC to have typesafety between your frontend and backend code.
• Server Functions
  • Server functions are the backbone of full-stack applications. Sveltekit server functions allow you to perform actions such as data mutation in a database, run cron jobs, or run logic where you require some private key to be used (e.g. password).
• User Authentication
  • Given that Sveltekit has built-in middleware, you are able to build an Authentication system on top of Sveltekit, where session tokens or JWT’s are used to manage permissions.
• SEO - Search Engine Optimization
  • Sveltekit allows you to add meta-tags to each page with <svelte:head>. You can also have server functions do the heavy lifting to generate and present sitemaps, and RSS feeds. And Sveltekit has auto-enhances images from buildtime.
• Server-Side Rendering
  • With Sveltekit, SSR is on by default so you can have super speedy HTML sent to the client before having to load the Javascript.
• Pre-rendering pages
  • The ability to pre-load and render a page before a user even clicks to enter the page makes your app feel instant.
  • This is an all-round consideration for improving user experience - and thus SEO.
  • Prerendering is on by default for Sveltekit pages and components, however this can be turned off by declaring export const prerender = false; at the beginning of the page load file: i.e. +page.ts/+page.server.js/+server.js
• Structured Data
  • Structured data is a commonly ignored strategy to apply additional context to a webpage - search engines use this data to better categorize your pages, and can show some of this metadata in the search results.

Best scenarios for using Svelte

Now, let’s talk about the few instances when a pure Svelte app should take precedence over a Sveltekit app.

• When implementing a front-end to an already existing backend
  • This is most common when the backend is written in a language other than Javascript, such as Go, Python, or Rust - to name a few.
• Creating basic apps or tools without the need for user authentication or server interaction.
  • Examples of this would be calculators, logic games, embedded UI’s etc.
• Small lightweight projects
  • If you’re looking to make a tiny project to serve some small business logic. Perhaps you don’t want to build it in vanilla Javascript, but you also don’t need the additional overhead that the Sveltekit meta-framework provides.
• If SEO is not of importance.

If most of the above apply to your project, then perhaps you are better off utilizing Svelte without Sveltekit.

Perhaps you’d like to make a single-page app where SEO is not of importance, but you want to pull in data from public endpoints. In this case, you probably don’t need the bells and whistles that Sveltekit brings, like a built-in server or opinionated routing.

Any even if you did want to create a server, but don’t care for the other stuff, then you could still spin up an express server and utilize that server how you’d like.

Conclusion

Unless you’re absolutely sure you only need the pure fundamentals of Svelte, then you should learn and start adopting Sveltekit. You’ll get the meat and potatoes of Svelte, with a bunch of battle-tested functionality for minimal overhead.

I’d go so far as to even suggest new developers begin using Sveltekit, as it exposes them to a lot of the technologies that they would experience as a user of the web. And being able to replicate these features - like navigate between pages - is awesome for creating positive feedback loops.

As Sveltekit is so easy to understand and aligned with common web standards, the learning curve is smoother than most other meta-frameworks.

Sveltekit is faster, more flexible, more powerful, and is better positioned to help your business with some of the SEO capabilities.

Sveltekit: certified rockstar 🤘.

FAQ’s