Reflections on Migrating My SaaS to SvelteKit
sveltekitsaas.com
Reflections on Migrating My SaaS to SvelteKit
1–10 of 46 posts
Re: Reflections on Migrating My SaaS to SvelteKit
#2SvelteKit is a very complete and well designed solution. Routing, data loading, forms, SSR, caching, dealing with environment variables - all very nice. The only "drawback" is Svelte - I just don't like the data binding thing and prefer working with React components and hooks. Maybe that's just because I've spent so much time in React/Next. Well written React code is actually quite easy to debug, reason about and debug. I find it super annoying to refactor Svelte code because every time I want to extract some code into a component it can't be a function in the same file before it becomes a whole new file. It has to be a file. Also haven't found anything nearly as nice as Framer Motion and Radix in Svelte land.
Re: Reflections on Migrating My SaaS to SvelteKit
#3SvelteKit is awesome - I wished there were a nice Docusaurus alternative in it. I checked out KitDocs and Sveltepress but both seem like small personal projects that can at anytime stop being maintained.
Re: Reflections on Migrating My SaaS to SvelteKit
#4I am so confused that both next and svelte seem to be entirely fine with x identically named files being concurrently open, which directory based routing has given rise to by design.
Surely, this issue can not hand waved away by the entire team of two major web frameworks, while they are currently trying to establish directory based routing as a new paradigm?
Re: Reflections on Migrating My SaaS to SvelteKit
#5how does it compare with react?
Re: Reflections on Migrating My SaaS to SvelteKit
#6> The naming conventions for routes is a little bonkers. Now when I’m working on my app I have like 10 tabs open that all have the name +page.server.ts. Does anyone know how I can make this better in vim?
:help setting-tabline
Low-level stuff; consolidating with some kind of project root directory concept and patterns would be convenient for such cases.
Re: Reflections on Migrating My SaaS to SvelteKit
#7SvelteKit is awesome - I wished there were a nice Docusaurus alternative in it. I checked out KitDocs and Sveltepress but both seem like small personal projects that can at anytime stop being maintained.
For what it's worth there's a good library to load markdown with Svelte components mixed in. Here's how I'm loading it: https://github.com/jokull/blog/blob/master/src/lib/getPosts....
Re: Reflections on Migrating My SaaS to SvelteKit
#8how does it compare with react?
Very different. Svelte has magic event bindings and compiles `.svelte` files. Their learning material is interactive and worth going through just to see some new ideas.
Re: Reflections on Migrating My SaaS to SvelteKit
#9The more I see it the more I'm certain that Rich and the team screwed the pooch with the whole '+page.server.ts' stuff.
They should really be using the existing syntax to have a context="server" portion instead of splitting the file out.
Heck, it could even just be an import for a server.ts file in the same root directory if people really liked the +whatever style of having the server code separated.
It feels especially redundant when you're building a static app or SPA. The sort of overly opinionated nonsense that put me off React and on to Svelte in the first place.
I've decided against making the switch to SvelteKit and instead rely on good old Svelte because I can have a /pages/Whatever.svelte encapsulates the structure and core logic of each view/page. It's clean, it's HTML-like, it works and more importantly, I can immediately wrap my head around it when coming back to the project after a period away.
I deeply love the guy, but I really think Rich should walk back this decision and default to the "whats the cleanest pattern that people can easily wrap their head around" approach.
Re: Reflections on Migrating My SaaS to SvelteKit
#10SvelteKit is a very complete and well designed solution. Routing, data loading, forms, SSR, caching, dealing with environment variables - all very nice. The only "drawback" is Svelte - I just don't like the data binding thing and prefer working with React components and hooks. Maybe that's just because I've spent so much time in React/Next. Well written React code is actually quite easy to debug, reason about and deb…
With all the love in the world, that's probably down to the sunk-cost fallacy. You've invested a chunk of time into understanding the idiosyncrasies and non-standard methodologies that React has pushed at you over the years.
Svelte's pattern for data binding (with the exception of the $: reactivity) is exceptionally idiomatic and as close to standard web as 2-way reactivity will ever be. Easy to get to grips with as a newbie and a breath of fresh air for someone with years of fe experience under their belt.
Svelte embodies the KISS principle and long may that last.