routify VS rfcs

Been using Routify in all my projects since I started with Svelte like 3-4 years ago.

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

I would have to say Svelte with a router like https://routify.dev . My recent blog post originally used sveltekit but I swapped it out last minute

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...

There's an issue open already and a RFC: https://github.com/sveltejs/svelte/issues/6059 https://github.com/sveltejs/rfcs/pull/64

The RFC ticket is here, so if anyone could provide valid use cases, please do it and push hard to make this happen: https://github.com/sveltejs/rfcs/pull/34

In the state Svelte is as of this day, there are a few bumps making it harder to implement versatile sets of UI primitives / atomical components. Namely, some of the ones I've met are: lack of syntax to cleanly forward directives and transitions to a component's template (https://github.com/sveltejs/rfcs/pull/60), lack of default slot assignment (i.e. automatically assigning a child component to a parent's slot without requiring devs to manually specify slot="..."), inconsistent bind:group behavior when used on components with nested inputs or through a store passed with setContext, etc. I don't have as much experience trying to implement such UI library components with other frameworks I've used (Vue, Angular) so I can't really say for sure that these challenges are confined to Svelte.

Good stuff. The conditional wrapper unfortunately doesn't work with directives, but the forward directive RFC would address that.

(Also a con): It's funny to me that a lot of people try to change Svelte to be "light-React" (see the Svelte RFCs). This also tells a lot about React too, it shows what React nails right on the head and what it misses horribly where Svelte got it right.

It's part of this proposal: https://github.com/sveltejs/rfcs/pull/38

Exclusive to elements: Like most Svelte directives (with the exception of on:), this does not work on components. There is an open RFC to allow forwarding directives to components, which would include style directives. However, this RFC has not been accepted at time of writing.

since v3.38.0 https://github.com/sveltejs/rfcs/pull/13 it not yet documented

All of these issues are very valid. For forwarding, I highly suggest you take a look at this RFC I wrote which will make this much https://github.com/sveltejs/rfcs/pull/60