routify VS Sapper

Anyway, it seems you have a problem with Sveltekit routing. You can still use Svelte with other SSR frameworks, such as Astro, a router like https://routify.dev, or switch to another framework altogether.

Routify is still active and new version in the works. Version 3 can be used https://github.com/roxiness/routify/tree/next

Consider https://github.com/roxiness/routify

Regarding some suggestions on here recommending SvelteKit: Learning SvelteKit might be a big ask depending on what you're trying to do. If you just want to stick with svelte only for now, and you want to add SPA routing capabilities, consider checking out https://routify.dev there's a ton of documentation for it and it's fairly simple to pick up. ✌🏼

Routing: We have a few third party ones such as routify, svelte-spa-router and svelte-routing as well as the clientside routers included in SvelteKit and Sapper.

if Next.js/Nuxt like needs are not something you're looking for yet, you can definitely go ahead with Svelte's default client-side app approach, with svelte-spa-router or routify for SPAs.

We chose Routify for client-side routing because this was around the time that Sapper seemed like it was being sunset in favor of Sveltekit which doesn't seem production-ready quite yet. We also have plans to statically pre-render the app so it can more-or-less work entirely offline and Routify makes that relatively straightforward (but see below).

Since svelte does a lot of compile time stuff, I would like to mention Routify, which is compile time SPA routing. For me it worked awesome to accomplish projects with many routes and the need for hash based routing.

See https://routify.dev/ and https://routify.dev/guide/installation/install-to-existing-p...

Example for web - https://routify.dev/

I built my first simple blog site in 2020 using Svelte and Sapper. The blog posts were powered by markdown files stored in the repository, and it was a great starting point.

Sapper

pancake which has very scarce documentation and is in thorough experimentation(at the time of writing). Since it has been created by Rich Harris, you can rest assured that it might probably never get documentation or a stable release just like our fallen soldier sapper (a moment of silence in remembrance)

SvelteKit can be considered the successor to Sapper or NextJS for Svelte. It is packed with tons of cool features, like server side rendering, routing, and code splitting.

So after using Sapper for some time, I decided to move my website to SvelteKit. I remember saying that I would not move to SvelteKit till they hit version 1 but the framework looks too promising. It had features which I needed and those features weren't in Sapper.

By that time, we had some troubles with virtual dom itself in our custom rich text editor that we based on slate - it was getting a bit laggy when creating huge financial documents (they usually have enormous tables and a lot of infographics) -so we were already thinking about other options and that’s where svelte comes into the light - especially sapper which was de facto default framework to be used with svelte at that time (SvelteKit wasn’t even announced).

Sapper is a framework for building web applications of all sizes, with a beautiful development experience and flexible filesystem-based routing. It is the predecessor of Sveltekit.

Sapper - ecossistema Svelte

Lol I won’t, and to answer your question, it’s built using sapper: https://sapper.svelte.dev

I maintain a Svelte Starter Kit and all I had to do between several updates is change the layout file names, simplify the hooks, and convert the config file extensions. If you're learning Svelte in 2021, you shouldn't miss learning it, as it's "the missing CLI" and the svelte team's favoured project structure, to build full-stack server rendered and static sites, with File/Folder based routing, focus on server-less with adapters, API routes, and good baked-in conventions and constructs to support common web app needs. It's a successor to Sapper which served the aforementioned needs, with exception of adapters, which is special/unique(with no officially provided parallels in Next.js/Nuxt ecosystems yet) way to make vendor-agnostic, server-less first deployment concern a seamlessly integrated part of the framework.