Routify-powered Sveltekit

[braebo]

@ghostdevv mentioned to me that someone has floated the idea of having a Routify-powered router for SvelteKit. I just wanted to give my 2c on the matter-

As a long-time Routify evangelist- the idea is certainly exciting! Jake has done amazing things with Routify, and I've always felt that the entire svelte community should be able to benefit from his innovations. I try to spend a few hours / day providing support in the Svelte discord, and I encounter a lot of people with routing-related problems that Jake has solved elegantly in the world of Routify.

I know that Routify 3 supports kit (which is amazing and I'll certainly be using it!!), but I feel that a unification of efforts here could benefit everyone. I know that man-power is spread thin on kit (god bless ben and the svelte core team), and the router is solid right now- but I think that someone like Jake leading the effort towards a more powerful routing story could be invaluable.

While I want to encourage Jake and the Kit team to consider working together on this, I don't want to assume anything about anyones plans (I've only spoken to GHOST about this so far), and I don't want to diminish Jakes efforts on Routify 3- hence this discussion! I'm mostly curious about what people think.

[jakobrosenberg]

Great post, @fractalhq.

I've been talking to Ben and he's working on more streamlined support for 3rd party routers in Kit. (Currently it can be done by creating an [...index].svelte file in the root and letting it catch everything.)

I would love for Routify to be the default router of Kit and dedicate my efforts to the Kit experience. That said, I know a lot of people have worked very hard on the existing router and some may have grown attached - as I have. However if the Kit team feels that Kit would benefit from the extra hands on deck and a new router, I'm all in. My goal remains to build a routing solution that beats anything available today, while remaining as easy as Svelte itself. Working alongside the core team could unlock some true magic.

We'll be presenting some of the new R3 features at the upcoming Svelte Summit.

[benaltair]

I'm curious, what are some examples of functionality that Routify could offer that Kit can't so far? I'm not familiar enough with Routify at this point

[ghostdevv]

Routify has a wide variety of helpers and is very customisable. R3 also has a bunch of new features that you can take a look at here: https://v3.routify.dev

[benaltair]

So things like Guards to explicitly handle protection of certain routes I suppose?

[benmccann]

I have a PR that exposes the Vite APIs that SvelteKit is built on-top of: #2663. You should be able to use that to plugin different routers to SvelteKit. Routfiy turned out not to work with it though because it doesn't use Svelte's built-in SSR functionality and instead uses JSDOM. It turns out there aren't really many routers that support native SSR besides SvelteKit's. I think svelte-routing might and so I'd be curious to see if it could work with SvelteKit as well. I'd be curious to see if Routify could be made to work with native SSR support, but that's not something I'd work on since it's outside the Kit codebase. I'm happy to advise or help how I can if anyone else wants to give it a try though

As for functionality that exists in Routify, but not Kit yet, I'd say some of the ones I think are more interesting are route guards/hooks, metadata, and multiple router instances. These are all things we could add to Kit, but given all the various competing demands isn't something I've gotten to yet. I'm happy to review PRs if folks would like to add them though

[samal-rasmussen]

Hi Ben. So I don't know much about SSR and I'm wondering could you explain what you mean by "native SSR"?

[jakobrosenberg]

Routify 3 is designed to work with Svelte's built-in SSR. ​There's an example here.

​As for #2663 I gave it a try today and have Routify 3 working with Kit's builtin SSR. I would have solved it sooner, but had ongoing issues with Kit + npm/pnpm workspaces 😳.

I'll try upload an example today.

[jakobrosenberg]

@samal-rasmussen Routify 2 didn't have any native SSR support. This was solved by bundling the starter template with universal SPA to SSR solutions like spassr/tossr (hence the names 😋).

There were pros and cons to this approach. Like easier development, but slower SSR.

Routify 3 works with both. If you use it in Kit, you get native SSR. If you use it in a SPA and add spassr you get JSDOM SSR.

[lkj4]

Routing is the core of SvelteKit as it is with Next.js.

Routing paired with SSR must work flawlessly because of SEO and all nuances which significantly impact SEO rankings. I mean, this is one of the main reasons we use SvelteKit or Next.js and I wouldn't want to have experiments there, it's just too much money on the table and hey, never change a running system. If routing/ssr/SEO does not work perfectly, I would switch within seconds. SEO is too important and I chose SvelteKit because of SvelteKit, its vertical integration, which is almost like an Apple product and especially because of their core maintainers, not disrespecting any other maintainers but yeah. Before we decided for Svelte, a big part of the due diligence were the maintainers, just to hint where users are coming from.

Just to give another example, imagine Michael Jackson who built react-router would knock on Next.js' door and ask to integrate his router. This wouldn't make any sense because it's an essential part of the entire thing and Next would—of course—politely decline. Btw, Michael Jackson built Remix which builds on his prior work and react-router. So, there are many options to use one's energy and go further and enrich the ecosystem without fragmenting because it would be still Svelte.

Moreover, users can chose between the battle-tested built-in router which covers 99.9% of users' needs and other libs. If we make another lib the default, the battle-tested, flawless, built-in router is removed from the market and from an oiled system. Plus distraction, breaking changes for all of us, in particular the users. Aiming now for the perfect integration without breaking changes would be just an aim and the end of the day, we know how migrations go. Further, in SEO land you don't see breaking changes, SEO impact is slow and cause and effect are far apart. It's very hard to find the cause for organic traffic changes. And having "some" router exchanged in the meantime, would not help either.

For Svelte it's important to have sane defaults and let third-parties extend, otherwise we would miss the opportunities of building a proper ecosystem around Svelte and SvelteKit (if we integrated everything into core). So, it's also an important decision for the core maintainers—only by keeping the core lean and being very cautious about what goes into core, they set the foundation for a proper ecosystem and its growth. Let's spend out energy on proper APIs for third parties who want to plugin, so even more maintainers can extend SvelteKit instead of reducing options.

So, I highly appreciate any work around Svelte, because we all have one thing in common, we love Svelte but I would be super strict to rip and exchange out core and moneymaking parts of Svelte. And, btw It's always easy to add features but it's hard to maintain and remove them.

[ghostdevv]

The difference with this is that first svelte kit is in beta, it's not designed for production use (though I do understand it's being used in production environments). Making changes now is the only chance you will get to make these changes, that will improve kit and make it better, not only for the developer but for the application that is shipped using kit.

Routify is a incredibly mature router and has been around a while, is coming up to it's third version, and is actively developed. Like SvelteKit it has a community of users around it. Routify on it's own works fine, it's a great router. But for me having access to everything svelte kit can offer (especially it's adapters) is very important.

The point of potentially having Routify in kit (in my eyes) is this:

• At it's current state Routify has more features than kit, while kit will most likely integrate most of them there will always be fragmentation between the feature set of Routify and kit which isn't ideal

• Svelte Kit is big, the kit & svelte team have a lot on their plates and having such a big part of kit worked on by more people would speed up kits development and improvements over time

• Routify & Kit are awesome, Routifys features are unparelled, and kits community and features are too - bringing them together would be a match made in heaven

Moreover, users can chose between the battle-tested built-in router which covers 99.9% of users' needs and other libs. If we make another lib the default, the battle-tested, flawless, built-in router is removed from the market and from an oiled system.

The kit router is changing regardless of whether Routify is involved or not, Ben is making it modular and they are working to add new features - Routify would skip both of these steps

[lkj4]

Routify has more features than kit,

More features is no feature in the long-term, think of maintenance, integration, etc. Adding features is easy and not the problem, everybody can do this, it's the overall design/architecture, how things will play together, and how crucial are all those extra features for 90% of the users?

With this reasoning, people could come and say we need something like formik for full-featured foms, integrated as deafult or super-duper complex Redux for immutable state management, just because, as default, in the core, with 500 million pages of docs and tutorials, right in SvelteKit, let's overwhelm the user, right from day 1. This is not how open source works and how ecosystems evolve. Let users have a choice, and let the core team keep focus and create an overall, balanced package which is extendable.

will most likely integrate most of them there will always be fragmentation between the feature set

I wouldn't call it fragmentation but an evolving ecosystem which can't evolve if we stuff every lib into core. And the common base is still Svelte.

more people would speed up kits development and improvements

No, more people wouldn't speed up anything, more devs != more pace. It's about smart decisions, designs and an architecture which is extendable, which you cannot speed up by just throwing more devs at it. It's so easy for dev teams to develop themselves into a deadlock by adding feature after feature. The core team should spent all their time and energy on sane defaults and an API for plugging in third-parties.

Routify & Kit are awesome, Routifys features are unparelled,

Maybe... but again, I run SEO- and $$$-critical apps with SvelteKit and while I highly respect/appreciate Routify's maintainer, I clearly don't want to have a crucial part to be exchanged. And if I wanted those features so desperately, I'd just use Routify, easy.

Why let the Routify maintainer not grow further usage and downloads until such a decision can be made, if at all. And still, why not keep multiple options in the market?

Look, less options in a market => less competition => stagnation. Keep the ecosystem vibrant, we need more than just one router.

The kit router is changing regardless of whether Routify is involved or not,

I wouldn't call it changing but rather, its base is getting an interface to let and get third parties involved. And in general, I haven't seen any breaking changes in the past (which have affected me) and this is why I trust my time and money to the core maintainers.

Routify would skip both of these steps

IDK, this feels a bit like apples to oranges. SvelteKit job is not to compete with Routify but enabling solutions like Routify and others to exist by providing good interfaces.

If Routify is the way to go, let it grow from now 2K to 100K or even 200K npm downloads/week, let testimonials speak about the SEO success with Routify, let them show the Google SEO Dashboard, let it mature more. How many libs come and go, how many maintainers lost their motivation and left us with deprecated software or unanswered issues. Starting something is easy, keeping something running and all features working well over years is the hard part. Let Routify stand on its own feet and win more users and we'll see.

💚

[pngwn]

Late to this one, I don't think allowing third-party routers is anything but a good thing for a variety of reasons and I don't think this necessarily needs to impact kit in anyway. It may make sense in the future to consolidate efforts but that doesn't need to happen.

On the two routers more broadly: I think there are problem few issues with both, so I don't think getting into a comparison game is particularly helpful. They both have their advantages and disadvantages that would need to be ironed out before any one of them could claim title 'destroyer of all routers'. It may be that such a solution is unrealistic due to different use-cases or they may just need to implementation and design changes. We need a suite of differing and complex use cases to really answer that question.

When I get the chance I'll go into more detail on the problems with some of the existing routing solutions. I think I've tried every router available at this point and I don't think I found one that handles everything in the manner that I'm looking for.

[samal-rasmussen]

Agree. Routing is one of those things that people just need to do differently for different reasons.

[jakobrosenberg]

I second that. Which component/router is the default isn't important. What matters is quality + versatility of the tools in the ecosystem.

To me, it's far more important that R3 and Kit's builtin router offer different solutions for different use cases.

Swiss army knives are cool, but specialized powertools designed to work seamlessly with the same battery will take you further. I used Kit's builtin router for my last MVP, cause it did the job, but for most projects, I add R3. It boils down to what I'm building.

[Pensarfeo]

Any progress on this?

[jakobrosenberg]

You can use Routify 3 inside Kit, but there are no plans to use R3 as the default router.