DEV Community

Cover image for A Short History of SvelteKit
ajcwebdev
ajcwebdev

Posted on • Edited on

A Short History of SvelteKit

Table of Contents

October

November - December

January - February

@sveltejs/kit on NPM - 0.0.8

Rich Harris, Conduitry - October 13, 2020

Here be dragons, etc etc.

This is a more fleshed-out version of snowpack-svelte-ssr that aims to replicate Sapper's functionality in its entirety, minus building for deployment (which can be handled by 'adapters' that do various opinionated things with the output of snowpack build).

It's currently missing a ton of stuff but I figured I'd throw it up on GitHub anyway partly for the sake of 'working in the open' but mostly because I need an issue tracker to organise my thoughts.

There are no tests yet or anything like that. Some of the code has just been straight copied over from the existing Sapper repo, but a pleasing amount of it can safely be left behind.

This [Snowpack] thing is really neat. It has some bugs and missing features, but identifying those is the whole purpose of this experiment, and so far I've been able to MacGyver my way around them.

Clone this repo, npm install, and npm link. That will create a global link to the svelte bin. You can then either npm run build or npm run dev, if you intend to make changes and see them immediately reflected.

Then, clone the corresponding svelte-app-demo repo and follow the instructions therein.

Futuristic Web Development

Rich Harris - October 19, 2020

Q: Do I have to use this workflow?

No, absolutely not. There's this split in framework land between things like Angular and Ember which kind of really want to own the entire experience, even if it's technically possible to use the constituent parts by themselves.

Then on the other side you have things like React and Vue which are really just component frameworks and you're expected to build an app yourself, which is why things like Next and Gatsby and Remix exist. I want Svelte to be both of those.

You can be widely productive with this app template in a matter of seconds, but if you're a power user with specific needs that aren't met by this template for whatever reason, then those needs will continue to be met by the Svelte project.

It is critically important that people are able to build their own custom integrations, plugins for things like Eleventy, or ever Svelte based frameworks like Routify and ElderJS and that is not gonna change.

Svelte, a bright future with Snowpack

Carlosvin - October 24, 2020

As you might know, this blog is powered by Sapper. I am already quite happy with it, so when I hear this announcement, I felt like when they cancel a TV Series that I am enjoying.

Happily, there is a good reason, there is going to be a better Sapper, I think they will call it SvelteKit, it is solving some issues and improving some aspects of Sapper, but the main benefit, in my opinion, is that you won’t have to choose between Sapper or Svelte when you start a new application, everything will be supported by the Svelte ecosystem.

The Next Svelte May Be Serverless-First

Bruno Couriol - October 28, 2020

Harris then demoed svelte@next, the Svelte version that is being experimented upon — we will refer to that from now on as Svelte Next. Like Sapper (and Next.js), Svelte Next adopts a file-based routing. Harris created in the src/routes directory the components implementing the routes for the demoed application.

An index.svelte file implements the home page while an about/index.svelte implements the /about route. Layout components ($layout.svelte) may implement commonly occurring parts of pages (e.g., a header or a footer) and keep the pages’ implementation DRY.

Twitter Announcement

Rich Harris - November 5, 2020

What's the deal with SvelteKit?

Rich Harris - November 5, 2020

Snowpack

Snowpack is at the vanguard of this movement, and it's what powers SvelteKit. It's astonishingly fast, and has a beautiful development experience (hot module reloading, error overlays and so on), and we've been working closely with the Snowpack team on features like SSR.

The hot module reloading is particularly revelatory if you're used to using Sapper with Rollup (which has never had first-class HMR support owing to its architecture, which prioritises the most efficient output).

Rollup

That's not to say we're abandoning bundlers altogether. It's still essential to optimise your app for production, and SvelteKit uses Rollup to make your apps as fast and lean as they possibly can be (which includes things like extracting styles into static .css files).

Server rendering

The other foundational assumption is that a server-rendered app needs, well, a server. Sapper effectively has two modes:

  • sapper build, which creates a standalone app that has to run on a Node server
  • sapper export which bakes your app out as a collection of static files suitable for hosting on services like GitHub Pages.

Static files and serverless platforms

Static files can go pretty much anywhere, but running a Node server (and monitoring/scaling it etc) is less straightforward.

Nowadays we're witnessing a shift towards serverless platforms, in which you as the app author don't need to think about the server your code is running on, with all the attendant complexity. You can get Sapper apps running on serverless platforms, thanks to things like vercel-sapper, but it's certainly not what you'd call idiomatic.

SvelteKit fully embraces the serverless paradigm, and will launch with support for all the major serverless providers, with an 'adapter' API for targeting any platforms that we don't officially cater to. In addition, we'll be able to do partial pre-rendering, which means that static pages can be generated at build time but dynamic ones get rendered on-demand.

a first look at svelteKit

Anthony Campolo - November 6, 2020

The Svelte core team is shifting its efforts to a project known as SvelteKit. It's important to emphasize that the people building Svelte, Sapper, and SvelteKit are all basically the same people. So really nothing drastic is changing here and it's more of a rebrand and namespace migration. Or is it?

In addition to the new name, there is also going to be a larger focus on serverless technology with Svelte now being referred to as a "serverless-first" framework. But to me the most significant change by far is the removal of Rollup and its replacement with Snowpack.

SvelteKit is very new, so new it currently exists mostly in the form of the blog post linked at the beginning of this article. But you can download it and start using it, albeit with many, many caveats attached to it.

Rich Harris talks SvelteKit and the future of web development

Svelte Radio - November 12, 2020

SvelteKit is, in one way it's a successor to Sapper. And you could even think of it as Sapper 1.0, if you like. But in another larger sense, it's our kind of vision for the way that you should build Svelte apps in future.

It’s something that we've been kind of talking about in a peripheral sense for a long time, we've been talking about how we can evolve Sapper to take advantage of some of the recent trends in front end development, particularly the rise of serverless and more recently, the rise of unbundled workflows.

But it all sort of came to a head recently, you know, the pace of development on Sapper had hit a bit of a low, at least until Ben McCann really picked up the baton and started churning through issues. And people were getting a little bit frustrated, I think with the progress. And Anthony is one of those people because he uses Sapper very heavily in his job.

At a certain point, we're like, “What if we just started from scratch?” Like the big rewrite, as opposed to trying to get all of these ideas into what was honestly kind of a watery codebase. I sort of proposed this very hesitantly in the discord thinking everyone was going to yell at me. And instead everyone was like, “Oh, yeah, let's do that.”

@sveltejs/kit on NPM - 1.0.0-next.1

Rich Harris, Conduitry - December 3, 2020

Here be dragons, etc etc.

This project aims to replicate Sapper's functionality in its entirety, minus building for deployment (which can be handled by 'adapters' that do various opinionated things with the output of snowpack build).

Svelte adapter for Netlify (@1.0.0-next.0)

Jasper Moelker - January 24, 2021

Get netlify configuration, defined by user in netlify.toml

module.exports = async function adapter(builder) {
  let netlify_config

  if (fs.existsSync('netlify.toml')) {
    try {
      netlify_config = toml.parse(fs.readFileSync('netlify.toml', 'utf-8'))
    } catch (err) {
      err.message = `Error parsing netlify.toml: ${err.message}`
      throw err
    }
  }

  else {
    throw new Error(
      'Missing a netlify.toml file. Consult https://github.com/sveltejs/kit/tree/master/packages/adapter-netlify#configuration'
    )
  }

  if (!netlify_config.build || !netlify_config.build.publish || !netlify_config.build.functions) {
    throw new Error(
      'You must specify build.publish and build.functions in netlify.toml. Consult https://github.com/sveltejs/adapter-netlify#configuration'
    )
  }

  // ...code blocks listed below

}
Enter fullscreen mode Exit fullscreen mode

Publish directory for static hosting

const publish = path.resolve(netlify_config.build.publish)
Enter fullscreen mode Exit fullscreen mode

Functions directory for cloud functions

const functions = path.resolve(netlify_config.build.functions)
Enter fullscreen mode Exit fullscreen mode

Copy static and client files to static hosting directory

builder.copy_static_files(
  publish
)

builder.copy_client_files(
  publish
)
Enter fullscreen mode Exit fullscreen mode

Copy server files to cloud functions directory

builder.copy_server_files(
  `${functions}/render`
)
Enter fullscreen mode Exit fullscreen mode

Copy renderer to cloud functions directory

fs.copyFileSync(
  path.resolve(
    __dirname,
    'files/render.js'
  ),
  `${functions}/render/index.js`
)
Enter fullscreen mode Exit fullscreen mode

Catch-all route to serverless render function in _redirects file

fs.writeFileSync(
  `${publish}/_redirects`,
  '/* /.netlify/functions/render 200'
)
Enter fullscreen mode Exit fullscreen mode

Prerender

builder.log.info(
  'Prerendering static pages...'
)

await builder.prerender({
  dest: publish
})
Enter fullscreen mode Exit fullscreen mode

Ben McCann on Sapper and SvelteKit

Svelte Radio - January 25, 2021

Q: On a high level, what is the difference between Sapper and SvelteKit?

The biggest change in my mind is the developer experience. SvelteKit is built on top of Snowpack and esbuild and so you're gonna see compile times be a lot faster. And that's something that's a problem in larger Sapper projects.

You don't notice it necessarily when you start out as a new user with Sapper. But when you start to grow your projects, some of the compile times with Sapper can get to be a bit longer. Our hope is to fix all of those issues and make it a really, really smooth experience with SvelteKit.

SvelteKit, the first ‘serverless-first’ framework?

Jasper Moelker - February 2, 2021

To ensure Svelte runs seamlessly on all [serverless platforms], Svelte will provide an adapter for each. Each adapter does three things:

  1. Copy to the serverless hosting directory Svelte’s:
    • compiled client-side JS bundles
    • other static files
  2. Copy to the serverless functions directory Svelte’s:
    • server-side JS bundles
    • platform specific render function
  3. Create the redirects configuration with a catch-all route to the serverless render function.

The adapter takes platform specific configuration (files) into account.

Top comments (0)